Skip to main content

3 rules for applying principles of GitOps to enterprise architecture

Check out these three rules for using GitOps to get your enterprise architecture up and running effectively.
Developer experience starts with intentional software architecture.

Photo by Kelly Sikkema on Unsplash

GitOps is an automated approach to system and infrastructure administration in which the capabilities of continuous integration/continuous deployment (CI/CD), and Git-based source code control management are combined to create and subsequently manage enterprise systems quickly and accurately.

Under GitOps, the infrastructure and application state are fully represented by the contents of a Git repository. Thus, any changes to the Git repository are reflected in the corresponding state of the associated infrastructure and applications through automation.

Taking a GitOps approach allows enterprise architects to express a fine degree of description in their architectural designs. For example, instead of just saying, "we'll use a relational database here" and then leaving it up to a DBA to figure things out, an architect can write a detailed specification using a conventional format such as YAML that describes the type of relational database to use along with configuration settings for that database. In addition, the architect can specify the system requirements of the machines that the database will run on, right down to the number of CPUs and maximum utilization thresholds.

The GitOps methodology is both powerful and efficient, but it's no magic bullet. You can't go off willy-nilly and start checking things into a Git repository and hope that it all works out for the best. Some basic guidelines are useful. Thus we offer the following three rules to help make adopting GitOps an easier undertaking. The three rules are:

  1. Accept that the world is dynamic
  2. Incorporate declarative definition into your architectural designs
  3. Embrace automation

Let's take a look at the details of each.

Accept that the world is dynamic

In the old days of manual deployment, enterprise architectures changed slowly. It could take days, if not weeks or months, for a new network topology to make its way from an architect's diagram into the operational fabric of a company's IT infrastructure. Today, when GitOps and CI/CD are in use, it's a matter of hours.

[ Want to dive in deeper? Read What is GitOps? ]

Accommodating fast and continuous change is becoming a typical characteristic of modern enterprise architectures. Thus, architectural designs need to reflect not only the dynamic nature of today's digital infrastructure but the mechanisms by which dynamic change will be implemented. This means incorporating GitOps and CI/CD artifacts, processes, and tooling into the overall architectural design. These items need to be described clearly, as is typical for computing, databases, message brokers, network resources, and application dependencies. Everything required to get an architecture up and running in a dynamic, GitOps—CI/CD environment needs to be known.

The long and the short of it is that a useful design sensibility for enterprise architects intending to adopt GitOps into their work is to understand enterprise systems that are always in motion at various levels and that the architecture needs to describe the many aspects of continuous change accordingly. It's the difference between taking a photograph and making a motion picture. It's a different way of thinking for many but rewarding in the long run for enterprise architects attempting to incorporate GitOps into their designs.

Incorporate declarative definitions into your architectural designs

Designs that are intended to describe the GitOps and CI/CD aspects of your architecture are best done declaratively. In a declarative definition, you specify what you want, not how you want it done. Take a look at the example shown below. It's a snippet of HTML code:

<!DOCTYPE html>
  <h1>The 3 Stooges</h1>

Listing 1: HTML is essentially a declarative format.

The HTML code in Listing 1 is declarative. It's telling the browser that it wants a web page that displays a titled list of the Three Stooges. It is not telling the browser how to render the page. It's just telling the browser what it wants displayed. The same is true of the code in Listing 2, which is an example of a manifest file that defines a Kubernetes network policy.

kind: NetworkPolicy
  name: access-nginx
      app: nginx
  - from:
    - podSelector:
          access: "true"

Listing 2: Kubernetes uses a declarative format to define network policies.

Notice that Listing 2 describes details about what the network policy is. It does not tell Kubernetes how to implement that network policy. Implementation is Kubernetes's business.

It is important to master declarative formats in your architectural designs because many GitOps and CI/CD tasks are executed according to declarative definitions. For example, Listing 3 shows a GitHub Action that sends a notification to a Slack channel when a team member opens an issue in GitHub.

name: Post Slack Issues

    types: [opened]

    runs-on: ubuntu-latest
    - uses: actions/checkout@v2
    - uses: rtCamp/action-slack-notify@v2.0.0
        SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
        SLACK_USERNAME: Cool Dude
        SLACK_CHANNEL: gh-issues

Listing 3: GitHub Actions use YAML to define a process declaratively.

Again, notice, as in the other examples, that there is no programming code in this listing. Rather the code declares the resources to use to fulfill a particular objective and when to use them.

The relevance of declarative definition to the GitOps way of doing things is that the Git repository is the single source of truth for all activity in the software development lifecycle—at the architectural level, design time, and runtime. Furthermore, many aspects of the digital infrastructure will be described in declarative documents stored in the source code repository. Thus, expressing the specifics of an architectural design meaningfully in a declarative format is an essential skill for modern enterprise architects that want to integrate the principles of GitOps into their design thinking.

Embrace automation

A digital infrastructure without automation ain't. Automation is at the very foundation of the software development cycle in today's world of enterprise architecture in general and GitOps in particular. While it's true that most enterprise architects won't be creating the actual automation code that's used by a particular architecture, having an awareness of the nuances that are part of creating an automated architecture is nonetheless important.

The analogy is this: Professional conductors of a world-class symphony orchestra won't be playing an instrument during a performance of Beethoven's 5th, but you can rest assured they've sat in an instrumentalist's chair at some point in their career. They understand the nuance of the undertaking. And, everybody—conductor or instrumentalist—is reading from the same score. That score is the specification for the music that will make its way into the listener's ears.

The same is true in enterprise architecture under GitOps. Code is the score that the GitOps automation tooling uses to get an application into the hands of a company's users. Without the code, automation is meaningless. Without automation, the application will never see the light of day. In short, embrace automation.

[ Download now: 6 ways to promote organization-wide IT automation. ]

Putting it all together

GitOps offers many benefits to enterprise architects. They can have a finer degree of specificity in their designs. And, with greater specificity comes more control over the quality of the systems that make their way into production. But, as mentioned previously, GitOps is no magic bullet. You need to have mastery of the methodology to get the results you want. Hopefully, these three rules for applying the principles of enterprise architecture will help you on your journey to incorporate GitOps into the fabric of your enterprise architecture.

Topics:   Developer   Programming   DevOps   GitOps  
Author’s photo

Bob Reselman

Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.


Privacy Statement