Why Use A Remote Operations Backend Over A Standard Backend

I discussed in a recent post entitled How to use Terraform remote backends what is a backend and the different types of backends that are commonly used by Terraformers. This post will delve further into why you should select a remote operations backend over a standard backend. Remote operations backends include Terraform Cloud and Scalr to name a few, there are some others out in the market, but these will be the main focus.

Standard Backends

As referred to in the previous post where we discuss backend definition, standard backends are generally cloud-specific backends such as an s3 bucket or Azure blob storage. The below diagram outlines the general components of a standard backend, those include:

• State file(s)
• State versions
• State lock

The standard parts are very much that they allow us as operators/consumers of Terraform to store our state somewhere that is accessible from multiple locations. This ensures that all engineers can view state and make changes to the Terraform code. Where versioning is enabled, previous versions of state are stored for that given Terraform code; this is always implemented as a feature of the storage backend itself rather than as a component of Terraform. 

Whilst standard backends are very prevalent in the industry and cater to most companies’ requirements, they also impart a lot of overhead to the engineers as they are now responsible for orchestrating the Terraform code and managing other ancillary services. In some scenarios, this is the desired state (although utilising a remote operations backend does not preclude you from doing this) as your engineers might want to run custom services/processes such as testing in line with deployments of the Terraform code. 

Remote Operations Backends

These were previously called enhanced backends and are now generally referred to as remote. However, I tend to refer to them as remote operations backends given that they give the consumer the ability to store version state and execute the Terraform code. For this discussion, I will try to avoid anything specific to a particular remote operations backend and talk about their commonalities. 

The below diagram outlines the components of a remote operations backend. In a similar way to the above standard backend, these components are as follows: 

State

• State file(s)
• State versions
• State lock

Operations

• Runs
• Cost estimation
• Policy

If we were talking about classes in an object-oriented programming language, we would call the remote operations backend a child of the standard backend class. It has the complete feature set of the standard with extra goodies bolted on top! There are three main benefits to the remote operations backend, those are: 

• Runs (executions or orchestration)
• Cost estimation
• Policy enforcement and audit 

Let’s break each of those down to discuss. 

Runs 

These are the executions of the Terraform code triggered either on checkin to the repository or by some other product specific means. Runs are also what encapsulates the other benefits of the remote operations backend which we will discuss shortly. 

Cost Estimation

When a plan of the code has been performed, the remote operations backend will also run a cost estimation (where enabled) that informs the engineer of the potential cost of either the entire environment or just the changes being put forward as part of the latest commits. This is an extremely useful feature for ensuring that engineers better understand the business cost of deploying resources to an organizations cloud environment. It no longer becomes an I didn't know situation.

Policy 

The next phase is the policy phase; this is where any policies that the engineers have defined are run. The policy feature allows us as engineers to better restrict what and how resources are deployed into cloud environments; this may go so far as to restrict how a resource is configured or even named. Features like this are essential to larger, more regulated environments where security operations require the enforcement of specific controls. Furthermore, it also acts as a source of evidence in the case where an auditor might require proof that a given control is being adhered to. 

Examples of the types of technology that can be used to write policy are Sentinel from HashiCorp and OPA which is part of the CNCF. Both of these technologies allow for incredibly granular and precise control of the resources that your Terraform code is creating.

However, this could also be something as mundane as ensuring the correct tags are put on resources! 

Closing Out

This post has gone through the standard backend and the remote operations backend, outlining what each entails and the benefits. You might be asking yourself, but what is the recommendation here? Well, here it comes. 

It doesn’t matter if you’re starting in your Terraform journey or you’re already deep down the rabbit hole; I would likely recommend checking out the remote operations backends first. If your organization can afford the paid tiers or you, fortunately, come in under the free tier that most products offer, then this is a fantastic place to start. It gives you all of the joyful features discussed above and, more importantly, it means you have to do little to no state management, which is always positive. However, the standard backend is perfectly acceptable and very widely used in saying this. It does allow the perception of increased flexibility. However, I genuinely believe that the best option for most consumers and backend developers is to use a remote operations backend as you gain too many additional features. There is a vast reduction in operations overhead. 

You can follow Brendan @BrendanLiamT on Twitter.