Why You Need To Embrace DevOps Differently - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

02:00 PM
Sebastian Velez, Director at the Center of Excellence at PSL
Sebastian Velez, Director at the Center of Excellence at PSL

Why You Need To Embrace DevOps Differently

Before you jump into DevOps understand what problems you are trying to solve, and whether you need to make a complete commitment to all of the elements or just specific aspects.

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.

Sebastian Velez, PSL
Sebastian Velez, PSL

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.

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
White Papers
Register for InformationWeek Newsletters
2021 State of ITOps and SecOps Report
2021 State of ITOps and SecOps Report
This new report from InformationWeek explores what we've learned over the past year, critical trends around ITOps and SecOps, and where leaders are focusing their time and efforts to support a growing digital economy. Download it today!
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll