Crossplane vs Terraform: Making the Right Choice

If you’ve come across this post, you’re likely pondering the decision between Crossplane and Terraform for your organization. And it’s a valid consideration.

Before we delve further, I must admit that I’ve closely followed Crossplane’s journey since its inception, contemplating the same question myself.

While Crossplane may be the new entrant in the field, there’s no denying Terraform’s status as a tried-and-true contender.

Despite the emergence of newer and seemingly more trendy tools like Pulumi, CDKs, and Crossplane, it’s safe to say that most organizations continue to rely on Terraform for their infrastructure management needs.

Nevertheless, Crossplane entices you with its promises of delivering robust self-serve platforms for your teams, empowering developers, and providing more time to focus on meaningful tasks.

The allure is undeniable, so let’s now take a closer look at what Crossplane has to offer.

What we like about Crossplane

Crossplane makes a compelling promise – it empowers you to construct control planes without the necessity of extensive coding.

Indeed, there are projects like Google’s Metacontroller that simplify the process of creating Kubernetes-based operators and control planes. However, Crossplane takes it a step further by eliminating the need for code (almost entirely).

Score for Crossplane. Let’s explore further.

The project’s maintainers emphasize another significant advantage: Crossplane ensures continuous reconciliation of your infrastructure state, effectively eliminating any discrepancies between the desired and actual state.

While mature teams often have automation in place for handling this concern, reducing friction remains crucial, and Crossplane offers a valuable solution.

Moreover, Crossplane fosters a mindset of encapsulating infrastructure code, which is hard to understate. This approach stands in contrast to the complexities you run into when your Terraform code base starts getting big and you don’t engineer specifically to address this fact.

The ugly bits

One aspect frequently discussed on the internet, even if not explicitly emphasized by the project’s maintainers, is that Crossplane, like Kubernetes, employs YAML as its backbone, while Terraform uses HCL, a different DSL that requires learning.

Let’s examine this point and also touch upon one of my main concerns regarding Crossplane.

However, before we proceed, let’s state the facts.

HCL vs YAML

Indeed, Terraform uses its own DSL, which has gained widespread adoption as a popular infrastructure tool.

The counter-argument raised is that many developers are unfamiliar with HCL.

While it’s true that most developers might not be well-versed in Terraform and HCL, they are more likely to be familiar with YAML.

Nevertheless, knowing YAML alone might not suffice, as working with specific documents, such as Kubernetes manifests, requires a deeper understanding of the domain and its functionalities.

On a side note, you could argue that a sufficiently large collection of YAML manifests could effectively become indistinguishable from a DSL.

Back to my main point.

White it’s true that Terraform might present challenges if you need to onboard all your developers to use it, I don’t think that’s something you should do with either Terraform or Crossplane.

The essence of Crossplane lies in constructing a black box that can be effortlessly consumed by end-users, primarily your developers. They need not be concerned with the intricacies of how the black box functions. If it works as intended, it makes them happy and enhances their productivity – two crucial aspects that complement each other.

Lots of YAML

This leads me to my other concern with Crossplane – the considerable amount of YAML it generates, rivaling only projects like Argo Workflows (excluding the still experimental Composition Functions, which are intriguing and worth exploring).

Please don’t misunderstand me; adopting YAML as a declarative way to define the desired state is indeed a game-changer (though not unique to YAML alone).

However, I believe this advantage is more pronounced with widely-known DSLs, like Kubernetes manifests.

Composing all infrastructure code in YAML can become burdensome. Here, Terraform’s HCL (or any purpose-built infrastructure description language found in CDKs and Pulumi) excels. Its constraints contribute significantly to its usefulness.

This distinction becomes evident when grappling with the versatile YAML manifests that Crossplane necessitates for configuration.

Crossplane – the awesome

Having said all that, I actually love the concepts behind Crossplane. Down at its core is the shift-left mentality, which is crucial in nurturing high-performing teams. It’s a pro that could possibly outweigh all the other downsides.

And, to be fair, none of my previous nitpicking is a deal-breaker either. The only thing that matters is that you’re going to shield your developers from having to understand the inner-workings of Terraform, YAML or Kubernetes.

Crossplane makes it easy to abstract these details and expose a clean and simple-to-use interface to your infrastructure. It goes beyond simplicity; the interface can be tailored to suit your organization’s specific structure and requirements. It also plays really nicely with GitOps (you’re using GitOps, right?).

But the biggest obstacle is something I’ve said in the beginning:

Most organizations continue to rely on Terraform for their infrastructure management needs

Adoption.

Ultimately, whether you write your infrastructure in YAML or HCL is a matter of personal preference. You can get used to them. Different tool, different DSL.

But the really painful thing is having to rewrite your existing infrastructure code in YAML.

Luckily, it doesn’t have to be this way.

Crossplane and Terraform – the perfect couple?

Rather than viewing Crossplane and Terraform as mutually exclusive options, consider their combined potential. By leveraging the strengths of both tools, you can create a powerful synergy for your infrastructure management needs.

Crossplane takes the lead in providing a user-friendly platform, abstracting complexities, and empowering developers with a simplified interface. It shields them from grappling with the inner workings of Terraform, YAML, or Kubernetes, making infrastructure provisioning more accessible and efficient.

On the other hand, Terraform brings its robust framework to the table. Its established DSL, HCL, and extensive ecosystem offer a wealth of resources and proven best practices for managing infrastructure as code.

Most importantly, you can reuse the existing modules you’ve already written – and leverage hundreds of battle-tested Terraform modules authored by others.

In other words, combining Crossplane and Terraform allows you to take advantage of the best of both worlds.

Crossplane serves as the orchestrator, integrating Terraform modules and their configurations, while Terraform serves as the building blocks, defining the infrastructure resources and their shape.

Make sure to check out our walkthrough of integrating Crossplane with Terraform.

The bottom line

Shifting left is about giving access to those higher-level building blocks while shielding the users from their internal implementation’s complexity.

Crossplane fits perfectly into this mindset and we’re excited about the opportunities it brings to the table. Especially ones that don’t involve obliterating your existing infrastructure code!

As Kelsey Hightower has said, the end goal is to reduce the amount of decisions a human needs to make. And I think it sums up what Platform Engineering is really about.