.jpeg)
In part one of the GitOps vs IDPs webinar, Chris and Kostis discussed how these two DevOps assets can be used in tandem to support a more efficient development environment. With so many questions remaining about how GitOps and IDPs can work together, Chris and Kostis ran a second webinar in October to demonstrate how these concepts can be used together.
If there’s anyone who hasn’t seen the first webinar yet, check that out or read the recap before carrying on with this article. And, if you’re not sure what an IDP is or what it can do for your DevOps setup, check out our explainer of IDPs here.
GitOps and IDPs - A quick recap
It is important to note again that both GitOps and IDPs are designed for modern systems like Kubernetes, which are known as “declarative”. This simply means that instead of defining how to change the state of something within your cloud setup, you define what that state should be. To do so, you can use different approaches as we will show in this webinar recap.
Before getting into the practical demonstration of how Internal Developer Platforms (IDPs) can be used as a self-service layer for GitOps, Kostis started the webinar with a recap of how a typical GitOps workflow operates.
In this example, the operator - which Kostis explains could be a developer, ops professional, or even an automated process - works solely through Git to commit changes to the source code and handle pull requests.
This is, of course, the driving principle behind GitOps. However, as developers or operators might already be thinking, this flow can appear unnecessarily lengthy.
This is where IDPs come into play. Internal developer platforms act as an intermediary interface layer over GitOps principles, helping to simplify the whole process.
With an IDP in place, developers only have to interact with that platform. This isn’t to say that they can’t dive deeper into low-level files if they don’t want or need to, but rather that it gives them the headspace to focus solely on code if that’s the level they want to work at.
This also vastly simplifies the DevOps workflow because the IDP completely handles the Git repository.
It’s not the only way to connect GitOps and IDPs, but it is the most obvious way of connecting the two in a way that works to improve the DevOps environment.
Chris explains:
“[At Humanitec], we want to provide a simple interface for developers so they don’t need to know what’s happening behind the scenes”.
How IDPs enhance GitOps
Chris kicks off the practical section of the webinar by demonstrating how the Humanitec IDP can be used in a DevOps setup.
This is an example of a simple application with two services running simultaneously. Chris goes on to explain that the beauty of using an IDP is that, as a developer, he doesn’t need to know where those applications are running unless he needs to. Rather, he lets the IDP handle that workload so he can focus solely on the code he’s working on.
He then demonstrates that, even though he doesn’t know where those applications are running, he has full control over them and can make changes on the fly. This includes adding new variables, which he shows here:
Chris explains that, in the background, Humanitec is dealing with the complexities of generating and updating YAML files.
So, a developer doesn’t have to deal with the YAML files directly to deploy code changes, potentially saving a ton of time in the development process. They also don't know which repository this change is getting pushed to, which cluster will handle the change, or whether it’s going somewhere else entirely, because all they need and want to focus on is getting their code to work.
What’s important to them is that the deployment is showing as running, and they have a time-stamped addition to the dashboard that shows what they deployed and when.
IDPs can also easily handle the creation of new environments and the provisioning of infrastructure:
To get the new environment running, all a developer needs to do is press the plus button under “Environments”, enter a few details, and it was up and running in under a minute.
With an IDP, developers don’t know where this new environment is coming from or where the code they are deploying to it is going. But, they can get a new environment when they need one without having to stress about YAML files or requisitioning resources from ops.
While this might be a very detached view of development, it’s also a good representation of what IDPs can handle if all developers want to do is focus on deploying their code.
On the other hand, Kostis demonstrates how an IDP can be used to handle GitOps.
In this very simple example, a developer would be working with one repository with the application’s source code. It’s purely a code repository at this point and hasn’t been configured to work with Kubernetes or set up new environments. As a developer, you can work in this repository and commit, that’s it.
But what is happening behind the scenes from an operator’s perspective?
In a second repository set up for the application, we have the deployment YAML files that act as a manifest, which effectively define the desired state of the Kubernetes cluster the app is deployed to. So, this can be changed manually by a human operator, or, in this case, it has been created by Humanitec.
Kostis explains that, in real life, Git repositories like this are likely to be far more complex, and you’re also likely to have multiple Git repositories for multiple environments, each running their own applications. So, manually updating them from an operations standpoint can potentially become extremely time-consuming.
However, by using an IDP alongside GitOps, developers and operators can simplify the whole process. Kostis demonstrates this using the ArgoCD GitOps operator, on which he has two example applications set up. This application runs on the cluster and, every three minutes, it automatically checks whether the current state is the same as defined in the Git repository.
In this first example, the application is fully synchronized to the Git repository. Within ArgoCD, you can easily check the live manifest for the cluster, whether any changes have been deployed, and what deployment is currently running.
On each application dashboard, there’s a complete history of deployments, including information like how long the current deployment has been active, who authored it, and when it was deployed. So, developers or operators can see the complete version history without needing to trawl through Git.
Similarly, Kostis demonstrates that it’s simple to roll back applications to previous deployments without having to manually change Git repositories or directories. In his second example application, he demonstrates that ArgoCD automatically detects if a configuration in Kubernetes is different from the Git repository.
ArgoCD automatically highlights the difference (in this example, someone mistakenly added port 80 via kubectl).
From there, developers or operators can get rid of the manual change by synchronizing back with the Git repository.
Combining IDPs and GitOps to improve DevOps workflows
In short, using an IDP means that developers can work on the level of detail and complexity that they prefer. So, the IDP allows developers to easily deploy changes, but if something goes wrong or they want more detail, they can use a GitOps operator to find that information without needing to manually operate manifests in Git repositories.
Once an IDP is configured to work with a GitOps setup, it can effectively take a high-level request - like code deployment - and transform it into low-level functions, which are then sent through the pre-defined GitOps flow.
Chris explains that this can have a lot of benefits for ephemeral environments for testing and interacting with code before deployment, particularly for developers who need to test front-end changes to ensure they work before release. He covered this in a previous webinar, which you can catch up on here. Humanitec allows developers to create and destroy ephemeral environments with a click of a button, which can save a ton of time in the development process.
Similarly, Kostis mentions that using GitOps for automation of environments means that systems can destroy these temporary environments after pull requests are closed so they don’t draw resources and cause cloud costs.
Finally, Chris adds that there’s no one right way of using GitOps to manage multiple environments and repositories, and it’s best to find an approach that works best for the team’s workflow and security needs.
IDPs and GitOps are extremely valuable assets in DevOps for helping to maintain consistency without making life unnecessarily complicated for developers or operators. Of course, this relies on using a high-quality IDP that’s configured for your workflow and environments. To learn more about how Humanitec can empower your workflow, check out our next workshop.
