This article originally appeared on the Oracle Technology Network blog.
If you want to implement a DevOps culture, don’t start with technologies.
DevOps is an effective, collaborative, and comprehensive approach to managing software development and deployment. Consequently, it has become the most popular way of approaching software development and automation for large and small enterprises alike. In fact, the “RightScale 2017 State of the Cloud Report” noted a continued increase in the number of enterprises and small-to-medium businesses (SMBs) adopting DevOps. Now, more than 84 percent of enterprises and 78 percent of SMBs are implementing DevOps. Perhaps the most telling statistic is that over 30 percent of those companies are adopting DevOps company-wide, a 9 percent increase since 2016.
As many adopters are beginning to recognize, implementing DevOps is a study in patience and perseverance as notoriously specialized areas of an organization learn to collaborate. It requires a refined and concentrated approach to ensure adoption runs smoothly. And while the benefits of implementing a DevOps culture are clear—continuous software delivery, more-stable operating environments, greater collaboration across teams, and so on—far too many companies are making avoidable mistakes when it comes to DevOps.
In order to move forward with DevOps, you need to understand the implications of DevOps as a culture, know the problems within your projects you are trying to solve and decide whether you need to make a complete commitment to all of the elements of DevOps or to just specific aspects. DevOps will cause communications and collaboration challenges if your team has expert technical knowledge, but they haven’t acclimatized to the culture. So, to help you oversee a successful DevOps implementation, I’ve highlighted here some of the lessons I’ve learned through implementing DevOps at the company where I work.
Culture Shift First, Technology Shift Second
DevOps is first and foremost a cultural change. It is incredibly important for companies to recognize that DevOps cannot be implemented only through the adoption of particular tools or technologies. You want your development, operations, and management teams all committed to the entire development and delivery lifecycle, not just the individual component of the process. I’m talking about deployment, operations, and quality assurance teams, as well as others, all coming together to support a collaborative, cross-team DevOps culture. As you’ll find, it is much more difficult to adopt a new company culture than it is to just use several new technologies.
So, how do you get there? The answer is there is no easy way, but there are some important things to pay attention to when adopting a DevOps culture. In order to construct a strong foundation for cultural change, the values and principles of DevOps—namely shared responsibility; automation; and real-time, reliable feedback—need to be thoroughly understood and embraced by those involved.
At the company where I work, we took a very fundamental approach to adopting DevOps. We introduced the idea gradually with a focus on building awareness and solving tangible, frustrating pain points within our projects and documenting the results. However, one of the most important things to note when making the transition to DevOps is that you are not creating another silo or a separate DevOps team; rather, all members are part of the delivery group building towards a DevOps culture. If a company starts with the tools but isn’t prepared to use them, attempting to embrace DevOps becomes hugely complicated and can even become counterproductive.
Think about it this way: your team sets up a continuous integration (CI) server, which is an automation component of DevOps. This server continuously runs automatic tests after a developer pushes new code to a repository to ensure the software is in a functional state. CI is a faster and more efficient way to develop software if it’s done correctly. The idea is that you catch bugs as the code is applied, not at the end of the application development cycle.
Unfortunately, if a development team isn’t disciplined enough to manage using a CI server, the team will stop making quality checks. Before long, the server has been facing issues for weeks, which is a scary proposition, because it means that any changes deployed over this period weren’t functioning correctly. Without discipline, without culture, and without cohesive goals, the tool by itself means nothing.
DevOps Not What You Expected? How to Get It Right This Time photo 1
[HANDPICKED CONTENT: Upcoming DevOps Technology Trends]
Address Pain Points First
The admittedly swoon-worthy benefits of DevOps make it very enticing for companies to dive in and instantaneously embrace DevOps fully, without due diligence. But as some companies are learning, that is not the way to adopt DevOps. Implementing a DevOps approach without being entirely sure of why you need it will likely leave your developers in a technical mess and your cross-team, collaborative approach to software development in jeopardy.
As with any new implementation, companies need to be critically aware of their pain points and their “why.” If your organization does not understand why or where it needs DevOps, be wary of accepting the implementation costs of DevOps. I admit, it’s easy to be seduced by container technologies and the whole suite of DevOps tools that make adoption seem so easy, but doing that doesn’t address the foundational issue: why you need DevOps in the first place.
For example, imagine that a development team is analyzing how to implement a microservice architecture style, which is used to build independently deployable services. While this approach works very well for large organizations with exponential scaling power—for example, Netflix, Amazon, and Google—the decision to implement a microservices architecture should be considered very carefully. At the very least, developers need to think about deploying, monitoring, and testing every single microservice that is set up. That translates to a lot of difficult, time-consuming work.
Through my company’s experiences with microservices, we’ve learned that sometimes developers could have met their needs in a much simpler way, and their energy could be better spent if the company invested in other areas of the development process, such as CI or increased testing automation.
There is no need for your company to start deploying DevOps technologies and hoping you’ll arrive at DevOps adoption. Rather, think about exactly where you need DevOps practices and why; focus on getting those problems solved first and then work on a wider implementation. A lean approach also has tangible benefits and involves less complexity.
Tips for Getting It Right the First Time
As you make the cultural shift within your organization, consider these tips to get it right the first time.
- Communicate—often and clearly. Avoid superfluous details, but also don’t leave employees in the dark. If you don’t have one, create a robust, company-wide communication system.
- Create a visual. With your team, create a visual representation of how DevOps operates within your company and ensure that it outlines your specific goals. This way, the team has something to refer to when things get cloudy.
- Survey the experts. Meet with teams from other companies that have already adopted DevOps. Consider leaving your building and getting in front of customers to understand how DevOps looks from their perspective. Most of all, ask the experts and avoid reinventing the wheel.
- Measure your outcomes. Define what outcomes are important for you to measure. Prioritize those and review them as a team to be able to understand how DevOps tools and technologies have affected your deployment time, your budget, and other key performance indicators (KPIs). That way, you’ll stay on top of problem areas and quickly discover best practices for your DevOps adoption.
About the Author
Sebastian Velez is director of engineering at PSL, a Latin American agile software development company based in Mexico and Colombia. He has been in the industry for more than a decade. In addition to founding different IT startups, Velez has led many large-scale enterprise projects for notable Fortune 500 companies. He has experience as a developer, software architect, scrum master, and college professor.
