Deconstructing DevOps: Configuration As Code

Configuration as Code

IT evolves. We write better code, create new tools, new languages, and new and better libraries. The speed of progress is surprising—so are the things that turn into trends. I want to talk about one such concept that has gained lots of traction. You know what it is already because it's in the title ;)

What Is DevOps?

Although there is no uniform definition of what DevOps is, I think a lot of people will agree that Wikipedia describes it pretty well:

“DevOps (a clipped compound of “development” and “operations”) is a software development methodology that combines software development (Dev) with information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.”

There are many components that constitute the term DevOps:

  • Continuous Integration
  • Containerization
  • DevOps culture
  • Improved deployment frequency
  • …and many more

Each of them deserves its own article, but here I wish to talk about infrastructure as code or more broadly—configuration as code. I’d like to show you the advantages *you* can get by implementing this concept in your projects.

Configuration As Code

The days of manually provisioning the production machine and deploying code are long gone. No company can afford anymore to spend hours to spin up a new AWS instance. Life taught us that we needed configuration management solutions that are fast, automated, and repeatable (thus deterministic), allowing us to easily scale and encouraging collaboration between developers and operations.

A couple of companies saw an increased demand for software that would fulfill the above criteria—they created solutions specifically designed to help you manage your infrastructure and deployment process in a safe and scalable way.

Worth mentioning here are Ansible by Red Hat as well as Consul, Terraform, Vagrant and Packer made by Hashicorp. There are also Puppet, Chef, and a bunch of others. The abundance of tools suggests that automating configuration management is a real issue that can be helped by using the proper software. Now let me try to convince you that you indeed need to use at least one of the above tools to manage your projects more easily 🙂

Configuration Drift

Configuration drift is the phenomenon where servers that are running in infrastructure become more and more different as time goes on, due to manual ad-hoc changes and updates and general entropy. This leads to subtle configuration bugs that are difficult to diagnose and nearly impossible to reproduce. Fortunately, this can be easily helped by applying the following:

Version Control

By storing changes to the environment in the code, you never lose track of what’s been done on the machine. You can store configuration code in a version control system such as Git. It allows you to track which changes have been applied at which stages of an application’s life. To improve on this further, you can properly tag and version the code. Faults can be found and fixed more quickly, and in the worst case, changes can be reverted to the last working configuration.

It’s common to put the configuration code in the same repo as the project’s codebase. This allows for collaboration between devs and operation as everyone who has access to the repository can contribute.

Code Syntax and Features

Because the configuration is written as code, you can use all best development practices to improve it, e.g., creating reusable definitions and doing code review. Moreover, because it’s code, often you can utilize elements common in programming languages: loops, variables, and conditional checks.

Software such as Ansible requires that its deployment plans are deterministic,

that is, plans must produce the same result each time they are run, independent of the initial conditions present on the machine. If for some reason a plan fails, it produces an error and further execution of plans is halted. That way, in Ansible, using coded plans is safe, because you don’t need to care about which part of the plan is needed to be run on the target machine.

Many Instances

You probably use more than one server in the deployment process of your project. In the case of having instances for production and staging environments, it’s a lot easier to promote changes using configuration as code. You can deploy plans to a staging instance, verify changes, run automated tests, do whatever you have in your pipeline. After checking that everything works you can repeat the same steps on the production instance just by changing the target URL.

Use IDE Features

Editing build plans in an IDE allows you to utilize features like code autocompletion, easy refactoring, syntax checks, function searches, parameter tooltips, and so forth.

Configuration As Code: A Recipe for Improved Efficiency and Productivity

Using configuration as code makes changes safer and faster, shaving off precious time and, in consequence, saving money. Click To Tweet

As Martin Fowler writes, “All of this increases in importance as you need to handle more servers, making infrastructure as code a necessary capability if you’re moving to a serious adoption of microservices. Infrastructure as Code techniques scale effectively to manage large clusters of servers, both in configuring the servers and specifying how they should interact.”

To start your journey with configuration as code, check out these two tools:

Ansible—this is a configuration management tool, that is, it automates machine provisioning and code deployment. Instead of setting up the machine from scratch—installing necessary packages and manually delivering application code to your machine—you can code all of these steps and execute them in an automated, deterministic manner. Ansible got very popular in a short time, overtaking Puppet and Chef by a large margin. In my opinion, it’s a go-to tool in terms of automating configuration management.

Terraform—an infrastructure management tool. It provides means for building, changing, and versioning infrastructure with code. You can quickly spin up a new AWS instance by executing a plan from the command line. Terraform can manage popular service providers (AWS, Azure, Google Cloud) as well as custom in-house solutions. The list of supported providers is pretty big.

Let’s Talk About Your Project!

Have an exciting project in mind? Or maybe would like to improve your current setup?
We’d be happy to discuss it with you. Let’s get in touch!

accept



Our Privacy Policy has been updated in line with the new General Data Protection Regulation(GDPR)