3 min read
Doron Grinstein

Control Plane and Crossplane | What is the difference?

Infrastructure as Code (IaC) tools are some of the DevOps engineer’s best friends. Without an IaC tool, you can’t call it DevOps. Some tools that fall into the IaC category include Hashicorp’s Terraform, Upbound’s Crossplane, Pulumi, and AWS’s Cloud Formation, amongst other lesser-known tools. Why are these tools so crucial to the practice of DevOps?...

Infrastructure as Code (IaC) tools are some of the DevOps engineer’s best friends. Without an IaC tool, you can’t call it DevOps. Some tools that fall into the IaC category include Hashicorp’s Terraform, Upbound’s Crossplane, Pulumi, and AWS’s Cloud Formation, amongst other lesser-known tools.

Why are these tools so crucial to the practice of DevOps? Simple – repeatability. For example, when building systems where cloud or data center resources are created manually by using a UI console, the app is coerced into working. But as soon as it is running as designed, the human memory that brought it into existence starts to erode. When the system requires re-creating some months or years later – how in the world is/are the same (or a different) developer(s) going to remember exactly the steps taken initially to create the resources for the system? The short answer is – manually provisioning resources like buckets, VPCs, databases, queues, etc., is a BAD IDEA!

When creating VPCs, databases, queues, routing tables, etc., the developer will not remember the parameters used initially. Even with great note-taking, manually repeating operations is slow and fraught with risks due to mistakes.

IoC tools generally provide similar functionality. They interpret text representing a domain-specific language that codifies the desired state of resources. It builds a dependency graph of resources and then calls the target(s) (e.g., cloud) APIs in the correct order. For example, to provision a VPC before a DB deployed within that VPC. The IoC tool maintains a state of the real world, so when subsequent changes are needed, including when the whole desired state requires tearing down, the IoC tool can mutate the real world from state X to state Y.

We use IoC tools for provisioning cloud resources at https://controlplane.com (not to be confused with Crossplane). We can’t imagine deploying hundreds of K8s clusters and other resources using a manual process!

Some non-technical folks have recently asked us, “what is the difference between Control Plane and Crossplane?”. Other than the fact that both have “plane” in the name and that Crossplane’s marketing website refers to “Control Planes,” there’s no overlap between the two. We’ve already covered what IoC tools do. Now let’s explain what Control Plane is:

Control Plane is a distributed compute operating system. It manages a set of Kubernetes (K8s) clusters running on any cloud or on-premises, turning N K8s clusters into a Global Virtual Cloud™ (GVC™). It allows developers to quickly deploy software to one or many GVC™ instances of specified locations and cloud providers. It gives developers 99.999% of availability and ultra-low latency, regardless of where users are. 

The Control Plane platform provides all the security controls, observability, scaling, and cost optimization organizations need to run cost-effective microservices. In short, Control Plane virtualizes the different clouds, giving developers a singular virtual cloud. It is a consistent, cloud-native compute substrate that abstracts the clouds, making workloads portable

Developers can focus on their code, and the Control Plane platform handles identity, reliability, scalability, low-latency, security, observability, cost optimization, connectivity, and more. You can provision a GVC™ and the many object types exposed by the Control Plane platform using the above mentioned IaC tools. From an IaC tool’s perspective, Control Plane is just another cloud, albeit one that provides the UNION of all the services of AWS, GCP, and Azure as one uber cloud.