Adopt GitOps best practices and tools for your organization
In his book 'Repeatability, Reliability, Scalability through GitOps,' Bryan Feuling provides an in-depth analysis of GitOps to help companies find best practices and tools.
GitOps offers companies the ability to streamline their deployment and delivery process -- but being able to use this practice is easier said than done. With no clear set of directions or formal definition, many companies struggle to approach GitOps practices with a clear understanding and vision.
In Repeatability, Reliability, Scalability through GitOps, author Bryan Feuling offers an in-depth, comprehensive look at what GitOps is and explores possible practices, tools and challenges. "My hope with this book was to give people fine-tuned guardrails on which GitOps practice they want to follow and how to stay in line, so you don't run into [pitfalls]," Feuling said in an interview. "My goal is to be a bit like Switzerland on the idea and make it easier for someone to make a decision," he explained.
Bryan Feuling
As a consultant, Feuling found most companies lacked a firm definition of what GitOps is or how to do it.
"GitOps as a practice has a different definition and application, depending on who is asked," Feuling wrote in the book. "Some dictate that GitOps is treating the Git repository as the source of truth. Others will say that GitOps is about converting every operation step into code, which is stored in a source code repository. And there are some that will give a middle-ground hybrid of the two."
The book is not meant to sway readers toward one style or tool, but rather to help users understand the goal they are trying to reach. "I noticed a lot in the DevOps community that GitOps is seen as the end-all-be-all of DevOps. [You're] not doing DevOps unless you do GitOps, and GitOps does everything," he said. Feuling hoped to help readers see the bigger picture to find what approach will be best for their team, industry, company and current tool stack.
Click here to learn more
about Repeatability, Reliability,
Scalability through GitOps.
Though designed for engineering leadership, the book is approachable to readers with minor technical experience. "My dad's kind of technical, but he's not technical in this area," Feuling said of how he approached his audience's experience levels. "My mentality was: What could I write that my dad would understand?"
He hoped that a vice president of engineering with little to no GitOps experience could pick up the book and understand the topic enough to pass it on to their subordinates and direct their team in implementing GitOps.
Approach GitOps principles
Choosing a tool is a major struggle IT organizations face when implementing GitOps. "A lot of people are sold by the dream of a tool, but they don't really understand what the negative drawbacks could be," Feuling said. "Don't think that one tool is really bad because it has this, and the other tool doesn't have a negative to it." The book highlights both the pros and cons so users know the potential pitfalls and how to work around them.
To visualize how GitOps could work for an organization, a hypothetical scenario weaves across every chapter to illustrate different potential situations. It proposes what the process could look like for a company adopting GitOps. For example, in chapter 3, "The 'What' and 'Why' of GitOps," the team decides to turn to GitOps after they experience numerous problems in their deployment process:
The DevOps team found themselves in the middle of a perfect storm of problems. They were still needing to support the quarterly release process, at least until the monolithic application was completely broken down into microservices. They also had to support the new pipeline process that they had built which has resulted in major support issues. And the team also needed to figure out a new pipeline process that would eventually supersede the rest.
The hotfix for the pipeline queuing issue was now completely resolved and the teams could move back into the previous continuous process that they had before. However, since the development process had become a tightly coupled service-oriented architecture, it was difficult to get the teams to adopt anything new. Ultimately, the team needed to not only bring in a better process, but they also had to make it easy to adopt, automate, and reduce the onboarding requirements.
Since the developers were already familiar with Git repositories, the DevOps team wanted to start there.
By leveraging the Git repository that the development teams were already accustomed to, the delivery and deployment process would actually be significantly easier to adopt. The Kubernetes manifests and application code were already stored in Git. And the teams were well accustomed to Git versioning and branching. Also, since the teams were using pull requests to trigger the builds, the DevOps team could continue using the same triggering event.
The DevOps team also found that the cloud teams were storing their Infrastructure-as-Code configuration files in their Git repositories as well. This allowed for the potential of a larger scope of support in the desired solution. By leveraging the Git repositories as a central source of the truth, the DevOps team could adopt a GitOps process.
Every scenario is followed by a thorough explanation of the team's reasoning for their actions as well as other options they could have chosen. The book is divided into three sections: fundamentals of GitOps, GitOps types, benefits and drawbacks, and hands-on practical GitOps. Each section builds off the previous one, ensuring the reader has a clear understanding of the deployment and delivery process to then introduce GitOps and the different types. In the later chapters, Feuling examines different tools and gets into specifics -- like how to create a Helm chart and an application with Git.
GitOps models
Section two of the book dives into three different schools of thought surrounding GitOps, which Feuling lists as original, purist and verified. As Feuling coined the term "verified GitOps," that is his preferred method, he said.
Original GitOps and purist GitOps focus primarily on automated deployment systems -- like Argo CD, Jenkins X or Flux CD -- which offer self-pruning and self-healing features but aren't necessarily GitOps-oriented. "Verified GitOps expands into how you can codify a delivery process, rather than just a deployment process," Feuling said. "The delivery is significantly larger in scope and the deployment is a part of a delivery."
Purist GitOps gives users more freedom to be creative with how to implement GitOps, but can be tricky, as it is nonconformist and lacks standardization. Feuling described it as "the wild, Wild West of GitOps," because the user can do whatever they want -- even store code in a Word doc, instead of in a network file system or server.
"It's about the essence data we're going to make. We want to boil it down to its pure essence. And while that sounds great, the real difficulty is that you're opening up massive scope creep," Feuling explained. This freedom could create serious problems for users but is included in the book because it could be the best choice for some IT organizations' current technology stack.
Feuling examines all three GitOps types, but, in most cases, it's not as simple as just picking one. "Most people reading this book are not like, 'Hey, I'm about to start engineering and I need to find out which one's the best one. Let's do verify.' It's usually 'I've got a stack of 20 different tools that have shadow IT'd their way into my stack, and I have to figure out what to do with [them] and make them fit together, work and integrate,'" Feuling said. "In most cases, I would say Originalist over Purist, because the toolset is founded for you already. It's easy to install Argo or Jenkins than it is reorient an entire architecture to make what appears to be GitOps."
As GitOps is still evolving, its future is uncertain. Without an industry-standard definition, Feuling predicts GitOps will continue to be redefined to sell new products -- much like the commercialization of open source software. "Imagine if you're sitting in your apartment or your house, and all sudden a brick comes flying through your window. You pick up the brick and it says, 'Do you have window problems? Call this number,'" Feuling said. With GitOps, the solution is being created before the problem occurs.
GitOps is more tech-stack-oriented than case-oriented. While no future editions are in the works yet, Feuling might expand the book as the GitOps industry continues to grow. But if Feuling writes updated editions in the future, he hopes to break out of the hypothetical and focus more on the technical aspect by working with a specific stack or piecemealing stacks together.
Editor's note: This excerpt is from Repeatability, Reliability, Scalability through GitOps: Continuous delivery and deployment codified authored by Bryan Feuling, published with Packt Publishing Ltd., May 14, 2021, ISBN: 9781801077798.
