Terraform Landing Zones

How a platform team can leverage Terraform to increase developer productivity

The developer enablement issue

Usually, upon joining a company, a developer gets presented with a 50-point plan and/or a 3 to 5-week onboarding and enablement program to get up to speed and start creating something.

After this enablement program, they will still need to understand and navigate the organization to open and manage all the tickets or pull requests that need to be created.

This situation creates a productivity problem, which impacts application cost, time to market, and overall customer experience.

The requirements are quite simple but complex to achieve and navigate.

In short, developers need a place to deploy a thing and an automated process to achieve that goal.

The place where things are deployed is expected to have all of the required governance, security, and compliance requirements already implemented, to ensure the developer is focused on the business logic and overall application goal, allowing faster iterations to reach the minimum viable product (MVP).

Following this logic, a safe space (place) to deploy components, such as applications, services, functions, etc (i.e. things) is often called a “Landing Zone” in current infrastructure management terminology.

How this strategy is being implemented

To simplify this process, some teams are looking to automate this process as much as possible, but they are usually only looking after one or two products or don’t have the necessary skills.

This is where platform teams are shining, by collaborating with the different teams and offering an organized and opinionated developer experience that covers multiple products and breaks down silos.

Sometimes the platform team opts to create a frontend for self-service, however, this platform team now faces multiple challenges:

• Avoid becoming yet another ticket that needs to be created/managed
• Maintain and support code for a custom front-end
• Keep a service catalog organized and up to date
• Automate and interface with all the different product teams
• Avoid becoming an expert in every product/cloud

If we try to look up the definition of a Landing Zone, each of the cloud service providers (CSPs) have their own definition, however, when it comes to platforms (e.g.: orchestrators or network) or applications (e.g.: monitoring, secrets management, etc), these concepts are absent.

How is the platform team able to tackle all of these challenges without attempting to boil the ocean?

I’ve seen a few examples of platform teams and each one usually starts off by being a team that is:

• Built with a cloud mindset
• Iterates quickly, fails fast, and is able to change direction
• Starts with one project as an MVP to make a repeatable use case
• Tries to address 80% of the use cases, instead of 100%
• Establishes their “shared responsibility model”, which serves as a service contract with their tenants. Here’s an example from our HashiCorp Cloud Platform.

If we look at the 3 phases of cloud adoption, this is a team that is looking to transition from a 2.0 to a 3.0 framework to provide some kind of self-service or products as a service type of experience.

Now that we are aware of the objective, the problem, and the process, what solution is available?

Terraform Landing Zones

A Landing Zone concept based on Terraform allows for the following:

• All teams can cooperate and use the same language, HCL, or any supported by the CDK for Terraform (CDKTF)
• Any product team can build Terraform modules to define their consumption pattern
• Anyone can use the 2700+ providers or build their own
• Terraform users can translate a Landing Zone or component into a single abstraction: a Terraform workspace or set of workspaces

With Terraform Cloud or Enterprise, a workspace gains extra functionality, to ensure all checks and balances are in place to prevent a foot-gun situation and ensure compliance and governance are in place.

To link workspaces it’s possible to create and set variables on another, use data sources instead (i.e. decouple workspaces), or use tfe_outputs. Currently, HashiCorp discourages the use of terraform_remote_state because the Terraform data source needs to access all of the state information.

Terraform Cloud or Enterprise also has a private registry, which enables the platform team to create a development community. A place where all different product silos can come together and publish their consumption patterns as modules. Developers can also use the no-code workflow from the private registry catalog to create Landing Zones or deploy components.

Implementing Terraform Landing Zones

To implement this concept, it’s important to remember what I mentioned before: you don’t want to boil the ocean. Delivering a whole end-to-end pipeline is daunting and complex. Starting by defining a small and scoped shared responsibility model provides clarity on the way forward to define your objectives and the developer personas the team is planning to accommodate.

With a quick search, you can find several implementations from different cloud providers, but the platform team ultimately has to set its own custom definition of “Landing Zone” and “component”, to make sure they are fit for their purpose.

There’s also specific guidance published by our cloud partners, that can be used as starting point or for inspiration. For a real-world example of how a company was able to implement the Terraform Landing Zones concept successfully read on How Deutsche Bank Onboarded to Google Cloud w/ Terraform.

Once your requirements and objectives are established, create a free Terraform Cloud account, and explore the API and the Terraform Enterprise provider to get accustomed to what a workspace is and the abstraction it allows you to have.

There are several decisions the platform team needs to make and HashiCorp is here to help every step of the way. Please reach out to HashiCorp so our Field Solutions Engineers can support you in your journey.