GitOps Gap: Few Use Declarative Configuration To Manage State

Declarative desired state is the GitOps principle everyone knows but few actually use. The recent State of GitOps report found that just 40% of organizations were using declarative configuration, so what is it and why is it so fundamental to successful GitOps?

What Is Declarative Desired State?

There are two ways to manage state in GitOps. The first is to define a sequence of steps to take a baseline and move it into the desired state. This checklist-style approach is imperative: a set of step-by-step instructions reach the intended outcome. In contrast, declarative state defines the end state, not the steps to reach it.

We can think of this in terms of pizza. You can follow the recipe by stretching out a pizza base, then adding tomato sauce, then topping it with cheese and a couple of tomato slices. Alternatively, you can show an experienced pizza chef a picture of a Margherita and they will take care of everything. Following the recipe gets you an imperative pizza, while showing the picture gets you declarative pizza.

In the same way, imperative configuration contains a series of API calls, commands and scripts, whereas declarative configuration defines the target state and moves the heavy lifting to the tools.

Open GitOps says: “A system managed by GitOps must have its desired state expressed declaratively.” There are only four principles and this is the first of them, so it must be important. But why?

Why Declarative Desired State Is Crucial

Declarative configuration provides a verifiable target state. That makes it useful beyond use within a tool, as it is documentation of what the system should look like. To build the same understanding with imperative configuration, you’d have to run through all the steps and understand how they would change a baseline state, which means you need to hold the whole process in your mental model to understand the end result. This also leaves room for assumptions and omissions, and may result in a state that isn’t what you imagined.

Declarative configuration is simpler to understand. It pushes the burden of achieving that state onto automation tools.

With declarative desired state you get:

• A documented target state
• Easier changes and reviews
• A readable change history and audit trail
• Transfer of reconciliation burden to tools

Given the advantages of declarative desired state and the tools that reconcile it, why aren’t organizations adopting it faster?

Not a Simple Task

While it’s easy enough to start a new project with declarative desired state, there are factors that make it difficult to switch an existing system.

The longer a system exists before you bring it under the control of automatic reconciliation, the longer it is exposed to ClickOps and configuration drift. This makes it hard or even impossible to understand and document the desired state.

Older systems may not be independent or modular, and it may be difficult to build a picture of what the desired state ought to be. Past decisions may force imperative configuration — for example, if they require chained deployments where services must be updated in a specific order.

If you’ve automated database schema changes, you’ll have faced a similar challenge. It was often easier to take a baseline backup of your database, then apply scripts to alter the schema from that point on.

Modern database tools make it possible to retrospectively generate these scripts from a model of the schema’s desired state. GitOps tools that can generate the initial declarative desired state from running systems could perform a similar role in improving the adoption of this practice.

Roles and Regions Are on a Journey

Despite the overall low adoption rate for declarative desired state, some job roles are ahead of the curve in terms of adoption. Architects are the most likely to use declarative configuration, with 60% of them using it. System administrators are the furthest behind at 33.3%.

There are also regional differences, with Europe, North America and Oceania each having more than 40% adoption, while other regions have less than 30%.

All these numbers are likely to improve as organizations grow and mature their GitOps practices. Those who are just starting out with GitOps will see improvements from other GitOps practices regardless of their choice of declarative or imperative configuration. Once they reach a higher level of maturity, declarative configuration will eventually be the place to look for further improvements.

Declarative Configuration Will Rise

Declarative configuration is one of six practices that complement and amplify each other. While you’ll only get the full benefit of GitOps by adopting all the recommended practices, you can work on introducing these over time so you can effectively onboard them and develop a high degree of skill and confidence before adding more. The six practices and principles are:

1. Declarative desired state
2. Human readable format
3. Responsive code review
4. Version control
5. Automatic pull
6. Continuous reconciliation

The State of GitOps report indicates many organizations are starting out on their GitOps journey. As they gain the skills and experience to apply these principles and practices, you can expect the number of organizations using declarative configuration to increase. The benefits are too important to ignore.

You can find out more by downloading the report and joining Octopus for the State of GitOps report webinar on Thursday, June 19 at 3 p.m. EDT/noon PDT.