On the surface, GitOps and IDPs - or Internal Development Platforms - couldn’t be more different. Both these approaches are brilliant ways of adding more consistency and creating developer-first workflows, but it can sometimes be hard to picture exactly how these can be used as part of the same team setup. 

After all, GitOps was developed to allow developers to utilize infrastructure as code (IaC) through Git, while IDPs aim to handle as much complexity as possible so developers don’t have to. So, you’ve got two DevOps powerhouses at different ends of the tooling spectrum. There’s no way they can work together...right?

In part one of our webinar series on GitOps and IDPs, Kostis Kapelonis, Developer Advocate at Codefresh, and Chris Stephenson, CTO of Humanitec, sat down to discuss how, and why, you should use these tools together to strengthen DevOps. 

What is GitOps?

GitOps is a set of guiding principles that work together to create a developer-centric Continuous Deployment setup. By using Git to manage infrastructure provisioning, configurations and deployment automation, the GitOps approach aims to provide a single source of truth as code. Thereby developers can continuously deploy code changes and requisition infrastructure without these requests getting stuck in a ticket queue in the operations team. 

Kostis explained that GitOps works on five core principles:

  1. Declarative. Instead of using imperative, ad-hoc scripts, operators tell the system what they expect to see as the end result, and GitOps formulates this behind the scenes. Instead of telling it how to get there, operators define the state they want to see. 
  2. Versioned and immutable. By storing the desired state using version control tools, operators can retain a complete version history for each state and deployment. 
  3. Deployed automatically. Instead of pushing manual changes, the system automatically pulls changes from the Git repository and deploys them straight to the desired location. 
  4. Continuously reconciled. The system keeps all environments in the same state continuously until the Git repository is changed. 
  5. Operated in a closed loop. The system and state work communicate bidirectionally, allowing any changes made to the source to be pushed to the system, and vice versa.

While Kostis admits that GitOps isn’t always applicable for every situation - which he covered in more detail during the Q&A - he explained there are significant benefits to using GitOps principles, such as:

  • Full history and auditing. By using Git, operators can see exactly who pushed what, when, where, and how. So, if there’s a problem further down the line, operators know exactly who they need to talk to, or what they need to inspect. 
  • Simple deployment and rollbacks. Because system states will pull changes from Git automatically, it’s easy to deploy changes to different environments. And, if anything goes wrong, operators can quickly roll everything back to its pre-deployment state.
  • Avoids configuration drift. When operators push changes manually, it’s easy to end up with push changes that fail in some environments but not others. In Git, it’s easy to see if two systems are different before changes are deployed.
  • Detect manual changes. If someone does push a manual change, GitOps will detect and log this so operators can either roll the system back or push the change to a Git repository.

With that being said, GitOps isn’t appropriate for every setup. Sure, it works well for simple setups, but when developers start working with multi-environment configurations, GitOps can make this unnecessarily complicated. Similarly, GitOps often struggles in complex enterprise setups where confidential information like database passwords need to be managed outside of a business CD setup. That’s not to say that GitOps can’t be adapted to work in these situations, but rather that there are other approaches that may be more suited to large enterprises. 

What is an IDP?

An Internal Developer Platform, or IDP, is a self-service layer that allows developers to spin up new environments and deploy code changes on their own. Instead of requiring ops to clone databases, or needing developers to sift through YAML files or documentation to figure out how to push code changes, an IDP empowers developers to self-serve environments, deployments, databases, logs and anything else they need to run their applications. . 

IDPs like Humanitec confer a ton of benefits to the DevOps ecosystem, like:

  • Easy infrastructure provision: When used in tandem with infrastructure as code (IaC), IDPs make it simple for developers to create databases or test environments without needing to requisition them from ops. 
  • Reduces operations load: Similarly, operations aren’t overloaded with menial tickets asking for new databases or environments, allowing them breathing space to get on with more vital tasks. 
  • Supports a continuous delivery system: By giving devs the power to run their own deployments and push them when they’re ready, it becomes easier to maintain an efficient delivery system.

Can GitOps and IDPs work together?

In short - it depends.

Chris and Kostis both believe that GitOps and IDPs work well together, and can make most DevOps setup more efficient when these concepts are used in tandem. However, like most DevOps principles and tools, there are situations where devs or ops may not want to utilize them. 

Kostis pointed out that GitOps might not work in all situations:

“In production, you should be using GitOps. For staging or temporary environments, it’s up to you...when I say temporary environments, I mean environments where you create a pull request to test your own changes, ones where the environment is up for two hours, four hours, or a day. If you don’t need full history or auditing, then you might not need GitOps”.

Similarly, Chris mentions that IDPs might get in the way in some situations:

“Having an IDP...gives you a semantic understanding of differences between environments, so you don’t need to be an expert...On the other hand, if you have a very subtle bug from a small change that’s been deployed, it doesn’t make much sense to use an IDP to debug that because you’ll need to go to the low-level files”.

With all of that being said, however, using GitOps and an IDP like Humanitec together offers a ton of benefits for most DevOps environments. Plus, implementing the two together is as easy as using an IDP as a layer over GitOps protocols. 

Both Chris and Kostis agree that the biggest benefit that IDPs and GitOps offer is that using the two together gives DevOps professionals a ton of flexibility. 

Kostis explains it like this:

“ [Developers] can work on the level they choose. So, if I’m a dev that wants to look [at files] on a deeper level, I can, but if I want to just focus on code, I can do that too. It gives you a lot more options as a developer. Meanwhile, in ops, I might not care about the application, so I can choose to just work in GitOps and not touch the IDP.”

This can save a ton of time, particularly in instances where developers would ordinarily have to fish through YAML files to find resources. It leaves developers with the option to work on a more granular level if they want to gain a deeper understanding of how everything works together, but it also facilitates a greater focus on the project at hand. 

However, the biggest benefit that Chris and Kostis agreed on was the level of consistency both GitOps and IDPs provide. 

Chris explains this in terms of using guardrails in DevOps, or having operations define specific pathways that developers can use to generate infrastructure resources. This gives developers space to move outside of those pathways if needs be, but generally maintains a level of consistency that reduces the risk of bad deployments. 

When devs can generate a new environment on the fly, it makes it easy for them to get on with work without worrying about making sure all of these new environments, databases, or other infrastructure elements are being run consistently. So, IDPs can fully manage the provision of these resources, while GitOps works behind the scenes to ensure that these elements are generated in a consistent and validated manner. 

When it comes down to it, GitOps and IDPs are both valuable assets in DevOps. So, while it’s easy to compare how both of these concepts handle different aspects of DevOps, both Chris and Kostis agree that these elements work better in tandem than as separate entities. 

In the next webinar in this series, Chris and Kostis demonstrate how GitOps and IDPs can be used together using Humanitec and Argo CD. You can find the webinar recording here or, if you’re short on time, read the blog post to see how these two assets can strengthen your DevOps setup.