Understanding Everything as Code: A Comprehensive Review of Modern DevOps

*article updated on December 4, 2024

For decades, systems administrators have built bespoke systems to provide custom solutions for their employers or customers. These systems have some advantages. After all, they’re built by hand for a specific purpose. But those advantages come with certain trade-offs. Notoriously, hand-built systems tend to be finicky and temperamental. Ask any tech worker with a certain amount of gray in their hair about their nightmares related to server configuration, and you’ll quickly find yourself with more stories than you bargained for.

Now we’re going to take a little peek at history, and at how things continue to change. We’ll come to understand the way that today’s systems both run code, but are also defined by that same code. Before we can do that, let’s take a little glimpse into the past to understand where we’re coming from.

The first thing to understand about the concept of everything as code (EaC) is that it’s not a technology. There’s no backing company or clever bit of code that makes EaC a reality. Instead, EaC is a philosophy. The basic bit of this philosophy is actually pretty straightforward: you should express as many parts of your application and the infrastructure it runs on as you can in code.

The code that defines your infrastructure should be treated exactly the same as the application code your team writes. It should be checked into source control, it should be code reviewed, it should be tested, and it should be open for regular modification by qualified engineers.

If you’re used to working in a world where system administrators painstakingly maintain systems through scripts and manual intervention, this might seem like a radical leap. But in reality, this is simply a melding of many different ways of thinking about cloud computing systems over the last decade. The earliest versions of DevOps focused purely on quickly configuring a single system to work within an existing web of functional infrastructure. As they moved applications to the cloud, many teams shifted their approach from relatively few powerful servers to a swarm of microservices. This shift meant that configuration moved from just configuring a single server to configuring services that comprised many interconnected logical servers at the same time.

Over time, these practices of using code to configure as much as you could, and storing that code in source control just like any other code, came to be known as GitOps. When many people first hear about GitOps, they think it’s an alternative to DevOps, but it’s important to understand that they don’t work in opposition to one another.

One of the major flaws of the first waves of GitOps implementations was that configuration files and templates were considered logically distinct from the code that ran on their servers. To a certain extent, this made sense. The tools necessary to treat configuration the same as code were either immature or didn’t exist yet. Today, that’s no longer the case, and many teams who practice DevOps practice some form of GitOps in addition. Radical adoption of GitOps, where every part of your application—the configuration for the infrastructure it runs on and the systems used to deploy it—are all housed in the same code repositories is known as everything as code.

If you’re an engineer or manager, and you’re just learning about EaC in a professional context, I bet you’re thinking a common thought: that sounds like a lot of work. And you’re right! Adopting an EaC mindset does require a lot of work to do properly.

Many teams that haven’t adopted DevOps at all have a handful of servers running in various states of configuration that aren’t so much planned as grown. It’s likely that at least one part of your existing application relies on a very specific version of a software library or operating system patch. If you update the underlying infrastructure, your whole service goes up in smoke, and suddenly a bunch of people with fancy titles want to know why you haven’t fixed the problems yet. Getting from where you are to where everything about every service is defined in code and regularly modified is a tall hill to climb. So why do all that work?

What companies that adopt EaC find is that the work definitely pays for itself. The first-order benefit shows up for engineering teams. Put simply, your deploys work. They work nearly every time, and when they don’t work, they’re really easy to roll back.

Instead of taking hours and hours and, in some cases, requiring downtime that eats into profits, they happen in minutes. In many environments, they happen a dozen times per day or more. What’s more, because the entire system is defined in code, a deploy takes no more intervention than a git push command. And every change undergoes the same scrutiny as your application code changes. You perform the same pull request process and the same change review before deploying. 

These benefits tend to have terrific knock-on effects for companies that adopt them. Reducing cycle time has benefits for companies, as those changes allow them to respond to market inputs much more quickly. But that’s not the only benefit. Adopting EaC philosophies also reduces other negative effects, like code churn. 

Reducing code churn might not feel like an obvious outcome of adopting EaC, but it makes sense when you think it through. Specifically, EaC means that it’s much easier for you to recreate complicated systems in multiple environments. That means that your development, testing, and production environments can be effectively identical. The identical nature of those environments removes an entire class of defects where bugs either do or don’t exist based on some unique quirk of a particular environment. 

While EaC doesn’t mean that you’ll never ship a bug again, it does provide another benefit. Because everything about your system is stored in version control, it’s easy to understand the history of how and why a particular configuration changes. You look in the exact same place that you look to understand why your application code changes. When you’ve fully adopted the EaC mindset, the changes to the underlying infrastructure will show up with the exact changes to the application code that utilizes the new infrastructure.

This means that if you accidentally deploy some new feature that includes a breaking issue, you don’t have to identify whether the underlying cause relates to the infrastructure or the application change. You can roll back the entire change in one commit.

We’ve hinted at this before, but it’s useful to lay out what exactly makes up the EaC portfolio. While EaC is a philosophy, it usually comprises a few different approaches to DevOps all combined together.

• Infrastructure as Code (IaC)

  • The goal of adopting infrastructure as code is to ensure that the servers and services your application relies on are defined by the code that they run.

• Configuration as Code

  • This is the natural evolution of the IaC approach above. Instead of simply defining the cloud resources your application needs, you actively configure them in the code as well. 

• Pipelines as Code

  • Adopting a continuous integration/delivery pipeline is a common benefit of a DevOps adoption. Instead of manually deploying code to servers, your continuous deployment pipeline pushes that code out to the appropriate environment as soon as developers merge it. Pipeline as Code also configures those pipelines within the code repository, just like the service infrastructure and configuration above.

EaC isn’t a one-size-fits-all solution. Yes, it comes with a bevy of benefits that more than pay for the work you’ll sink into it. You’ll ship code more quickly, and your customers will experience fewer bugs and have a better overall user experience. But that doesn’t mean it’s the right fit for your particular use case. Not every product benefits from shipping faster, and for those who don’t, EaC is not the right approach.

If you’re thinking about EaC, it’s likely that you’re also thinking about how to manage features as they roll out. That’s where CloudBees brings a wealth of knowledge to the table. When you’re moving fast, you still need to be safe, and you still need to effectively experiment to find the best way to connect with your customers.

Adopting an Everything as Code mindset can revolutionize your software development process, but achieving it requires the right tools and expertise. CloudBees simplifies this transition with integrated solutions for feature management, CI/CD, and secure deployment. Whether you’re implementing Infrastructure as Code, Configuration as Code, or Pipelines as Code, CloudBees provides the resources and guidance to streamline your workflows and enhance system reliability.

With CloudBees, your team can move faster without compromising safety or quality, enabling efficient rollouts and minimizing risks. By aligning your infrastructure, code, and workflows under a unified approach, CloudBees helps you unlock the full potential of EaC. Start your journey today and transform how your organization delivers software.

This post was written by Eric Boersma. Eric is a software developer and development manager who's done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he's learned along the way, and he enjoys listening to and learning from others as well.