Beyond Terraform: Why Your IaC Strategy Needs to Evolve
- Ikpemosi Victoria Braimoh
- May 1
- 3 min read
Updated: Jun 23
Can you talk about Infrastructure-as-Code (IaC) without talking about Terraform? Probably not!
Over the years, Terraform has been the backbone of IaC. It has helped teams automate cloud provisioning, create reusable infrastructure, and make the job a bit easier for developers.
While Terraform excels at infrastructure-as-code provisioning, it presents challenges for developer self-service workflows. Its configuration language and workflow are infrastructure-focused rather than application-centric, creating a steep learning curve for developers.
For many organisations, it’s not just about getting resources deployed. It’s also about evolving and adopting a better strategy that goes beyond infrastructure provisioning. It's about reducing manual efforts and embracing a reliable platform that helps you manage your configurations more effectively.
Kratix + Crossplane: A smarter approach to IaC?
Kratix is an open-source platform framework that allows organisations to create platform abstractions while leveraging their existing tools and processes.
Although Kratix is often seen as an alternative to Terraform, that’s not the case. Terraform and Kratix both aim to enable IaC, but at different abstraction levels.
While Terraform supports managing cloud and other SaaS tooling through its custom HCL programming language, Kratix allows you to create reusable platform components to provide infrastructure (and everything else) "as a service", using Promises.
Take an organisation running dozens of microservices across multiple Kubernetes clusters, for example.
If each application team manages their own deployments using standard Kubernetes manifests and the security team has identified a critical need for all containers to run with a read-only filesystem to prevent potential attacks, how can this change happen seamlessly?
Organisations using the Kratix framework will find it easier to effect these changes across all environments than organisations using the traditional IaC approach.
Without a platform solution like Kratix, implementing this "day two" change becomes a massive burden. Firstly, documentation must be provided to explain the new requirement. The platform team will then need to schedule meetings to discuss the changes, ask each team to update their deployment manifests individually, and finally, ensure they all meet the compliance measures across all deployments.
This process could take weeks or months, leaving your organisation vulnerable in the meantime.
However, with Kratix, you simply update the Promise definition with the necessary security requirements.
Once the Promise is updated and the changes are applied, all applications using it will automatically enforce the read-only filesystem policy without requiring manual updates from individual teams.
No meetings, no coordination with multiple teams, no chasing stragglers. The change will be implemented instantly across your entire organisation, ensuring consistent security compliance.
Promises define an API for your users (application engineers). Promises also define any workflow steps required to fulfil and maintain the Resources, such as running Terraform or other IaC tools, validating business rules, and any additional steps like releasing software that runs on the provisioned Terraform infrastructure.
But here is the thing: if you’ve ever written HCL, you will agree with me that when you write configuration for one cloud provider, it's not easily transferable to another cloud provider.
This is where Crossplane enters.
And now, how would you move from Terraform to Crossplane? This is where Kratix’s Promises architecture makes things seamless. All you have to do is focus on delivering your applications instead of dealing with different cloud configurations.
Now let me tell you more about Crossplane.
Crossplane’s Kubernetes-native approach
A recent CNCF survey shows that most organisations are actively adopting Kubernetes to run almost all their applications and seek ways to unify their infrastructure management approaches.
Crossplane uses a Kubernetes-native approach, allowing you to define infrastructure and deploy it to any cloud. It goes further to continuously monitor and manage the infrastructure like a Kubernetes object, ensuring they match your desired state.
For example, you can use a template to define a generic compute instance without tying it to a specific cloud provider.
So, If your application runs on AWS or GCP, you can configure the ‘providerConfigRef’ to point to the AWS EC2 or GCP compute engine without changing the entire infrastructure definition.
Evolve beyond Terraform without abandoning your existing investments
The truth is, most engineering teams are stuck in a familiar pattern: they've invested thousands of hours in Terraform configurations, trained their teams, and built CI/CD pipelines around it.
It can be really difficult to abandon existing processes that work for you and embrace a change. This is why there is a better approach to evolve without disrupting what already works.
As mentioned earlier, Kratix enables organisations to adopt Crossplane without discarding their existing tools. Providing an API and an abstraction layer ensures that teams can modernise their approach to IaC without disrupting business operations.
Relying solely on Terraform means staying locked into a batch-processing mindset. Teams that evolve their strategies will spend less time debugging and more time innovating.
There is a whole lot to gain when adopting the Kratix + Crossplane approach. Want to see how they both work together? Book a demo here.
Comments