For nearly a decade, DevOps has been the talk of the town--or, at least, the talk of the IT industry. Everywhere you go, you hear analysts singing the virtues of DevOps as a better, faster, more secure and less costly approach to building and deploying software. Those arguments are persuasive. In most respects, it’s easy to understand the benefits of DevOps. But there remains one big problem with DevOps in many organizations today: putting DevOps theory into practice. It’s easy to talk about DevOps at a high, abstract level. It’s much harder to figure out how you operationalize DevOps, or translate DevOps principles into actual on-the-ground practices. That’s likely one reason why companies tend to report slow progress in achieving DevOps.
If that’s a conundrum you face, keep reading for real-world tips on actually doing DevOps.
DevOps at a High Level
Before delving into strategies for putting DevOps into practice, we have to start by identifying which goals DevOps is supposed to help you achieve in theory.
Different folks define DevOps in different ways, but most discussions center on a few key principles:
- Developers (whose job is traditionally to write software) should work in close collaboration with the IT Ops team (whose job centers on deploying and maintaining software).
- Software should be “continuously delivered.” This means rolling out changes to an application on a constant, incremental basis, rather than releasing a large set of updates all at once every few months or years.
- All members of the IT organization should have easy access to information about the software-delivery process. Information should not be “siloed” away in places where only certain teams or individuals can access it.
- Software-delivery operations should be able to scale, which means supporting larger volumes (or, in some cases, scaling down in order to avoid unnecessary costs), even if team size doesn’t increase. Automation is critical for achieving scalability.
- IT teams should strive for continuous improvement by identifying weak points in the applications they deliver, then using that information to improve their operations.
You need not be a professional IT analyst to understand how these goals can improve software from the perspective of both the people who create it and the people who use it.
Putting DevOps into Practice
But, again, implementing specific processes and tools that enable the goals identified above is harder. Unlike many other IT concepts, such as “the cloud” or “automated testing,” doing DevOps isn’t as simple as merely adopting a new kind of infrastructure or a new kind of tool. Nor is it as easy as hiring the right kind of staff, although some companies mistakenly think that this is all they have to do, which is why “DevOps engineer” has become such a popular job title.
Instead, putting DevOps into practice requires reconfiguring the entire software-delivery process, and it typically involves adopting a variety of new tools--as well as using existing tools in new ways.
With that challenge in mind, here are some practical tips for operationalizing DevOps.
1. Identify the tools you need.
Operationalizing DevOps should start by figuring out which tools you need to do DevOps. While there is no specific set of tools required to achieve the goals associated with DevOps, you’ll typically want the following:
- A Continuous Integration server, such as Jenkins or TeamCity. This type of tool helps to ensure that you process new code at the speed of continuous delivery.
- An automated testing framework, like Selenium, which you can use to help test applications quickly across a variety of environments.
- Software monitoring tools that help you identify availability and performance problems. Ideally, you’ll use these tools not just for production applications, but also during the pre-release stages of your software-delivery pipeline.
- Communication tools, such as Slack and Trello, which help to streamline the sharing of information across teams.
Other possible types of tools to consider include:
- Configuration management tools, such as Ansible or Puppet. These tools help to automate the provisioning of infrastructure and the deployment of applications. These may no be necessary if the scale of your software-delivery operation is small, but they are critical when you want to scale up.
- Application orchestration tools such as Kubernetes, which are also critical for large-scale software deployments.
2. Identify your infrastructure.
In addition to implementing the right tools for DevOps, you’ll need to determine which type of infrastructure you’ll use those tools in conjunction with. Consider the following options (which are overlapping to a certain extent):
- Cloud-based IaaS infrastructure, which enables greater scalability and portability than on-premise infrastructure.
- Docker containers, which are useful in a continuous-delivery operation because they make it easy to build software once and run it anywhere (or anywhere that supports Docker, at least, but that’s most Linux or Windows-based environments these days).
- Serverless functions, another handy infrastructure building-block for deploying applications cost-effectively at scale.
- You may already be using some or all of these infrastructure components. In order to leverage them to greatest effect for DevOps, you’ll want to figure out how you can best integrate these resources into a continuous-delivery pipeline to which all members of your IT team have access.
3. Reorganize (or expand) your team.
As noted above, “DevOps engineer” is now a thing, and you can find plenty of qualified IT professionals who were trained specifically in DevOps practices. Adding these folks to your team is one way to help operationalize DevOps.
However, you don't need to hire a slew of new engineers or rewrite all of your job titles. You can also reorganize your IT existing team. If it’s currently broken into different groups, with developers isolated from IT Ops personnel, you’ll want to break down those barriers. That doesn’t necessarily mean having developers start working in the IT Ops department and vice versa, but it does mean building effective communication channels between the different teams, including by using the types of communication tools described above.
You might also consider strategies such as having some developers spend part of their time each week in the IT Ops department, and vice versa, or setting up recurring meetings where developers talk to IT Ops.
Ideally, you won’t stop there. Including other members of the IT organization, such as software quality engineers and security experts, in the communication channels you build will reinforce DevOps best practices and enable maximum visibility into IT operations.
You can hire DevOps engineers, too, but my general recommendation is to think of them as guides who can help facilitate communication between your existing IT teams, not replace them.
4. Implement processes to act on feedback.
Continuous communications between IT teams is not enough on its own to enable the level of continuous improvement that DevOps prioritizes. You should also take care to implement specific processes that ensure that your teams act upon the information they share with each other.
This could take the form of weekly or monthly meetings where different groups come together to discuss problems they have observed (such as a feature IT Ops has noticed that continually causes performance problems in production) and develop plans for fixing them (such as how developers will write new code to fix the performance problem just described).
Ideally, your team will also work on a daily basis to take feedback into account and make continuous improvements. But having a specific process in place to make sure that action is taken in response to data collected by different teams ensures that you actually achieve the continuous-feedback loop that DevOps prioritizes.
Conclusion
It’s easy to talk about DevOps in the abstract. It’s much harder to “do DevOps” in practice. But with the right tools, infrastructure, people and processes, implementing DevOps is quite feasible.
