Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
If you asked the average person in the street, “What does DevOps mean to you?” you’d probably get a blank stare. And there are those who aren’t directly involved but are vaguely aware of DevOps as a concept. While a vague understanding is better than nothing, it leaves room for misconceptions and misinformation, which can be problematic in the long term. An accurate definition of DevOps is necessary.
How can you provide an accurate definition of DevOps for a non-technical audience? Long-term DevOps practitioner Alex Honor echoed earlier agile software development principles when he coined the phrase, “People over process over tools.” This mantra provides a handy list of DevOps priorities, and as such offers a useful framework for an easily understandable definition of DevOps.
Start with the People
Everyone loves a good organizational chart, and discussing how DevOps teams organize themselves is a useful way to understand how DevOps should work in practice. DevOps is very much about bridging traditionally separate development and operations departments, but this involves more than simply increasing collaboration between teams.
Related Content:
5 Biggest Ways to Fail at DevOps
DevOps Gets More Exciting in 2018
In a traditional setup, developers build applications and fix them when necessary, while operations teams work to maintain, support and monitor those applications.
In DevOps, the wall dividing these two worlds disappears. But it’s not just about getting dev and ops teams to work more closely—it’s about creating an environment where developers and engineers work alongside each other at every stage of a product’s life cycle. In other words, there should be no separation between dev and ops, just a unified DevOps team.
By emphasizing the people factor and contrasting a DevOps team structure with more traditional arrangements, it’s easier to visualize DevOps playing out in the real world. This is a great place to start when it comes to demystifying DevOps for a less-technical audience.
Move on to the Process
When put into practice, DevOps is supposed to be faster, more efficient and more reliable than more traditional software engineering methodologies—once the organizational structure is in place, these benefits can be achieved via innovative DevOps processes.
In traditional development and ops, manual tasks have a habit of slowing down processes, and getting in the way of high-frequency deployments. But in DevOps processes based on infrastructure as code (more on the tech later), teams can automate the provision and management of resources.
Take the task of provisioning server resources, for example. In the past, the developer would email the infrastructure team and ask for a certain set of resources in a specific configuration. Then someone in the infrastructure team would look at a document and follow a checklist of tasks before finally deploying the server.
In a DevOps process, not only are developers and infrastructure engineers working alongside each other in the same team, they’re also implementing processes through infrastructure as code (IAC).
Within the context of IAC, the provisioning of IT resources is automated via code, so rather than provisioning servers manually, the developer simply clicks a button. The desired infrastructure then spins up automatically, accelerating the overall process and giving DevOps teams the means to deploy far more frequently and efficiently.
By describing the automated processes made possible by IAC, the differences between DevOps and more traditional practices become much clearer. For less-tech-savvy employees, this explanation provides some much-needed context in terms of the day-to-day working of DevOps teams.
Then Talk About the Tools
Technology, and the benefits it brings in terms of automation and management, is a key driver of DevOps. The maturation of cloud computing and virtualization, and the emergence of infrastructure as a service (IaaS) in particular, provides the flexibility and speed demanded by DevOps.
With IaaS, it’s possible to instantly provision computing resources for highly customized and constantly shifting IT requirements, without on-premises hardware or manual configuration. This in turn enables the infrastructure as code (IaC) processes detailed above, and the level of automation required for DevOps teams to function.
So cloud computing, in the form of IaaS and by extension IAC, lays the technological foundations of DevOps. That’s the big-picture stuff, but what about those brand-name tools that non-technical people might have actually heard of? Docker, Kubernetes, GitHub, Jenkins, Travis CI … the list goes on, but how vital are these to the core concept of DevOps?
Arguably, not very. While containerization, source control and continuous integration tools all can perform very important roles within a DevOps context, they’re hardly defining features of DevOps itself.
Continuous configuration automation solutions such as Puppet and Chef come more directly under the IAC umbrella, enabling the automatic configuration and scaling of data center resources. But like the others, these tools would be equally at home in a more traditional setup.
In this sense, there’s no such thing as a “DevOps tool,” just tools that can be used within a DevOps organization for DevOps processes. It’s how you use them that really counts.
So when offering a definition of DevOps for a novice audience, don’t fall into the trap of simply reeling off a list of tools. DevOps is far more about people, organization and process. And while it’s very reliant on IaaS and IAC technologies, many of the tools utilized by DevOps teams are more or less incidental.
And Finally, a Reminder that DevOps Works
The ultimate goal of DevOps isn’t simply to unify development and operations, but to result in shorter dev cycles, more frequent deployments, higher-quality products and happier customers. More bluntly, the ultimate goal of DevOps isn’t just to say, “We do DevOps,” but to increase productivity and make the business more profitable.
Just look at sprawling organizations such as Google and Amazon. The success of these companies hinges on their ability to deploy new software multiple times every day, or even every hour. Amazon and Google may not agree on a precise definition of the term, but what they do agree on is that DevOps, as a set of unified software engineering practices, is crucial to their profitability.
With a consensus on the broad strokes of DevOps emerging over the last few years, lack of definition of DevOps will hopefully become less of an issue as its culture crystallizes. In the meantime, the good news is that the big ideas behind DevOps are also the most straightforward to explain to a non-technical audience.
By breaking DevOps down into people first, process second and tools third, an accurate and relatively simple definition of DevOps is possible. DevOps is fundamentally about people, how developers and engineers organize themselves and work as a unified team to deliver better products faster. It’s on top of this structure that DevOps processes are built, with a heavy focus on automation and innovative tools—always within the context of the core DevOps principles and practices.
— Neal Thoms
