From Here to GitOps and Back Again
The IT sector has been pursuing automated deployment for a very long time. Back in the day, application release automation mapped an application to defined environments, the first step to a fully automated code-to-production system for managing rollouts. It has been a long road, and there have been quite a few twists and turns, but we are progressing.
One step that, in hindsight, was natural and is highly likely to continue, is basing GitOps on a continuous delivery (CD) tool or a deployment automation tool. This allows the GitOps tool to be more tightly aligned with the actual rollout process and placed at the end of the DevOps toolchain.
Likewise, aligning with “worker” tools allows GitOps to focus on the coordination of a rollout rather than the work of the rollout, as underlying workers like FluxCD and ArgoCD handle a lot of the deployment and configuration and can be told what to do for things they don’t specifically know.
Security and Compliance in GitOps
The fact that GitOps handles all of the final steps to deployment, and even deployment to production, means that the tool will hold an increasingly critical place in the DevOps hierarchy. The best place for security policy enforcement is in the tool that will set up the final, complete solution. It’s also the best place to focus on compliance. Where better to build a software bill of materials (SBOM) than at the tag end, when you know what the software, support applications, environment, and even the OS are loading up?
We expect vendors to continue folding in security, and we expect that the tooling will do a better and better job of it. At the same time, we see this space increasingly involved in active—or runtime—security. GitOps can already watch for changes to config as they’re pushed, but we see vendors moving toward monitoring the running application to detect change, and running the processes to keep them in line with the system of record, eliminating drift caused by things like installations on the running system.
The Future of GitOps
This space will likely end up as a feature set in other products—not because it isn’t important enough to remain a separate space, but because the trend of bundling with CD tools or configuration management tools is already pretty set, and we expect similar consolidations to continue. This will keep the solution set stable, but we hope won’t completely lock in the feature set to a single CD tool.
Customers will rightly be concerned by the failures and ownership changes that this space has recently seen. However, we consider the risk to be minimal at this point. There are a lot of reasons that we don’t think customers should worry too much—primarily because, at this point, bundling with other tools is the norm for remaining products, and that will buffer revenue concerns while GitOps is taken up.
GitOps Methodology: Beyond the Technology
GitOps, like DevOps, is as much a methodology as technology. You absolutely need the tools to enable it, but without a culture that promotes end-to-end deployment automation, the best infrastructure as code (IaC) and GitOps tools won’t solve the problems.
This is why we recommend that prospective customers study the GitOps process separately from studying tools before making a large commitment. Understanding how and when all of the moving parts, like network configuration and app testing, fit into the overall GitOps architecture will help a lot when choosing a product that suits your organization’s needs, and training is available from a variety of places.
Is DIY GitOps Worth It?
Some organizations may want to use GitOps but do not wish to bring on another vendor. Like so many parts of IT, GitOps can be done in-house, it will just take more work—both up front and in long-term maintenance. GitOps tools are enablers and standardizers, so both the enablement and standardizations will have to be implemented and maintained independently if an organization wishes to run homebrew GitOps.
A large number of companies have tacked GitOps methodologies onto DevOps practices as changes in the GitOps space—like pull-based approaches, for example—force them to consider if they want this newer technology and how to get it implemented. While pull-based tools exist, a full GitOps solution would be less complex than integrating a separate tool into an internally developed GitOps toolchain. For this specific example, some organizations will be well positioned—via Argo, for example—but there is an array of improvements in the space that create similar issues for homebrew solutions.
The Final Case for GitOps
Simply put: the benefits of GitOps far outweigh the risks and implementation costs. The ability to easily check in a code or configuration, build all that needs building, apply policies (both corporate and security), build a deployment environment and deploy the application into it, kick off dynamic testing if required, and even promote to production if a specified set of conditions are met is powerful. GitOps solutions offer stable releases by ensuring each release meets standards defined both in the GitOps tooling and in tools like security scanners that are integrated into the GitOps process.
IT is a complex environment, and exceptions do and will exist, but as a rule, GitOps has grown to the point that it can handle more than 90% of IT needs and even more in a cloud-first environment.
Next Steps
To learn more, take a look at GigaOm’s GitOps Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.
If you’re not yet a GigaOm subscriber, you can access the research using a free trial.
The post From Here to GitOps and Back Again appeared first on Gigaom.