DevOps Vs Infrastructure-as-Code (IaC) Vs GitOps

Introduction

In this article, we will be discussing what DevOps, Infrastructure-as-code (IaC), and GitOps are and what sets them apart. If you are someone who is already working in the field or that manages software infrastructure, you may have encountered these terms thrown around. All of these have similar aims: to improve quality and the speed of software delivery. And For us to find the difference, we’ll need to be able to understand what each term represents.

What is DevOps?

DevOps is a set of cultures and practices to improve how fast we deliver top-notch quality software to our end-users. This is done through a set of processes or bridges that will allow continuous collaboration between (DEV) development and (OPS) operations, hence the name. The goal of a DevOps engineer is straightforward. It is to simplify and automate everything. This includes not only the software application that is being built but also the different processes within teams.

At the core of DevOps comes the primary pillars and the end goal would be to integrate these processes as part of the software infrastructure. If done correctly, it would bring tremendous value to any company that adopts it.

What is Infrastructure as Code (IaC)

Infrastructure-as-code is an idea where we build our software infrastructure through config files or manifest files. But before we dive deep into its concept, let’s first understand the two common approaches to managing our software infrastructure, the imperative way, and the declarative way.

The imperative way means that infrastructure is provisioned in a step-by-step approach, in its most straightforward example, a system admin connects to a server via SSH, types in manually each line of command in a command-line interface (CLI) that will either create the necessary components, install packages or change some settings into the server.

Of course, it doesn’t have to be manually typed in, and the process can be automated to a certain extent like an admin can create a bash script to execute these commands, but the style remains the same, each command is fixed, and is run consecutively.

The downside to this approach is, that it is not as flexible. Each command is static and if you are to make any changes to one server, you’ll have to go in and make changes manually, and if we’ve done quite a few changes to that particular server, this may cause the server to deviate, making the server different from the others, this is what we call a configuration drift. This may not become a problem if we’re only dealing with a handful of servers. But if we think about it with regards to scalability in hundreds or thousands, then it becomes chaotic and almost impossible to manage.

Then there’s the declarative way, and this is what the concept of Infrastructure as code follows. What this means is that we provide our servers or applications with the use of manifest or config files, these files often contain changeable variables and instructions to completely provision an application or server from scratch, It doesn’t follow the conventional bash commands lined up and be executed in a bash script, but instead follows a form of key/pair values that is commonly in YAML or JSON format. Afterward, It will then make use of a tool or software capable of reading the file and then do all the necessary work to your infrastructure.

The most popular and widely used IaC tools are Chef, Ansible, Puppet, and Terraform. Each has its techniques and approach and even has its format of the file is read. If you want to learn more about these tools in-depth, I recommend checking out KodeKloud, they have courses for all of the tools mentioned here that are very thorough. They have labs straight to your browser for practice, allowing you to learn these tools as quickly as possible.

With Infrastructure-as-code (IaC), you maintain a file that can be referenced by a multitude of servers. One of the main benefits of this is, that you are assured that if it works on one server, it will then work the same way with another. And if let’s say, you no longer want a component to be included in the process of provisioning, you can easily make changes to the file and the tool will then apply the changes to the server based on the contents of the file.

Since the manifest files are usually tiny in size, this allows us to have a very testable infrastructure as well, as we can spin up a server from the config file and if it doesn't work, perform some changes then repeat the process until the output becomes satisfactory. This solves the problem with replicability and scalability of our infrastructure as one file is enough for you to provision clones of servers very quickly.

What is GitOps?

GitOps is a process where infrastructure as code principle is enhanced further by combining it with the benefits that Git provides. We explained that with IaC, we make use of manifest files that define everything about our infrastructure, any changes we want to apply are done through these files and will be applied to individual servers. However, the admin would still need to manually place these files in and execute whatever “apply” command depending on the tools being used to read from these manifest files.

With GitOps, the automation process becomes much simpler and streamlined. For the admin to make changes to the infrastructure, it no longer has to be done manually, all is needed is to commit those changes to the specified Git repository as you would when you’re working with application code, then the application or infrastructure will react to these changes by continuously syncing the changes on that same repository. There are two types of ways we can perform syncing in GitOps, the Pull deployment, and the Push deployment approach.

The pull deployment as the name suggests is configuring your application or infrastructure to constantly pull or sync from the Git repository. Any changes that are done to the repository will then be pulled to the entity that needs it. Getting started with this approach is fast and simple, as there’s no need to set up complex pipelines, as a simple bash script running in an interval is usually enough.

Then there’s the push deployment. This is achieved by building or utilizing automated pipelines in your Git repository that deploy changes directly to your infrastructure whenever there are changes. Choosing this approach may require more time to set up.

One of the main benefits of Git is to allow versioning, transparency, security, and continuous integration. With GitOps, we inherit the same benefits applied to our infrastructure. You can now support having multiple admins working on the same environment simultaneously through the Git branching process by pulling the repository to their local workstation, editing the files then submitting a merge request that can be then reviewed and approved by others. This allows your infrastructure to be more secure since only approved changes are committed to the environment. If a change causes massive problems or causes your infrastructure to crash, you can easily roll back the changes to the repository, allowing your infrastructure to sync and recover instantly.

The best part of all these is you only need to learn Git to get started with GitOps. Proficiency in Git is one of the primary skills of DevOps engineers. Getting your fundamentals right at the start can sometimes draw the line between a good and a bad DevOps engineer. If you want to get started with using Git, KodeKloud also has an amazing course for beginners.

For amy aspiring learners looking to integrate ArgoCD and GitOps principles within their CICD pipelines, check out our latest ArgoCD course here.

Bringing them together: DevOps Vs Infrastructure-as-Code (IaC) Vs GitOps

Now that we’ve discussed and understood these different concepts. Let’s summarize and put them side by side to see the key differences between them.

Conclusion

In the end, DevOps is the primary foundation. All of the process enhancements and automation we do should one way or another reflect and improve or solve one of its primary pillars. Infrastructure-as-code introduces us to a practice that will allow us to easily keep track, improve maintainability and achieve scalability in our infrastructure. And finally, GitOps further empowers the infrastructure-as-code approach with the features of Git to allow Continuous Integration between developers as well as provide Continuous Delivery with the help of pipelines that automatically deploys the changes to the infrastructure.