The Intersection of Control Planes, Crossplane, and Upbound

Cloud computing has increased the speed of innovation for many companies. Whether it’s building a simple website to serve static content from a bucket or complex microservice-based applications that power a company’s operations, companies now have many options to choose from to meet their business needs. Kubernetes in particular has made it easy to build and operate applications that can run anywhere and at scale.

But Kubernetes alone won’t get the job done, because applications deployed into Kubernetes often depend on infrastructure–databases, queues, IAM role and policy configuration, and more. How should app devs stitch infrastructure with their applications? All the benefits that organizations have come to enjoy in Kubernetes for their apps (such as continual reconciliation or eventual consistency), what’s the equivalent for the infrastructure upon which those apps depend on?

What’s more, larger organizations must contend with the compliance and complexity that occurs when application teams from across the company establish their own ways for provisioning the infrastructure their apps depend on. Or, “how do I empower teams to get what they need in a low-toil way, all while enforcing my compliance and regulatory needs?”

Companies who recognize these challenges have tried to adopt tooling such as Terraform and wrapped it in CI/CD pipelines such as Github Actions to remedy these two problems. Terraform is a fantastic tool for providing a vendor-agnostic way (thanks to HCL) to do one-shot attempts at provisioning cloud resources in a consistent and reproducible manner. Stick Terraform into a Github Actions pipeline and you now have an automated way to try provisioning what’s needed in the cloud. But what happens when the Terraform inevitably fails? Terraform lacks retries, resiliency, has cumbersome state management, support for long running operations, handling race conditions, and more. Some companies are staking their effort to build self-service platforms on a foundation that wasn’t meant to support that sort of weight. 

That’s because Infrastructure-as-Code tooling like Terraform is not an orchestration engine and that’s not its intended job. To solve similar challenges for applications, the industry has aligned on Kubernetes. Kubernetes possesses a powerful resource model–backed by a control plane–to do the heavy lifting required to orchestrate applications. Why should infrastructure be any different? Why don’t organizations adopt an orchestration engine–powered by a control plane–to drive the creation and ensuing lifecycle management of their infrastructure? I think it’s because previously, such a project was a massive undertaking requiring special technical expertise, and so companies were left ultimately dissatisfied with TicketOps, IaC-powered pipelines, and a toolchain not meant to solve the job to be done.

A Job to be Done

Crossplane was designed to solve these challenges, giving companies a path to adopt the Kubernetes-inspired control plane way of doing things for both apps and infrastructure. Crossplane allows companies to converge on Kubernetes as the single platform, bringing an orchestration engine to bear for both their apps and infrastructure. It gives organizations a resource model, SDK, and other building blocks so they can get started building their own cloud platforms the right way–on top of a control plane.

The Crossplane project was started by Upbound and contributed to the CNCF. The project refers to itself as, “the cloud native control plane framework”, meaning the project gives companies building blocks so they can enjoy the benefits of a control plane without the overhead of starting from scratch. Thousands of organizations are using Crossplane today, with hundreds publicly attesting to their success running platforms in production powered by Crossplane.

Some have a misunderstanding about IaC tools such as Terraform in relation to Crossplane. In some ways, it’s like comparing the Docker engine to Kubernetes. Organizations should use Crossplane to enable them to:

1. Standardize on the Kubernetes API as the stable interface between their users and platform
2. Leverage existing machinery for identity, access control, and rate limiting (to name a few)
3. Use Crossplane’s framework for mapping user API invocations to composing whatever resources your platform needs to offer.

Thanks to the composition functions feature introduced in v1.14, Crossplane isn’t opinionated about how you compose the resources you need. You can use go templating, kcl, or choose from the growing list of supported languages to define your compositions . Crossplane ultimately doesn’t care, because it’s concerned with orchestration. Crossplane is the tool for this job to be done and it’s what organizations’ cloud platforms are desperately missing.

Intersecting Upbound

We at Upbound have spent countless hours working with Crossplane users–platform engineers who are building new cloud platforms for their organizations and knee-deep in Crossplane. We understand their pains and have incorporated those learnings into our product offering, Upbound.

Upbound the product is the most trusted way to start, run, and scale Crossplane on any cloud, in any region and on-premise. When a company chooses to build on Crossplane, one of the first things they need to think about is the relationship between:

• their users
• their Crossplane instances
• and the Cloud Accounts that ultimately contain the cloud resources to be created and managed through Crossplane

Upbound’s managed control planes solves this problem by offering a strong isolation and tenancy model that allows organizations to tightly couple a given Crossplane instance to a Cloud Account boundary to provision infrastructure resources required by an app. Overlaid with Upbound IAM and control plane groups, users have a rock solid identity model (integrated with their preferred Identity Provider such as Okta or Microsoft Entra ID) that can securely scale with your organization’s adoption of Crossplane.

Upbound is able to run managed control planes wherever organizations need it: in our SaaS environment, in their own Cloud Accounts, or even on-prem. Wherever they choose, organizations get the power of the Upbound Console and supporting functionality like integrated secrets, backup and restore, and more all out-of-the-box. With Upbound, we aim to help organizations use Crossplane instead of having to become Crossplane experts to operate it. 

Hire the right tool for the job. There’s a better way to define and orchestrate your cloud resources for your platform than contorting traditional IaC tooling into pipelines. Choose Crossplane as the orchestration engine your cloud platform so desperately needs to be successful. Use Upbound to go faster and farther with Crossplane than you could ever imagine.

If you’re building your own cloud platform and are ready to try out the missing ingredient in Crossplane, Upbound is the best place to get started. Contact the Upbound Sales team to see a demo of the product. You can also stop by the Crossplane slack community and say, “Hi 👋”.