Four mistakes organizations make when adopting DevOps
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – searchmicroservices.techtarget.com
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 new 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 DevOpscan 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.
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.