#cnrm

It'll soon be 2 years since I last wrote here about Platform Engineering. Time flies when you're busy working. I do think it's important, however, to take time to show off what you're working on, get feedback and help others who are trying to head in the same direction.

Two years ago I was all over Terragrunt, writing Infrastructure-as-Code for clients in a consulting job. Terragrunt as a wrapper is a real boon for Platform Engineers wanting to create homogeneous environments in Terraform without having to repeat code in the root modules.

Since this time, I've become an employee doing Platform Engineering for a single company which opens your eyes about another set of problems that I believe more people will connect with than the plight of the Platform Engineering ronin.

There is more than one platform

What I mean by that is that within companies there are often multiple products, each with their own infrastructure requirements, but Infrastructure often gets treated as a monolith of configuration that either gets deployed as a whole or not. Either that or a lamentable set of feature flags that make it difficult to see what is actually getting deployed. This is understandable as we want to have homogeneity between environments, but if a product doesn't use a piece of infrastructure we probably should not deploy it for them.

The big wait.

This monolith approach also means that Platform Engineering teams spend a lot of time writing these big configuration modules or root modules for each product launched.

DevEx survey conducted by Rafay indicates that 25% of organizations take 3 months or more to deploy new applications, 45% of respondents are unhappy with their process and 33% say it's too complicated to provision new environments.

Time to consider self-service

Developers know what their applications need, that's why we all went through the era of DevOps, having the teams that developed the software handle operating it. We cannot, however, expect them to be experts in both the application side of things and Cloud architecture and Infrastructure as Code.

Gartner reports 85% of organizations with Platform Engineering teams plan to implement some sort of Internal Developer Platform (IDP) by 2028. This is up from 60% in 2025.

Terraform Stacks

Terraform can be a key element in self-service in infrastructure procurement. We just need to adjust our tools.

On September 25th HashiCorp made Terraform Stacks generally available to its cloud customers. This is a new orchestration method for familiar Terraform code in that it separates the Terraform workspace if you will into two dimensions. On the X axis you have 1 or more deployments and on the Y axis you have 1 or more components.

Components are basically input references for Terraform Modules. On the component level also are input variables, outputs and provider configuration.

Deployments are inputs for the components. On this level you also have integrated support for OIDC tokens from HCP Terraform which you can input to your components to enable authentication in your Terraform Providers using OAuth to your cloud infrastructure. Also on the Deployment level are Stack inputs and stack outputs allowing you to chain different Stacks together connecting their output as input to other Stacks.

There are also deployment groups and auto approval rules that allow you to set conditions for automatically approving Stack deployments based on speculative plan results, if there are no deleted resources for example, or if there are only new resources and no changes.

One of the strengths of Terraform Stacks is the concept of deferred deployments where it detects what parts of the deployment will need to be deferred until resources it depends on are ready. This means if you deploy an EKS cluster and then try to install a Helm chart to that cluster, Terraform Stacks knows to hold off on the Helm chart installation until after the EKS cluster is ready.

Terraform Stacks and GitOps

Deployments in Terraform Stacks are configured by a file you can easily template with jinja to generate new ones. One way to handle this is to create a Workflow Dispatch in GitHub to generate a new deployment by constructing a JSON context and applying it to a jinja template and appending to the .tfdeploy.hcl file in your repository, then generate a Pull Request and assign it to your Platform Engineering team.

Since most IDPs can integrate with Workflow Dispatch in self-service you now have a way for Developers to self service their need for infrastructure.

AWS Accounts and GitOps

You can even start further upstream. AWS Integration and Automation (aws-ia) has a mature Terraform product called Account Factor for Terraform (AFT). This product provides a GitOps way of procuring new AWS Accounts. To create one you can create or append to a Terraform file in your aft-account-request repository that contains a module block. This again can be handled with a Workflow Dispatch and it can end up being a Pull Request to your Platform Engineering team.

This reduces reuse of AWS Accounts which encourages separation of concerns and reduces blast radius of configuration errors.

And so on..

These two methods provide a golden path laid out by your Platform Engineering team to procure infrastructure. And I hope you can see where we can go from here.

We can create stacks to procure VPCs, or add a customization for AFT that generates a VPC from a common IPAM and sets up the networks you need.

A stack to procure EKS with a Helm chart installation for ArgoCD that references a repo and subdirectory for ArgoCD to deploy your K8s manifests to keep with the GitOps method, with output ffrom the VPC stack informing us of the subnets to use.

A reusable centralized workflow to allow your monorepo to deploy services to the EKS cluster using git push to the ArgoCD repo.

A Terraform Workspace that can grant development teams' Identity Center roles access to their newly vended AWS Account.

What about the small things?

Okay, it's probably fine to keep the big things like EKS in Stacks and procure them via self-service but what about the IAM role your Service Account needs, its permissions, the S3 buckets you need for your backend application or the DynamoDB table?

AWS and GCP have interesting products called Amazon Controllers for Kubernetes and Config Connector. These are Controllers for Kubernetes that expose an API in the form of Custom Resource Definitions so you can move these things closer to the application's context by adding it to the Kubernetes Manifests.

That way you can think of the application's manifests as a set of requirements for the application to run properly. This can and usually does vary by applications, the permissions each of their workload service accounts need in the context of cloud IAM.

These connectors then reconcile reality of the cloud infrastructure with the desire state of the manifest and continually resolve differences, eliminating drift.

Conclusion

There are shared feelings of attrition in the Software Development world involving delays in software deployment, the wait for infrastructure procurement, developers blocked by not having access to what they need to do their jobs.

The only way we can ever get out of this mess is if we stop doing things in an unsustainable way and start creating pathways and processes of self-service. It can be painful to shift course and let go of the current process that we have already spent a lot of time an effort developing, but fortunately for many of us working in Terraform there is emerging a way to migrate to a better, less monolithic and more GitOps process.

Platform Engineering teams can then focus on creating these self-service golden paths for each component and supporting those that need to use them.