Time to Cross Over: Migrating from Terraform to Crossplane

January 29, 2024

Rachel Sharp

When organizations start to scale, getting the correct infrastructure-as-code workflow right can be a daunting task. Thankfully, when teams think about the next step in their cloud-native journey after Terraform, Crossplane is there to help. In this blog post, we'll take a look at an example company going through some growing pains and how the Crossplane provider-terraform can help. For an in-depth how-to guide, check out the Upbound docs migration tutorials.

Introduction

It's 2024, and your startup JNCOmatic isn't just hot; it's Unicorn-in-a-Ferrari hot! Your groundbreaking app, which can slap a pair of hyper-realistic, backwards JNCO jeans onto anyone (or any dog on its hind legs), is running on all cylinders.

The Terraform Tango

Back in the day, when Viv was the lone Op of the Ops team, things were simpler. Deployments were a breeze, the scale was low, and AWS bills were…manageable. Viv started out on the team of one by implementing a Terraform workflow to easily deploy all the necessary infrastructure to the cloud. She mapped out the resources, accounted for spot instance scaling, and ensured user data was encrypted from a few files. Here’s an example of a Terraform resource configuration she might have used:

resource "aws_instance" "my_vm" {
  ami           = "ami-abcd1234"
  instance_type = "t2.micro"
  tags = {
    Name = var.vmName,
  }
}

variable "vmName"{
    description = "VM name"
    type = string
}

Scaling up

But that was before, CourtJortster, a TikTok influencer with a flair for the '90s, happened. Livestreaming the entire 1993 Chicago Bulls roster in NBA2K – all decked out in JNCOmatic gear – turned your world upside down.

The Terraform approach worked well when the team was a single person responsible for serving a small number of users. The first step of the cloud-native journey was just laying a foundation, but as JNCOMatic scales by orders of magnitude, Viv knows the workflow needs an update.

Four people on an Ops team can’t collaborate as they would like on the Terraform configuration files. You’ve got a growing number of developers who need to spin up environments to test new methods of generating realistic jean texture with AI. And managing state files? "As if!"

Shifting Gears: `provider-terraform` and Crossplane

Viv decides the Ops team needs to shift to PlatformOps. PlatformOps is how companies ensure their software, infrastructure, and security experts can get the tools and environments they need to get their jobs done. The developer platform the company needs is Crossplane.

Crossplane is an open source Kubernetes extension that transforms your Kubernetes cluster into a *universal control plane*. The control plane allows you to connect Kubernetes clusters to external resources and enables platform teams to build custom Kubernetes APIs to build and manage resources. The platform team already uses Kubernetes for application deployment so there is not a significant learning curve - in fact, Viv is removing tool sprawl from the organization by consolidating infrastructure deployment in the same workflow as application deployment.

By using control planes instead of Terraform, the team doesn't need to worry about configuration drift or use a custom language for their deployments. Painful rollbacks or errored apply operations that stop deployments in their tracks left the team with half-applied configurations with little choice but to start from scratch. In addition to complex module management, multi-cloud or hybrid deployments in Terraform require a lot of patchwork to make sure your resources work together.

The big problem: The team has amassed so many Terraform configurations that it’s difficult to easily start over on Crossplane.

The big solution: Crossplane has a `provider-terraform` that executes HashiCorp Configuration Language (HCL) within Crossplane.

The same Terraform configuration above is easily slotted into a Crossplane spec:

apiVersion: tf.upbound.io/v1beta1
kind: Workspace
metadata:
  name: tf-vm
spec:
  forProvider:
    source: Inline
    module:
      resource "aws_instance" "my_vm" {
        ami = "ami-abcd1234"
        instance_type = "t2.micro"
        tags = {
          Name = var.vmName
        }
      }

      variable "vmName" {
        description = "VM name"
        type = string
      }

  vars:
    - key: "vmName"
      value: "crossplanevm"

The team can easily move from HCL to Crossplane with the `provider-terraform` option and reduces the learning curve a little more. After creating a few more Crossplane specs for their resources, the team gets more comfortable with the workflow.

The GitOps philosophy baked into Crossplane makes it easy for the team to collaborate. The Crossplane configurations live in a team repository and there are no locks or state files to contend with. This workflow also minimizes resource drift. If a team member edits a resource in AWS through CloudFormation or in the GUI, Crossplane uses continuous reconciliation through Kubernetes to keep resources aligned with the source of truth in the Crossplane specs. In other words, your desired state in the spec is exactly what Crossplane will deploy and will prevent drift through Kubernetes' reconciliation loop.

All-in on Crossplane

Eventually, the team fully embraces Crossplane, opting to use its native Kubernetes spec for infrastructure management.

apiVersion: ec2.aws.crossplane.io/v1alpha1
kind: Instance
metadata:
  name: crossplane-vm
spec:
  forProvider:
    region: us-west-2
    imageId: ami-abcd1234
    instanceType: t2.micro
  providerConfigRef:
    name: awsconfig

In this example, the team employs a consistent configuration language throughout the deployment spec. Crossplane's AWS provider supplants the Terraform provider, directly orchestrating the desired infrastructure.

This process takes time and it can’t be completed overnight. Meticulous planning is essential for critical infrastructure. Thankfully, you don't have to do it alone. As a Cloud Native Computing (CNCF) project, Crossplane's open-source, community-driven nature offers support through an open source GitHub repository, Slack channel and bi-weekly community meetings.

Once the team maps out their existing configuration in Terraform, the next step is to match the resources in Crossplane. This is where the Upbound Marketplace comes in. The Marketplace is the central hub for finding Crossplane providers. Upbound, the company behind Crossplane, offers a selection of official, actively maintained, and tested providers. In the Marketplace, the team has access to Providers (external APIs you consume from cloud providers) and Configurations (out of the box solutions for deploying the building blocks of your architecture).