DevOps promises faster, better software delivery cycles, but engineering leaders should consider if it's the right approach for them and their organization.
Over the past decade, DevOps has emerged as an overarching philosophy and set of development practices that have transformed how software is written and deployed.
In companies that implement DevOps, the silos that once separated development and operations teams have now been broken down. The once monolithic “big bang” software releases have been replaced by small, regular releases to the existing codebase that can be safely rolled out whenever they’re ready. While not every organization has made this shift, it has become a hugely popular way to build and run software.
If your company is considering making this shift, you will need to know how this major change will align with your existing organizational structure, the skills your engineers will need, and how to measure success.
What is DevOps?
DevOps isn’t a tool you can buy or a technical architecture you can roll out. It’s a way of thinking about software development that informs the tools and architectures you choose. This gives engineering leaders scope to implement DevOps in a way that suits the needs of their organization and teams.
At its core, the principles underpinning DevOps is to bring together development (writing code) and operations (making sure that code runs properly).
Before DevOps, most software would be written by developers and run by operations, with little collaboration between the two. The waterfall project management method dominated, requiring each large phase of a project to be fully complete before the next one can begin.
You can see why a company building a skyscraper would need to make sure its foundation is absolutely perfect before they start building upwards. But this way of thinking isn’t necessarily as well suited to building software. Monolithic software projects held companies back from innovating fast, responding to customer demands, and keeping up with a new wave of nimble, cloud-native competitors.
DevOps arose alongside the agile project management methodology, which, unlike waterfall development, emphasizes fast, iterative rollouts of small features and improvements that can be quickly reversed if necessary, with multiple initiatives operating in parallel. With DevOps, the operations team is more intimately involved in the development and testing of individual features, and their feedback helps development teams understand the real-world environment they’re releasing features into.
This culture of cross-team interactions has increasingly become the norm in the software industry, so much so that other teams are sometimes integrated with development and operations in a similar way. For instance, you’ll sometimes hear about DevSecOps, in which security teams take part in the iterative development process to ensure security features are built in from the ground up rather than added later.
The DevOps lifecycle
DevOps is implemented through a software development lifecycle that goes something like this:
- A plan is developed for a new feature or bug fix
- Developers write code implementing that functionality
- The code is built so that it’s executable
- The new functionality is tested in an environment as similar as possible to production
- Once the tests are passed, the code is released to production
- Released code is integrated with the live codebase and deployed
- The new code operates in the real world
- Care is taken to monitor recently released code and assess how it performs
- This feedback helps to develop plans for future iterations
As you can see, this cycle is built as an iterative loop, which is why it’s often represented with an infinity symbol.
Steps one through four are generally considered to be the realm of development, while five through eight are under the umbrella of operations. But under DevOps, both teams (or a combined DevOps team) will be intimately involved throughout the cycle. Developers can be called in to address runtime considerations in live software. Operations specialists can provide input during planning and design sessions on how code can efficiently make use of existing IT resources.
Engineering leaders will be responsible for fostering this kind of collaboration and making sure the processes that drive this lifecycle run smoothly. If you’re shifting from a more traditional software development model, you need to make sure that these teams are able to integrate and collaborate with each other in new ways that team members might find unfamiliar and uncomfortable at first.
When hiring, keep an eye out for generalists who are comfortable keeping a foot in both worlds, and have great communication and collaboration skills.
DevOps practices
In order to make this lifecycle a reality in practice, engineering leaders need to implement a number of practices that may represent a radical change to how your team members work.
- Continuous integration and continuous delivery, or CI/CD – In many ways, CI/CD has grown and matured as an integral part of DevOps. Under CI/CD, developers are constantly committing small updates to an application codebase, and these updates are quickly tested and deployed with the use of automated test processes and build tools. Version control systems like Git and automated building and testing tools like Jenkins make CI/CD possible. But leaders need to put policies and procedures into place to ensure that these tools are used correctly.
- Microservices-based development – It’s difficult to implement small, frequent changes to a large monolithic codebase. That’s why DevOps shops tend to build applications out of microservices – smaller pieces of functionality that communicate with one another via APIs. Ideally, you can make changes to microservices without affecting the rest of the codebase, so you can update (or roll back to a previous version) bits of functionality without breaking the application as a whole. Microservices typically run in containers – self-contained virtualized computing environments – which make them more portable across various infrastructure types, and ideally reduces the chances of nasty surprises when you roll them out onto a new production system.
- Infrastructure as code – In many ways, this is the operations-side parallel to CI/CD. Under infrastructure as code, automated tools like Ansible use declarative configuration files to provision the servers and other infrastructure needed to keep an application running.
- Communication and collaboration – In order to make sure everyone is on the same page, structured systems for regular communication and collaboration need to be in place. This might entail using project management tools like Jira to track progress, the collaboration capabilities built into code repositories like Git to hash out differences of opinion on feature development, or regular stand-up meetings.
Managers will need to get organizational buy-in for these processes, both from the developers who will have to implement them and from management, who will need to allow for a transition period as your team gets up to speed. This is particularly tricky in organizations that rely on a waterfall-based software development model and have little appetite for disruption.
Why your team should adopt DevOps
The value proposition of DevOps is simple: done right, it enables both improved speed and quality for your software releases.
- Speed of development increases because the iterative nature of DevOps encourages constant small-scale improvements and automated testing and rollout. A 2019 survey found that teams using DevOps deploy 200 times more frequently and 100 times faster than their non-DevOps counterparts.
- Quality improvements arise naturally when constant and automated testing, as well as continuous monitoring and communications among teams, becomes the norm. This is especially true when security is fully integrated into the DevOps cycle.
- Tighter collaboration is a prerequisite to making DevOps work. Getting previously siloed teams to work together will have a huge impact on your company cohesion and capacity to innovate, even beyond the immediate benefits of DevOps.
Barriers to adopting DevOps
Despite its obvious benefits, the execution of a DevOps transformation is the key to success. There are a number of barriers that could stand in the way of a successful DevOps rollout.
- Technical troubles – DevOps is a philosophy, not a product, but to make it work you may need to adopt several big technical changes to your software development process. You’ll likely want to break your existing applications into microservices and adopt a collaborative code repository like GitHub, along with a suite of automated build and test tools. These can cost money (though there are open source alternatives) and time to get devs up to speed. You can also run the risk of tool sprawl as you implement all this, especially if you’re choosing individual tools off the shelf instead of an integrated suite. Finally, if your codebase is made up of large, monolithic applications, it's also going to take time and expertise to break those apart into DevOps-friendly microservices.
- Cultural resistance – Your current codebase, processes, and culture are familiar and probably comfortable to your team. As an engineering leader, you need to convince them that making the leap will be better for the company and for them in the long run, and identify which team members have the skills and temperament to grow into new roles in a restructured team.
- A half-hearted transition – You need to overcome both technical and cultural barriers in order to reap the benefits of DevOps. It’s all too common for organizations to build out a technical infrastructure for CI/CD but not do the harder work of making the necessary cultural shifts.
- Increased risks loom – While slow, waterfall-based development has opportunity costs, those moving to DevOps need to accept that iterative development increases the risks of rolling out updates that aren’t fully thought through (even if they can be rolled back). Also, in some industries, regulatory regimes require a stricter separation of roles than what DevOps envisions, so in these fields you might need to modify the usual DevOps way of doing things in order to comply.
Key DevOps skills for your team
If you’re looking to hire developers or engineers to drive a DevOps initiative or team, or get your current team up to speed, make sure they’re familiar with the sorts of technologies and platforms we've been talking about so far: CI/CD and its associated tools, automation generally, microservices architectures, API-based development, and Kubernetes or similar container orchestration platforms. That’s on top of your existing languages and frameworks.
Just as important as these skills, if not more so, is a willingness to work in cross-functional teams, and being comfortable talking to – and taking feedback from – operations, product, and business team members on a regular basis, not just at occasional requirements gathering sessions. In this world, a generalist who’s willing to learn is more valuable than a specialist hyperfocused on one domain.
What comes next?
Making a move to DevOps can be a big shift. If possible, you may want to take a gradual approach, putting together a small proof-of-concept team focused on a specific application or initiative.
That’s a great way to identify benefits and barriers to DevOps in your own organization and learn lessons that you can apply to a bigger rollout and – if all goes well – total transition.
There are plenty of resources available to anyone wanting to get started with DevOps, including Gene Kim’s DevOps Handbook. The key, however, is to focus on the people element rather than diving into the tools and technology that you will eventually use.
If you’re ready to learn more, check out these resources from LeadDev:
.png)
.png)
_0.png)
.jpg)
.png)
.png)
.jpg)
 (1).png)
.png)
.png)
.png)
.png)
.png)
 (1).png)
.png)
.jpeg)
 (1).png)
.png)
.png)
.png)
.png)
 (1).png)
.png)
 (1).png)
 (1).png)
 (1).png)
.png)
.png)
.png)
.png)
 (1).png)
.png)
.png)
.png)
.png)
.png)
.png)
 (1).png)
.png)
.png)
.png){kind=icon}
.png)
.png)
.jpg)
.png)
.jpg)
 (1).png)
.jpg)
.png)
 (1).png)
.jpg)
.png)
.png)
.png)
.jpg)
.png)
