DevOps has become the preferred way to ship applications faster and with better quality. However, making the transition...
from waterfall to DevOps can go wrong in many ways. Not only are many people, tools, processes, data and applications involved, but adopting DevOps must encompass approaches, such as microservices and application containers.
This tip covers the top mistakes that can make the road to adopting DevOps very bumpy.
1. Not going all the way
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 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 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 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 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.
Separating databases according to the services they power is what it takes to run microservices at scale. This calls for more management, as there can be numerous databases with different sets of data, but it also brings clarity in terms of responsibility, as the responsibility is also shared across micro-teams rather than a single team of database admins. Importantly, it makes your data more nimble, and helps requests be processed quicker. This speed delivers a better end-user experience, and helps developers build features faster, as they can take advantage of databases more easily.
The decision to migrate to the DevOps model of building software is only the start. The real effort lies in understanding the nuances of how it can affect every layer of your application stack -- infrastructure, databases, application code and team structure. Just focusing on one of these will not result in a DevOps transition; all of them need to be addressed in the right way for DevOps adoption to be successful.
Careful control is crucial for DevOps
Barriers to DevOps adoption
Bringing DevOps and QA together