GitOps vs ChatOps

In this guide, we will be looking at GitOps vs ChatOps and how you can scale your infrastructure toolchain using CTO.ai.

GitOps

The idea behind GitOps is using Infrastructure as Code for all the scripts that you need to create, update or delete your infrastructure. You can use a number of tools to help you with this like Terraform, Pulumi, and Yaml. Your infrastructure files, application files, and state of the infrastructure are saved in Git.

If you think about a traditional CI/CD flow for EKS, it’s more of a push model where the AWS code build is pushing the deployment and manifest file to your Kubernetes Cluster.

The short explanation of GitOps is Infrastructure as code done right with all the best practices. The Infrastructure as code concept is when you define your Infrastructure as code instead of manually creating it. This process makes your infrastructure much easier to reproduce and replicate.

Infrastructure as code evolved into defining not only Infrastructure but also network as code or policy as code, configuration as code, and security as code. These are all types of definitions as code. For example, instead of manually creating servers, network, Kubernetes Cluster, and all your configuration on AWS, you can define all your configuration in a Terraform, CDK, CDKTF code and Kubernetes manifest files.

How does IAC work?

How do many engineering teams write and use infrastructure as code? As a DevOps engineer, you will create these files locally from your machine, test them and execute them from your computer. All these files are stored locally on your computer or you may create a git repository for your infrastructure as code and store all your files on Git. You have version control for your Infrastructure code and other team members can fetch the code as well and collaborate. But when you make any changes to the code, you may not have a defined procedure like pull requests. You may have the main branch when you change the code. You may also commit it directly into the main branch and when someone else in your team changes the code they can also commit directly into the main branch. Implementing this kind of procedure will result in no code reviews as well as no collaboration on the changes.

When you commit your infrastructure as code changes into the repository, no automated tests are running to test your code changes. If you committed invalid YAML files, made a typo, or the names of the attributes are wrong, you won’t be able to know what went wrong in your deployment and these code changes can break something in your Infrastructure or application environment.

Executing these changes can also be done manually from your laptop. However, in order to execute the code changes, each team member must access the Kubernetes Cluster or AWS Infrastructure and apply changes from their local machines. This can make it challenging to trace who executed which commit or fixes. So even if you already have your Infrastructure as code, which already has lots of benefits, our process is still mostly manual and inefficient.

What is GitOps

In GitOps practice, treat the infrastructure as code the same way as the application code; have a separate repository for the infrastructure as code (Terraform, CDK, CDKTF) project and a full DevOps pipeline for it.

Implementing GitOps

With GitOps, your Infrastructure as code is hosted on git repository where it’s:

Version Controlled.
Allows team collaboration.

When you make changes instead of pushing to the main branch, you go through the same pull request process as your application code in a different branch. So anyone in the team, including Junior Engineers, can create a pull request, make changes to the code and collaborate with other team members involved on that pull request. For each change pushed to a new branch, you will have a pipeline that will validate the configuration files and test them just like you would test your application code changes.

After testing the commits, other team members can approve the final changes. By using the GitOps process, you have a tested and well-reviewed configuration change before they get applied in any environment. After approval, your changes will be merged into the main branch through a CD pipeline and will eventually be deployed to the environment.

The GitOps process enables an automated process that is more transparent and produces high-quality infrastructure or configuration code where multiple people can collaborate on the changes and testing rather than one engineer doing all the configuration from their laptop manually.

GitOps (Push + Pull)

The developer checks in on the code in their repository, the container image is built and gets pushed into a repository but the continuous deployment is different. In GitOps, CD software is constantly being run and checks with your repository to keep your applications like your Kubernetes Cluster in sync. Using GitOps, the CI part remains the same.

CD Pipeline: Pushing vs Pulling Paradigm

Once your changes are merged into the main branch, they will automatically be applied to the Infrastructure through a CD Pipeline. In GitOps, we have two ways of applying these changes: Push or Pull based deployment.

Push based deployment is what we traditionally know from the application pipeline. In this deployment, the application is built and the pipeline executes a command to deploy the new application version into the environment.

Pull Model

In the pull model, an agent like CTO.ai Service is installed in your environment and your Kubernetes Cluster for you to instantly preview your changes and get your applications live, quickly and easily. In the pull model, it actively pulls the changes from the git repository itself. The Service agent will monitor and compare the desired state with the actual state. It will regularly check the state of your infrastructure code in your repository and compare it to the actual state in your environment where it’s running. If it sees a difference in the repository, it will pull and apply changes to get the environment from the actual state to the desired state defined in the repository.

The pull-based model watches the state of your infrastructure and applies those changes.

GitOps doesn’t only work with Git, it also works with code repositories such as AWS code commit.

ChatOps

ChatOps is actually a flow of interactions that starts with the Ops team that uses chat applications to make certain decisions and discuss operations. On the other hand, there is a chatbot that is listening to those conversations and executing the others on the Infrastructure.

ChatOps is a collaborative, conversation-eccentric way of working that brings people, discussions, bots, tools, and files together in one central location.

Without ChatOps

The interaction between team members still happens but they are less structured and often team members just talk to one another and different parts of the Infrastructure is changed by different people so it’s hard to follow what has been done in your environment. That’s where problems arise.

Benefits of ChatOps

Transparency (History of commands)
Visibility (Knowledge of sharing)
Promotes automation hides complexity.
Shorten the feedback loop (faster time to response)
It is a shared console or command line.
It captures the history.
All the required people in one place.
Meantime to restore drops dramatically.
It’s a methodology, not a technology.

With transparency, there are no hidden actions like a developer in your organization doing something and telling you some days after that they did it. Everything is clear and reviewed as it happens.

It’s also a perfect way of providing visibility, especially for newcomers. They can simply just jump into the channel and see how the business is done, what are the operations executed, what tools are used, etc.

It structures your workflow in a way that everybody can use it just by typing some commands in a chat application.

If you are managing an incident having an outage, ChatOps shortens that feedback loop by giving you that faster response time. When you are implementing ChatOps, you have everyone in the same channel and everyone can see the command history.

Ideal World of ChatOps

In an ideal world of ChatOps, you have your:

In an ideal world, this is what ChatOps would look like. You have your team of people off to the left. This can be SREs, Support, DevOps, and Engineers. They are usually interacting with a messaging tool like Slack which can be channel-based or topic-based. Your slash commands and bots on the other hand are interacting with your infrastructure.

ChatOps is taking tools you already use in your day-to-day workflow and moving them into a more conversational tool.

ChatOps really caters to the way that we’re already consuming information as well as providing information. It helps break down silos between developers, operations, and customer support staff.

ChatOps uses the processes that developers are already familiar with like ticket tracking, incident management, and it puts them in-line in conversation around the issues that developers or operations people are using.

How CTO.ai enables GitOps and ChatOps

CTO.ai is your ideal Developer Experience for enhancing your Infrastructure as Code (Terraform, CDK, CDKTF) workflow.

We work with frameworks like CDK, CDKTF, and Pulumi which lets you easily compile your declarative infrastructure operations, without worrying about your deployments and workflow.

CTO.ai enables ChatOps by integrating all the existing DevOps systems and applications you have and allows you to have public and private communications.

Running our conversational CLIs structures your workflow in a way that everybody can use it just by typing some commands on Slack. This makes it simple to turn your existing scripts into beautiful, interactive conversational GitOps workflows so your entire team can self serve their DevOps, in Slack.

Here at CTO.ai we enable you to manage your source code, track your deployment and collaborate with your team using our ChatOps mechanism. We integrate GitOps into your resources using our operational practice by driving operations, configuration, and management using a Git repo. We leverage Git repo’s version control system, peer-reviewing system, and history to automate the deployment process for your development, staging, and production environment.

Using CTO.ai will take care not only of the Continuous Integration (CI) part but also the Continuous delivery (CD). When you set up CTO.ai, you will be prompted to point to a code repository and it will ensure that the cluster config matches that code repository and automates your deployments.

The workflow process is done using our continuous delivery and automated pipelines which we enable for your application deployment as well. We also enable Webhooks to let you push your configurations into a dev and test environment and once you merge that particular pull request into the main branch the deployment to production happens.

Using our Ops workflow Delivery workflow you can configure, build, test, deploy your applications, and automate your deployments.

We play a vital role in enabling efficient communication across your teams by enabling your team to release from slack. We’ll set up a fully managed workflow that enables your team to release any cloud directly from Slack so that you know when new features are being delivered.