Get started Bring yourself up to speed with our introductory content.

Four mistakes organizations make when adopting DevOps

Making the transition to DevOps can be a bumpy ride. Learn how to avoid common mistakes that can make the road to DevOps difficult.

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 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.

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 new 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.

Next Steps

Careful control is crucial for DevOps

Barriers to DevOps adoption

Bringing DevOps and QA together

This was last published in October 2017

Dig Deeper on Microservices and DevOps

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How has your organization dealt with roadblocks to DevOps?
Cancel
Many IT vendors, some very large, depend on putting a new slant on the methods in order to get you to buy from them.  This is a constantly shifting landscape with vendors jockeying to get position for the future.  For example, Many popular experts on structured code wrote books on the subject.  Once object-oriented methods took over in web development, the same 'structured code' experts published books on object-oriented coding methods. They have never done it and have no credibility in that subject. Watch as value-pair files begin to replace RDBMS how quickly the big RDBMS vendors will claim to have the best file structure and tools for key-value pair parallel processing. 
Agile and Scrum create multi-skill teams that can perform all the necessary tasks to take an application all the way from Business Case to Production.  So, what will the staffing companies with employees with Release Management titles and Quality Assurance titles do?  Make the transition from Development to Production a specialty and separate it from the Agile Team's responsibility.  Well, they create Dev-Ops.  
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close