Crossplane.io Evaluation

This outline describes the work performed by Shadow-Soft throughout the consulting efforts performed.

Table of Contents

1. What is Crossplane.io

Introduction

Crossplane is a framework for building cloud native control planes without needing to write code. It has a highly extensible backend that enables you to build a control plane that can orchestrate applications and infrastructure no matter where they run and a highly configurable frontend that puts you in control of the schema of the declarative API it offers.

Crossplane connects your Kubernetes cluster to external, non-Kubernetes resources and allows platform teams to build custom Kubernetes APIs to consume those resources.

Crossplane creates Kubernetes Custom Resource Definitions (CRDs) to represent the external resources as native Kubernetes objects. As native Kubernetes objects, you can use standard commands like kubectl create and kubectl describe. The full Kubernetes API is available for every Crossplane resource.

Crossplane also acts as a Kubernetes Controller to watch the state of the external resources and provide state enforcement. If something modifies or deletes a resource outside of Kubernetes, Crossplane reverses the change or recreates the deleted resource.

With Crossplane installed in a Kubernetes cluster, users only communicate with Kubernetes. Crossplane manages the communication to external resources like AWS, Azure or Google Cloud.

Crossplane also allows the creation of custom Kubernetes APIs. Platform teams can combine external resources and simplify or customize the APIs presented to the platform consumers.

Components and Concepts

Crossplane introduces multiple building blocks that enable you to provision, compose, and consume infrastructure using the Kubernetes API. These individual concepts work together to allow for powerful separation of concern between different personas in an organization, meaning that each member of a team interacts with Crossplane at an appropriate level of abstraction.

Packages

Packages allow Crossplane to be extended to include new functionality. This typically looks like bundling a set of Kubernetes CRDs and controllers that represent and manage external infrastructure (i.e., a provider), then installing them into a cluster where Crossplane is running. Crossplane handles make sure any new CRDs do not conflict with existing ones, as well as manage the RBAC and security of new packages. Packages are not strictly required to be providers, but it is the most common use-case for packages at this time.

Providers

Providers are packages that enable Crossplane to provision infrastructure on an external service. They bring CRDs (i.e., managed resources) that map one-to-one to external infrastructure resources, as well as controllers, to manage the life-cycle of those resources. You can read more about providers, including how to install and configure them, in the provider's documentation.

The Upbound Marketplace contains the available providers.

Managed Resources

Managed resources are Kubernetes custom resources that represent infrastructure primitives. Managed resources with an API version of v1beta1 or higher support every field that the cloud provider does for the given resource. You can find the Managed. 

Resources and their API specifications for each provider on the Upbound Marketplace and learn more in the managed resources documentation.

Composite Resources

A composite resource (XR) is a special kind of custom resource that is defined by a CompositeResourceDefinition. It composes one or more managed resources into a higher level infrastructure unit. Composite resources are infrastructure operator facing, but may optionally offer an application developer facing composite resource claim that acts as a proxy for a composite resource. You can learn more about all of these concepts in the composition documentation.

[Back to the Top]

2. Crossplane Versus Other Tools

Terraform

At the time of this writing Terraform supports platforms and API integrations with 3462 providers compared to Crossplane’s 45. Terraform enables coding with a semi-robust DSL derived from HCL2. Terraform is installed as a statically linked cross-platform binary and does not require a Kubernetes control plane installation. Terraform manages the infrastructure with a protected state file to prevent inadvertent infrastructure destruction and modification. Terraform is the industry standard and therefore is the easiest to hire engineers with a relevant skillset. Terraform has a somewhat rough learning curve, but also has existed as the industry standard for long enough that there are numerous engineers already skilled with it who can provide assistance. Terraform has a rich ecosystem of third party products provided by companies such as Gruntworks, Spacelift, Google, Amazon, Microsoft, and independent developers that enhance its capabilities.

CDKTF

The Cloud Development Kit for Terraform (CDKTF) is functionally equivalent to Terraform itself. The primary difference between the two is that CDKTF configurations are programmed in Go, Python, Typescript, C#, or Java instead of a HCL2 derived DSL. Therefore one would choose this over Terraform when there is a strong familiarity and need for the robustness of a full programming language. It fully integrates with core tools such as Terraform and providers, but not as well with third party tools such as those by Gruntworks. For example: acceptance testing in Python would be performed with Pythonic tools, and not with Terratest. Otherwise the CDKTF enables the same advantages versus Crossplane as Terraform with the primary difference related to the choice of programming language.

Pulumi

Pulumi is most comparable to CDKTF, and therefore enjoys most of the same advantages over Crossplane as CDKTF. The primary initial difference between Pulumi and CDKTF is that Pulumi supports a YAML-based configuration, its C# support is fully expanded to all in the .NET family, and its Javascript SDK bindings are natively Node.js instead of Typescript (but Typescript can still be utilized with the Node.js framework). Pulumi is very significantly less widely used in the field than Terraform (but still significantly used more than Crossplane), and as such enjoys a marketplace of providers (144) and available engineers with the required skillset quantifiably about three times greater than Crossplane, and about twenty times fewer than that of Terraform. The usage, utilities, and support for Pulumi follows the same paradigm as Terraform, but is generally less in every category and among third party tooling as one would expect. However, in any legacy code Pulumi will leverage Cloud Native Templates instead of the API, and these typically have a much higher rate of failure for infrastructure modifications, and obfuscated logging for debugging.

Cloud Native Templates

Cloud Native Templates (e.g. CFT for AWS, ARM for Azure) are the most similar to Crossplane in that they are a YAML-based configuration that declaratively manages infrastructure. The primary differences are that Crossplane supports the major cloud platforms and Cloud Native Templates only support one major cloud platform, and Cloud Native Templates do not require a Kubernetes cluster for usage.

Ansible

Ansible also utilizes a YAML-based configuration, but is imperative rather than declarative. This is because Ansible was originally designed as an orchestrator and software provisioner which lends itself to an imperative execution methodology. Use cases where resources are actively managed (e.g. infrastructure of configuration) are typically better handled declaratively. This is because declarative DSLs describe end states modeling a desired outcome, and not a sequence of actions that theoretically and hopefully achieve the desired outcome. Ansible supports more platforms and APIs than Crossplane, can also be used for orchestration and software provisioning, and is similarly easy to learn but can be used with Jinja2 templating (Crossplane not supporting Sprig for some reason). It is also the industry standard for orchestration and software provisioning, and therefore it is easy to hire engineers with the skillset who can provide assistance. It also installs a local agentless binary that does not require a Kubernetes cluster.

Cloud Platform SDKs

Cloud Platform SDKs (e.g. aws-sdk-go, boto3) are most comparable to CDKTF and Pulumi in that they manage infrastructure with a specific programming language. The primary difference is that the SDKs only target a single cloud platform (same as the Cloud Native Templates) whereas CDKTF and Pulumi target multiple providers. Therefore the codebase would need to either uniquely handle the different platforms and APIs, or be separated into different codebases per platform (standard architecture) and API (unusual architecture). This means the platform and API support hurdles would be similar to Cloud Native Templates and Crossplane. The programming language knowledge hurdle would be similar to CDKTF and Pulumi. This option would enable programming compared to Crossplane, and would require language installation and packages as opposed to a Kubernetes cluster.

[Back to the Top]

3. Decision Tree

I want to use for infrastructure provisioning:

1. The best tool for the job that also has a bit of a learning curve: Terraform
2. a robust programming language I am already familiar with: CDKTF
3. a language not supported by CDKTF, and also targeting a major platform (e.g. AWS, Azure, GCP): Pulumi
4. a simple YAML-based configuration tool that was originally designed for orchestration and software provisioning, but can also provision infrastructure imperatively (but not necessarily actively manage it): Ansible
5. a simple YAML-based declarative configuration specific to only one cloud platform: Cloud Native Templates
6. a robust programming language I am already familiar with, and I want to build out custom solutions myself for all of the utilities, and I am probably targeting only a few platforms/APIs: Cloud Platform SDKs
7. a simple YAML-based declarative configuration supporting several platform APIs that also requires a Kubernetes cluster: Crossplane

Contact us with any questions. We are here to help!