TNS
VOXPOP
Get, Post or Go Home?
Should GET and POST be the only HTTP request methods used by developers?
Yes, GET and POST are the only verbs needed.
0%
No, DELETE, PATCH and other requests have their place.
0%
GraphQL.
0%
DevOps / Microservices

GitOps Explained with Emoji

GitOps is not a revolution, but rather a system to support more frequent releases that drive modern software development.
Jun 9th, 2021 9:00am by
Featued image for: GitOps Explained with Emoji
Lead image by Bill Oxford via Unsplash.

Margaret Francis
Margaret is president and chief operating officer of Armory, and a seed investor in minority and women-led businesses. Previously she was senior vice president for product and general manager of Heroku. She holds a bachelor's degree from Yale University and an MFA from SFAI. For fun, she reads a lot of science fiction and plays with her kids.

The history of software development could be written as constant acceleration. From the steady waterfall model of releasing new versions once a year, to agile making small features weekly, to modern cloud architecture pushing out code changes as often as you or I might take a coffee break.

How have we achieved this acceleration? Through the evolution of tools that make code deployment safer, easier and more observable.

GitOps is not a revolution, but rather a system to support more frequent releases that drive modern software development. It’s a standardized workflow for deploying, configuring, monitoring, updating and managing infrastructure as code. Most importantly, GitOps enables you to move faster safely.

‘Move Fast and Break Things’ Has its Limits

In the heady days of agile’s first introduction, speed was everything. Release every week, and who cares if you introduce bugs? Users would find them, you’d fix them and the evolving product would look more and more like the ideal product for users every day.

These ideals work when building a digital marketing agency or a goofy storefront that sells pencil toppers. But “who cares about a few bugs” doesn’t fly when you’re running an online bank concerned with compliance. Further, it’s one thing to introduce bugs by changing the product in ways that users don’t love. It’s quite another to break production and take the site down.

As we’ve encouraged developers to embrace DevOps and empower small teams to release microservices, it’s easier than ever to experiment with operations and make changes that break things.

The answer might seem like “slow down and be more careful,” but the actual answer is even more speed.

The Kernel of GitOps

The central idea of GitOps is that operational changes happen as soon as a commit 📄 is made to a repository 🏦. If daily releases increase the chance that a change will break the build, it would seem that per-commit releases would make that much worse. However, if you release changes multiple times a day 📄, you increase the feedback 🤔😀 that developers 👩🏾‍💻 receive. GitOps actually makes it safer to experiment, because issues appear while you still have time to fix them.

GitOps empowers your developers to do the work of IT and operations, making changes to operational configuration to better host services.

Git Makes it Possible

The main rule of GitOps is that a repository (probably a git repository, but the concept is tech-agnostic) must be the single source of truth for your service’s application code and the configuration for the containers that will run your application. Need to revise your app’s error ⚠️ handling? Make a commit. Need to increase the memory 💾 allocation? Another commit 📄. How about standing up new servers in response to heavy loads? You guessed it, a commit 📄.

When things are running smoothly, GitOps means that every developer has a sense of ownership over their application. By delivering a service from start to finish, they gain a deeper understanding and better ability to support the application in production.

We Can Always Go Back

How is it possible to empower every single developer to make changes in prod? A single source of truth in a Git repository means there is always a way to go back. GitOps requires the system’s desired state to be stored in version control, so anyone can view the entire audit trail of changes.

This requirement means that debugging a recent breakage is easier, since there’s a clear record of changes. Even better, traveling back to a known good state is a lot simpler when there’s a clear record of changes. Ideally, the past is no more distant than a quick Git reset.

Again, this is enabled by having a Git repository 🏦 as a source of truth for all operation changes. While GitOps does rely on creating commits for everything, it promises to help enterprises stay competitive and achieve greater velocity safely and securely — and be controlled by the developer.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.