DevOps In the Wild
Whether you’re a developer early in your career, a student new to the joys and struggles of programming, or a non-technical person that works with programmers, you’ve likely encountered the trendy term “DevOps” (short for “developer operations”). It’s also likely that you have a very vague and incomplete sense of what DevOps actually refers to.
If you are feeling like you are clueless when it comes to understanding DevOps, you’re not alone. We’ll explore some fundamental ideas behind DevOps and how they intersect with the role of the average developer. While there will be plenty that we don’t get to, we hope to provide a sound, fundamental understanding from which you can dive into some of those aforementioned explainers on your own.
What Is DevOps — Or, What Isn’t It?
There is no succinct answer to this question. In fact, the Wikipedia entry on DevOps avoids the question entirely by stating, “Academics and practitioners have not developed a unique definition for the term ‘DevOps’.” What can be definitively said is that DevOps is not a programming language, framework, or platform. It is not a well-defined process, nor is it enabled by using a specific tool. And yet, while it isn’t any of those individual things, it is indeed a collection of all of them.
DevOps is a practice and methodology that aims to help developers deliver software safely and efficiently. In that sense, it has been compared to agile, which is also a broad, umbrella-like term used to describe a set of processes, tools, and philosophies around project management. (If you have questions about agile, we have an article for that, too!)
DevOps is a practice and methodology that aims to help developers deliver software safely and efficiently.
To understand what DevOps is really about, we first need to understand how software is “delivered.”
UPS for Software
When first learning to code, you build and run applications on your computer. If you are building a web app, you run and test it on “localhost,” the name that allows your computer to access itself via a web browser. (We’ll focus on web apps for this article, but similar concepts apply to mobile, desktop, and other application types.) Absent some additional configuration, that in-progress application is only available to you, on that specific computer. This is great since it allows us to run and test our apps quickly: code, save, rebuild, and refresh the browser. It’s that simple.
But when your app is ready for others to use, localhost just won’t cut it. In order for others to use our web app, it needs to be hosted on a web server. Getting working code onto an accessible web server is what we mean by “delivering” software.
Delivering Software the Old Way
Traditionally, the work of getting an app onto a server required developers to work with other technicians known as system administrators (aka sys admins). A sys admin would set up and configure a server for the application’s needs, creating user accounts, installing packages, and configuring the system software to allow external access to the server via the web/HTTP. The sys admin would then work with the developers to get their code onto the web server, where it could be widely accessed.
The server in question might be owned and managed by the company, located on its property, or it might be leased from a third-party provider and located in some building on the other side of the country. In either case, the process looks the same.
Delivering Software the New Way
The advent of cloud computing has lead to a shift in how server resources are managed, for the better. Rather than having to buy or lease entire machines, companies can use services provided by companies like Amazon Web Services (AWS), which allow for flexible allocation of resources. The servers in question can be thought of as abstractions of a physical server sitting on a shelf, without many of the limitations of a physical, owned device. Want to create a new server? It’s as easy as clicking a button on a web page. In fact, you can choose from a menu of servers, pre-configured to work with specific application stacks. Of course, somewhere behind the abstraction of the cloud is a bunch of real, physical servers sitting on a shelf. The difference with the cloud is that we don’t have to worry about those details, which are handled by a cloud computing provider.
With the growth of cloud computing has come a revolution in computing services. A sys admin is no longer needed for most or all of the tasks involved in setting up a basic web application on a server. A developer with little to no sys admin knowledge can, following a set of basic instructions, deploy an application to a service like Heroku, Pivotal Cloud Foundry, or Azure.
Beyond the simplicity behind allocating server resources and deploying an application, these providers also enable many other processes to be scripted and thus automated. Want to create a new server with the exact same configuration as the one you’ve already built? You can write a script to do that. Want to carry out a set of related tasks whenever you deploy new code? You can write a script to do that too. Want to script the entire deployment process? Yep, you can do that too. The ability to script (read: automate) repetitive tasks related to application deployment is a key pillar of DevOps.
The ability to script (read: automate) repetitive tasks related to application deployment is a key pillar of DevOps.
Deployments with Bug Repellant
Beyond enabling more consistent deployment practices—a script will always do the exact same things, time after time, nullifying the possibility of human error—the new way of deploying applications also allows for quicker, more frequent delivery of applications. Beyond speed and convenience, DevOps principles also focus on safe, stable deployments. It’s no good to be able to deploy applications quickly if those deployments introduce bugs.
Bugs are prevented by both the production of good code, and by good testing. Testing can be manual—with quality assurance analysts and testers working through test plans prior to deployment—or it can be automated, with large sets of test scripts verifying the integrity of an application. Automated tests are clearly preferable when taking a DevOps approach to deployment. Automated tests not only reduce human error and increase efficiency, but they also allow tests to be integrated into an automated sequence of tasks that enables automated software delivery via tools known as continuous integration (CI) servers. That process, in its simplest form, looks something like this:
- The developer writes and commits code.
- Continuous integration server sees the commit and checks out the new code.
- CI server builds and then tests the app.
- If the previous step is successful, the CI server automatically deploys the application. If it fails, developers are automatically notified of the failure.
This process is referred to as continuous delivery, and it allows companies like Netflix and Amazon to safely deploy code hundreds of times per day. How big of a deal is that? Without DevOps practices, manual deployments might take place once per week, or even less frequently. Quicker, safer deployments allow software to adapt more quickly. Software evolves in smaller, more regular increments, and large, manual, risky deployments become a thing of the past.
This process is referred to as continuous delivery, and it allows companies like Netflix and Amazon to safely deploy code hundreds of times per day.
DevOps In the Wild
For the DevOps practices that we’ve discussed to come into play, developers and sys admins have had to adapt their day-to-day work. The role of a sys admin in our deployment story has been usurped by that of a DevOps specialist, while developers have had to become fluent with DevOps principles that affect how they write their code.
DevOps specialists are engineers that focus on setting up and configuring DevOps deployment pipelines for software development teams. They work in close concert with developers to seamlessly integrate their development practices into a tightly-configured pipeline. Most of these specialists are intermediate-to-senior-level technicians that started out as either developers or sys admins and had a mindset that attracted them to automation and quality. One senior DevOps engineer described the perfect candidate for a conversion to a DevOps role as someone that, when tasked with something repetitive, would write a script to do the job.
Developers have also needed to evolve their approach to writing code. Not every code base is a good candidate for a DevOps approach, and specific considerations are needed to ensure that automated testing and deployments are effective. Among these are test-driven development and the understanding of twelve-factor app methodology. Familiarity with containerization tools, such as Docker, is often also necessary.
If you are a developer, you now have a basic understanding of what we mean when we talk about DevOps. It’s a complicated and evolving picture and one that has permanently changed how we write and deliver software. Armed with this understanding, you can now safely dive into one of the more comprehensive DevOps explainer articles out there (NewRelic’s is a good place to start). If you’ are not a developer, you have a more clear perspective of how this evolution of processes and tools has affected software development.