From Terraform Modules to Developer-Friendly Platform APIs: Scaling Your IDP with Kratix

Abby Bangser
Sep 22
4 min read

Many organisations have invested heavily in Terraform, and rightly so. It’s a mature Infrastructure as Code (IaC) tool that automates infrastructure and streamlines workflows. However, when building an internal developer platform (IDP), IaC alone isn’t enough. To scale across teams and business needs, all while supporting seamless fleet management, you also need developer-friendly platform APIs and abstractions.

Some may argue that Terraform modules provide useful abstractions. These modules offer clearly defined contracts between reusable infrastructure templates and instances of that infrastructure. Additionally, there is strong community support, with over 15,000 publicly available modules to build upon. However, Terraform modules don’t provide a platform API..

That is where Kratix comes in.

Watch: From Terraform to Platform APIs with Kratix

Why Terraform Needs an API Layer

Terraform modules define clear inputs and outputs. Take a public S3 bucket module, for example. It has input parameters, such as bucket_name, tags, and acl, and output values, including arn and bucket_id.

Clear guardrails on input configuration are helpful, but Terraform modules don’t support the “X-as-a-Service” collaboration model described in Team Topologies. In this model, platform teams must be able to evolve their services (owning their “flow of value” fully) and be capable of refactoring, extending, or upgrading services without breaking developer workflows. Conversely, developers should be able to consume new offerings and adapt their configs without deep coordination with the platform team.

Similarly, consumers of this service, often stream-aligned teams, should have the ability to integrate new offerings, manage deprecated features, and change their configuration needs without depending on collaboration with the producing team.

Not only does putting Terraform behind an API enable ownership of the code, it also allows productising of the service to include key auxiliary opinions such as:

Integrated approvals
Security scans
Best-in-class deployment options such as GitOps workflows
Self-service portals for developers
Fleet-upgrades of both the templates and the instances

How Kratix Enables Platform APIs Without a Terraform Rewrite

Any software team is busy, and internal-facing teams tend to be notoriously overloaded. This means knowing platform APIs are the right solution isn't enough; it needs to meet an extremely strict return on investment (ROI) calculation to be prioritised over other new feature work that can bring cost savings, reliability improvements, and more to the organisation's end users.

When improving ROI, you can either increase the value or decrease the cost. And with the Kratix CLI, you can reduce your cost to transform any Terraform module into an API.

With the Kratix CLI, you can turn any public or private Terraform module into a platform API in minutes:

Wraps the module into a Kubernetes Custom Resource (CRD)
Publishes the CRD as a reusable platform API
Handles setup (permissions, credentials) before exposing to users
Stores API requests as HCL code in Git for full GitOps workflows
Integrates seamlessly with CI/CD pipelines (e.g. GitHub Actions) for plan/apply

The result? Your already trusted Terraform code has been transformed into a reliable, upgradeable API that is ready to be extended to package additional business processes and requirements.

From Terraform-based Platform APIs to Backstage-based UIs

APIs are a form of developer UX, but you can think of the API as a baseline interface, thereby providing a minimalist experience. Given that it was so easy to generate the API from Terraform, your team can now focus on enhancing the experience and going beyond templating.

Many organisations are identifying browser-based portals as the right experience, but struggling to succeed with the TypeScript-based OSS project Backstage. This is where Syntasso Kratix Enterprise (SKE) can reduce a platform team's heavy lifting of writing TypeScript to configure Backstage, instead automatically registering Promise APIs in Backstage as components and templates.

This introduces easy-to-use web forms instead of finicky API requests, which were already a significant step up from managing HCL modules.

And thinking beyond a single interface, most organisations need to cater to users with different preferences and needs. Requiring not only portal interfaces, but also CLI, ticketing systems, chatbots and more. This is where investing in the API first starts to pay off, as adding a new interface is as simple as integrating a new display layer rather than re-creating the complete code and business process integrations.

The Benefits of Platform APIs

A Terraform module isn’t an API. It doesn’t separate the concerns of the producers and the consumers. Instead, it leaks domain language (HCL) to the users and demands user upgrades even for backwards-compatible refactorings.

And beyond the deep implementation challenges of using code as an interface, there are also broad organisational challenges in managing security workflows, approval gates, and related code changes, such as configuration management to a single-purpose IaC language.

Kratix provides the ability to create composable platform APIs that enable multiple developer-friendly interfaces without significantly increased maintenance cost, all while still giving platform teams control to manage necessary upgrades and security patches in a centralised way.

With Kratix, you can: