Why You Need To Embrace DevOps Differently

The great race is on for companies all around the world to implement a DevOps culture. Gartner was absolutely right when it predicted that DevOps would evolve from niche, to mainstream in 2016. Now, it’s arguably the most popular and widely adopted methodology in the development world. In fact according to the RightScale 2016 State of the Cloud Report, 70 percent of SMBs are adopting DevOps, as are more than 81 percent of enterprises.

But, with such rapid adoption, one has to wonder if everyone firmly understands why it’s needed, or reasonably, if companies are just trying to follow the latest software development trend.

That said, I’ve noticed companies make a few common mistakes when it comes to DevOps. They may have the technical knowledge down pat, but they haven’t acclimatized to the culture, which causes a number of complications when it comes to communication and collaboration. Here’s what you can do to ensure your company is fully prepared to embrace DevOps, and reap all the benefits it has to offer.

Culture > Technology

The agile software development methodology, of which DevOps is an outgrowth, consists of five fundamentals: values, principles, tools, processes, and practices. However, while more often than not companies put the emphasis on the last three, many of the issues they face arise from the first two softer fundamentals.

DevOps is a cultural change first. So to implement DevOps tools correctly, developers must be disciplined in the culture. This means caring about the whole development and delivery life cycle -- through deployment, operations, quality assurance, etc. -- and not just about the code. The tools employed for DevOps, should only exist to support this culture.

However, many companies seem to implement the technology first, such as cloud services like Amazon Web Services, container technologies like Docker, virtual machines, or continuous integration servers, in order to hit the ground running with DevOps. But they do so before making sure the team is really mature enough to fully adopt the principles the culture demands.

If one starts with the tools but isn’t prepared to use them, attempting to embrace DevOps will become hugely complicated for an organization, and can even become counterproductive.

Think continuous integration (CI) servers, for example. They continuously run automatic tests after a developer pushes new code to a repository, to ensure the software is in a functional state. But if a development team quickly configures a CI server and the developers aren’t disciplined enough to manage it, the team may well stop focusing on the quality checks. As time goes by, they will see that the server has been in red for a couple of weeks, meaning that any changes they deployed over this time period, weren’t even functioning correctly. Without discipline, the tool by itself means nothing.

Unnecessary technical complexity

DevOps emphasizes communication, collaboration, and automation, to make infrastructure changes and software delivery a whole lot easier. And considering all the hype surrounding it, it may be tempting for companies to go all in with DevOps, and implement every new approach in the book.

But companies beware. This isn’t the way to go. Implementing a DevOps approach without being entirely sure of why you need it will likely leave your developers in a technical mess.

Companies need to analyze their pain points, and only implement DevOps processes where they need them most.

For example, imagine a development team is analyzing how to implement a microservice architecture style, which is used to build independently deployable services. While there certainly are valid reasons to this approach, the decision to go forward with it should be considered carefully. With each microservice developers create, they need to think about deploying it, monitoring it, and testing it, etc. That is a lot of work. Oftentimes, developers could have met their needs in a much simpler way, and their energy could have been better spent if the company invested in other areas of the development process.

[As you head into 2017, check out the 10 Tech Jobs Set For Big Pay Raises in 2017.]

Take what we did at PSL, the company I’m involved with. Whereas with previous projects we had implemented DevOps-related techniques before the team understood why they were needed, we took a different approach with a one-year project. We didn’t get into trending containers technologies, but rather implemented continuous delivery step-by-step to analyze results and gather feedback. We did convert two features into independent microservices when we found they had performance issues, but the rest of the application remained monolithic.

The whole approach was much more effective. It was based on a continuous introspection from the development team, measuring results, and keeping an eye on what business value every implemented change possessed. Most importantly, the team was committed to the whole delivery and quality processes, and kept that focus while all the changes took place.

If companies focus on exactly where they need to improve, they’ll be able to figure out why DevOps related technologies are important to them specifically. There’s no need to deploy DevOps technologies front, right and center. It’s fine for a company to dip their toes in it, because sometimes a leaner approach can provide the same benefits. Just with less complexity.

Although it’s tempting to take up DevOps head on, companies first need to make sure their teams are mature enough to engage in it. DevOps is a culture before anything else, and it needs to be built slowly, brick by brick.

Sebastian Velez, is the Director at the Center of Excellence at PSL, a Latin American agile software development company based in Mexico and Colombia. PSL has partnered with, amongst others, companies such as IBM, FedEx and Oracle.