Tag Archive for CI/CD

Slicing GitOps Baloney Thin

During much of my tech career, I dealt in precision. Precision tolerances for hardware products. Precise specifications for software. marketing language that favored exactitude.

Oh wait. That last one is not entirely true. In fact, even in technical marketing where precise language would seem to be appreciated, vague and even obtuse language is often rewarded. This drives plausible deniability which, in turn, benefits companies when products don’t work as advertised. It’s true across all products, even IT ones. More importantly, it allows marketers to set their products apart from otherwise similar ones.

That brings me to my latest pet peeve – the term GitOps. This particular rant started on Mastodon after a tech journalist I respect a lot (one of the few that grok the technical stuff) wrote an article referencing the term. The article was, as usual, excellent. The title, however, lit my fuse about GitOps.

My complaint is that GitOps is just another name for Continuous Integration (CI) or maybe Continuous Integration/Continuous Deployment(CI/CD). To be more charitable, it was CI using some variant of the open source git (and yes it’s lower case) project. GitOps is, in my opinion, an example of slicing the baloney too thin. So thin, in fact that it becomes meaningless.

At that point, one of the maintainers of the OpenGitOps project, Roberth Strand,  pointed me at the project’s website. I appreciate that, by the way. It’s always a sign of good community when members suggest resources to each other. Mr. Strand especially wanted me to look at the the guiding principles of GitOps. They are 1 :

  • Declarative – A system managed by GitOps must have its desired state expressed declaratively.
  • Versioned and Immutable – Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
  • Pulled Automatically – Software agents automatically pull the desired state declarations from the source.
  • Continuously Reconciled – Software agents continuously observe actual system state and attempt to apply the desired state.

What you may notice is lacking is any mention of git itself. That’s right, GitOps doesn’t require git at all. Why call it GitOps then? Weird, right?

The other thing that is immediately noticeable is that these principles would apply to most CI systems. Granted some are not driven by declarative languages, but I would argue most are. Ultimately this looks like a specific implementation of CI.

Back to our baloney. This is an example of trying to create an entire category – be it software, product, or community – from a specific case of an existing term. It’s good marketing. Afraid you might drown in the growing sea of CI/CD products, projects, and companies? Narrow the scope and call it something else. Now whatever you are doing sounds new and fresh. Yay!

The downside is, of course, confusion. It walks like a duck, quacks like a duck, but everyone is told it’s not a duck. Instead, consumers (IT pros in this case) are told to believe that a Mallard is different from a duck. The proliferation of technical terms that mean almost the same thing or that are just subsets of subsets makes decision making much harder. Consumers have to spend too much time just figuring out the starting point.

I suspect that enough companies and organizations such as the CNCF have taken up the term GitOps that it is here to stay. There’s no turning back. What is important is that GitOps not be seen as anything more than a specific case of CI, which is only part of the CI/CD pipeline landscape. Ignore the marketing and look under the covers. You might need some CI software or processes, and they may be called GitOps. You don’t need both and they are not competing with each other, except for the marketing.

 

  1. Source: OpenGitOps, https://opengitops.dev/

Cloud Vendors Release CI/CD Tools

Cloud CI/CD Tools

This was also released under a slightly different name on Amalgam Insights.

Development organization continue to feel increasing pressure to produce better code more quickly. To help accomplish that faster-better philosophy, a number of methodologies have emerged that that help organizations quickly merge individual code, test it, and deploy to production. While DevOps is actually a management methodology, it is predicated on an integrated pipeline that drives code from development to production deployment smoothly. In order to achieve these goals, companies have adopted continuous integration and continuous deployment (CI/CD) tool sets. These tools, from companies such as Atlassian and GitLab, help developers to merge individual code into the deployable code bases that make up an application and then push them out to test and production environments.

Cloud vendors have lately been releasing their own CI/CD tools to their customers. In some cases, these are extensions of existing tools, such as Microsoft Visual Team Studio on Azure. Google’s recently announced Cloud Build as well as AWS CodeDeploy and CodePipeline are CI/CD tools developed specifically for their cloud environments. Cloud CI/CD tools are rarely all-encompassing and often rely on other open source or commercial products, such as Jenkins or Git, to achieve a full CI/CD pipeline.

These products represent more than just new entries into an increasingly crowded CI/CD market. They are clearly part of a longer-term strategy by cloud service providers to become so integrated into the DevOps pipeline that moving to a new vendor or adopting a multi-cloud strategy would be much more difficult. Many developers start with a single cloud service provider in order to explore cloud computing and deploy their initial applications. Adopting the cloud vendor’s CI/CD tools embeds the cloud vendor deeply in the development process. The cloud service provider is no longer sitting at the end of the development pipeline; They are integrated and vital to the development process itself. Even in the case where the cloud service provider CI/CD tools support hybrid cloud deployments, they are always designed for the cloud vendors own offerings. Google Cloud Build and Microsoft Visual Studio certainly follow this model.

There is danger for commercial vendors of CI/CD products outside these cloud vendors. They are now competing with native products, integrated into the sales and technical environment of the cloud vendor. Purchasing products from a cloud vendor is as easy as buying anything else from the cloud portal and they are immediately aware of the services the cloud vendor offers.  No fuss, no muss.

This isn’t a problem for companies committed to a particular cloud service provider. Using native tools designed for the primary environment offers better integration, less work, and ease of use that is hard to achieve with external tools. The cost of these tools is often utility-based and, hence, elastic based on the amount of work product flowing through the pipeline. The trend toward native cloud CI/CD tools also helps explain Microsoft’s purchase of GitHub. GitHub, while cloud agnostic, will be much for powerful when completely integrated into Azure – for Microsoft customers anyway.

Building tools that strongly embed a particular cloud vendor into the DevOps pipeline is clearly strategic even if it promotes monoculture. There will be advantages for customers as well as cloud vendors. It remains to be seen if the advantages to customers overcome the inevitable vendor lock-in that the CI/CD tools are meant to create.