the process of adopting DevOps can end up being very painful for those who do not go all out in terms of cultural acceptance and fully transitioning to all the required tools. Throwing in a couple of tools like Jenkins and Git for version control and build automation might be a good first step for continuous integration, but the goal of DevOps is far beyond that.

You can’t keep your application architecture and underlying infrastructure the same as before and hope to achieve a DevOps transition. DevOps requires going all the way in changing your infrastructure, from servers and virtual machines to containers.

Containers bring advantages like portability across the development pipeline, flexibility in using multiple programming languages, decoupling of the host system from the application layer, and better security and fault tolerance. Today, it’s hard to imagine a DevOps team could function without the help of containers. While many organizations dip their toes in container adoption, it requires taking the plunge to transition to containers at every point of development.

Similarly, microservices is a bitter pill to swallow, as it calls for major change to the application layer. Microservices, the practice of breaking down a large application into multiple services that work together, supports DevOps in a big way because developers can independently deploy and manage each service. This helps simplify the management of each service, but as a whole, brings new challenges, as many services need to communicate with each other for the app to function seamlessly. Networking, storage, node replication, service discovery, load balancing and resource allocation all become vital to the app’s function.

2. Prioritizing titles over team structure

Giving everyone a DevOps title doesn’t change anything. The reality is that DevOps is a culture, and not a tool. Implementing DevOps means that you have decided to stop working as large, singular, isolated teams like Dev, IT and QA, and instead work as small, multifunctional teams that collaborate together on a Dev + IT + QA level. DevOps aims to achieve a culture that moves fast because teams are empowered to make decisions about the services they manage — that’s where structure comes into play. Your team should be organized based on the microservices architecture that powers your app. This will help each team that manages a service to become independent and to make decisions on their own without constant external assistance. Remember — you need a fast-moving, empowered team culture, instead of catchy titles.

3. Not securing data in the cloud

Out of the many reasons to prioritize data security, the one that stands out is the tremendous increase in the value of data. Information has always been critical for business success. Now, however, with the rise of data science, a company’s success depends on how much value it can unlock from its data. Simply put, data is an asset, and it is valuable today more than ever.

As you transition from a private data center to the cloud, data security is the first aspect to consider. This means understanding the shared responsibility model for data security in the cloud. The cloud vendor is responsible for the security of the cloud, and you’re responsible for security in the cloud.

Security in the cloud means following robust processes to encrypt your data into ciphertext, and to protect it with an encryption key. Services like Amazon Web Services Key Management Service help enforce this kind of data security. You need to ensure that the cloud vendor’s encryption policies and procedures match the level of security you need for audit and compliance purposes.

Securing your apps and data in the cloud involves a learning curve, but it is essential when you are adopting DevOps and a new way of operating in the cloud.

4. Not decomposing data along with services

For services to perform at their peak and process requests at a rapid pace, the data architecture that powers your application matters. If you simply decompose your app into services, but leave the databases that house your data untouched, the data becomes a bottleneck to performance.

• No CI (No Unit Tests, No Mocking)
• All Quality Gates are right-shifted (UAT/AC Testers, Load and Performance Tests, Security, …)
• Proprietary IDE and command line tools without CI functionalities
• DVCS not present or plays a unimportant role (See SYM and CVS)
• Package-Centric deployment (No Microservices)
• Many different package types/package content with different deployment plan
• Change Management and no machine readable release notes
• Complex dependencies to sub-systems
• Outage Handling
• PROD deployment different to PREPROD deployment
• Distributed Application Configuration Managemenet
• Segragation of Duty
• Historically complex (Need process changes)
• Monolithic Domains
• No DDD therefore almost impossible to introduce Micro-services
• No SOA approach
• Package-oriented deployment pipeline
• Differentiation between managed and unmanaged environments
• Often Bare-metal Infrastructure
• Infrastructure is and was never part of Legacy Code Life Cycle owned by Dev Team
• Often External Vendor sending packages to deploy on-premise at consumers site (Process-Break lead to DelOps)

Characteristics of Mainstream DevOps

• Greenfield view
• Almost legacy-free value streams with almost no complex dependencies
• Seamless transition from CI to CD via specific plugin support
• Micro-services
• Independent deployment to production
• Microservices allow easy rollback
• Container (Docker) and Unikernel Technology enabled
• PREPROD easy cloneable from PROD
• App Config Management can be handled right from the start (CI)
• Full trust in core-teams (you develop it, you build it, you run it)
• All processes are shifted left (No UAT Testers and no OPS anymore) and fullautomated
• Virtual Infrastructre Automation is part of Development