This article will discuss what DevOps, Infrastructure-as-code (IaC), and GitOps are and what sets them apart. If you are someone already working in the field or managing software infrastructure, you may have encountered these terms already. They all have a similar objective: to improve the quality and speed of software delivery.

To understand the differences, we’ll first define each of these terms and expound on the value they add.

What is DevOps?

DevOps is a set of cultures and practices that improve how fast we deliver top-notch quality software to our end-users. This is done through the enhancement of continuous collaboration between (Dev) development and (Ops) operations, hence the name DevOps.

It harnesses the power of collaboration and automation to create a virtually seamless pipeline linking coding, testing, and deployment.

What is Infrastructure as Code (IaC)

Infrastructure-as-Code (IaC) is a concept where we manage and deploy the infrastructure through code instead of manual configurations.

Traditionally, when you need to set up a server, the admin will manually go through the steps of configuring the resources like CPU, Memory, Storage, and Network, then install the operating system and all the necessary software for it to run.

Sure, this is a doable approach when you have a few servers. But when there is a need to provision hundreds or more servers, this approach becomes extremely tedious.

Additionally, if you manage to provision hundreds of servers with the manual approach but suddenly want to make changes, you'd have to go through each server making the changes manually.

That can cause a configuration drift. A situation where servers that are supposed to be similar end up having different configurations. This can result in an application running perfectly on some of your servers and crashing on others.

The scenario above elaborates why the manual way is no longer feasible. This is where IaC comes into play. With IaC, we treat the infrastructure as if it's an application by defining it as code.

Let’s briefly discuss how to approach IaC.

Approaches to IaC

There are two ways of approaching IaC.

I. Declarative approach

Where we write code that describes how we want our infrastructure to be, and when we deploy it, the infrastructure will reflect how the code was written.

It involves defining infrastructure configurations in a code format, which can be version-controlled and automated for easier deployment and management. Some of the most commonly used formats are YAML and JSON. This approach allows for greater consistency, scalability, and reliability in infrastructure management, and can also help reduce manual errors and improve collaboration among teams.

II. Procedural approach

Where we instruct how the infrastructure will be configured in a step-by-step format. Here is how it works: A system admin connects to a server via SSH and manually types in each command in a command-line interface (CLI)to either create the necessary components, install packages or change some settings on 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.

Most Popular IaC tools

The most popular and widely used IaC tools are Chef, Ansible, Puppet, and Terraform. If you want to learn more about these tools in-depth, I recommend checking out KodeKloud's IaC Learning Path.

These courses will help you understand each tool using lectures and demos. You’ll get a hands-on learning experience and coding exercises that will validate your IaC skills.  Additionally, assignments will challenge you to apply your skills in real-life scenarios.

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 used to read from these manifest files. This is where GitOps comes in.

GitOps uses Git as the source of truth for infrastructure and application deployment. It is a way of managing infrastructure as code and automating the deployment process using Git workflows. 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 they would when you’re working with application code.

Changes to the infrastructure code are automatically tested and deployed in a controlled and repeatable manner. This allows you to manage your infrastructure and applications in a consistent and automated way.

There are two ways of implementing GitOps: Pull deployment and Push deployment.

I. Pull deployment

Pull deployment refers to the process of continuously pulling changes from the Git repository to the target environment. This ensures that the target environment is always in sync with the desired state as defined in the Git repository. This approach is easy to set up because it does need complex pipelines; a simple bash script running in an interval is usually enough.

II. Push deployment

Push deployment in GitOps refers to the process of pushing changes from the Git repository to the target environment. This approach is less commonly used compared to pull deployment, as it requires more manual intervention and can result in inconsistent environments if not managed properly. However, some organizations may choose to use push deployment in certain situations where it makes sense for their specific workflow.

Below is a graphical representation of the pull and push deployment strategies.

Benefits of using GitOps

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, allowing your infrastructure to sync and recover instantly.

The best part of all this 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 can sometimes draw the line between a good and a bad DevOps engineer. If you want to start using Git, ENROLL in KodeKloud's Git for Beginners course.

GIT for Beginners | KodeKloud

Learn Git with simple visualisations, animations and by solving lab challenges

KodeKloud

If you are looking to integrate ArgoCD and GitOps principles within your CICD pipelines, check out our latest ArgoCD course.

GitOps with ArgoCD | KodeKloud

KodeKloud

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.

Conclusion

In sum, DevOps is the primary foundation, and all of the process enhancements and automation we do, one way or another, reflect and improve or solve one of its primary pillars. IaC allows us to easily keep track, improve maintainability and achieve scalability in our infrastructure. GitOps empowers the IaC with Git features.

More on DevOps:

• 6 DevOps Concepts Every DevOps Engineer Should Know
• Is DevOps for you?
• DevOps vs. DevSecOps: Explaining the Key Differences
• What is Ansible in DevOps and How it Works