Crossplane Curious? Marketplace Makes Onboarding Easy
This post was originally published on The New Stack here.
Crossplane has fundamentally changed the game in allowing organizations to converge on a single platform for all of their needs – apps, infrastructure and everything in between. If you have not heard about Crossplane before and want to learn more about its core concepts, I recommend Pete Lumbis’ blog post “Crossplane, the Operator's New Best Friend.”
Those who have at least dabbled in Kubernetes and have heard about Crossplane may still find there’s a learning curve between the two. It’s common to wonder how to get started on the journey to building your own platform by designing your own APIs. Upbound Marketplace is an essential tool for users embarking on their Crossplane journey, and I will demonstrate why.
A Guided Tour of the Upbound Marketplace
The Marketplace is a critical tool for Day-Zero Crossplane users. Before a user sets out to build their API, it’s important to first outline the shape of their API, based on inbound requirements. Let’s suppose the user has these requirements:
- Their organization runs predominantly on Google Cloud Platform (GCP).
- Their goal is to deliver a platform that other teams can use to create VM instances that have already been configured to comply with their company policy. Other app teams don’t want to hassle with knowing which properties to set or what sizes are outside of company policy. They just need a VM to host their app
- They’ve decided they’ll only ask the app team to specify whether they want small, medium or large-sized VMs. They’ll also give app teams the option of selecting a region: us-east or us-west.
From these requirements, the user knows they’ll need to build API abstractions on top of GCP’s Compute Engine service (VMs). So, their first objective is to check whether there is a Crossplane provider for the cloud service they want to build on. This is where Upbound Marketplace already comes into the picture.
Provider Discovery
The Marketplace promotes a set of popular providers on the frontpage, of which the GCP Crossplane provider happens to be one. Just the same, users can also use the search bar to browse a catalog of nearly 30 Crossplane providers. If the user were to search “Google,” it should return two results: one implementation that is maintained by Upbound (the benefits explained in this blog post) and one maintained by the Crossplane community.
The Upbound Marketplace already has popular providers like AWS or Azure, and the Crossplane community continues building more Crossplane providers with each passing week, making it that much easier to get started with Crossplane.
API Discovery
If the user were to click into the Upbound official provider-gcp, they’ll be taken to a page where users can browse through what the provider has to offer. This page gives users a consolidated view to peruse through and explore the API types available for users to build on top of.
Thinking back to the requirements mentioned earlier, if a user is building a platform on top of Compute Engine VMs, they can use the search bar in the CRDs pane to look for “instance”. Note: you may have to try a couple search terms. The marketplace searches based on a few fields exposed by the CRD. For example, if you search for “VM,” you will get no results, but “instance” gets accurate results.
If the user clicks the CRD that has an “Instance” kind under the “compute.gcp.upbound.io” API group, they’ll be able to read the description provided by the CRD and see that, “Instance is the schema for the Instances API. Manages a VM instance resource within GCE.” With confidence that they’ve found the correct base CRD to build on top of, they can now familiarize themselves with the API documentation of the CRD, especially the “spec” field.
Upbound Marketplace makes it easy to learn which fields are required objects under the “forProvider” field. This tells users these fields will need to be set when they instantiate them as part of their API abstraction. For example, scanning the fields of the Instance CRD, users can see that “boot disk,” “machineType,” “networkInterface” and “zone” are required.
machineType is required, whereas minCpuPlatform is not
If the required fields are an “object” type, users can recursively expand the object’s fields and see the required fields for that nested object.
API Examples
The Marketplace is also able to provide examples for each API. These examples are functioning .yaml configs that users could submit directly to their control plane to create instances of this CRD as a managed resource. This is a useful tool that gives users a launch pad for writing .yaml config.
Discovering Configurations
A third way the Marketplace is useful for Day-Zero Crossplane users is it can be used to discover Crossplane configurations. Many of the configurations in the Marketplace are reference implementations with permissive licenses. Configurations can either be discovered by scrolling down on the main page or using the search bar. If you use the search bar, make sure to change the filter type to “Configurations.”
Users may want to build an API for which there is already an implementation (like a Kubernetes cluster or PostgreSQL instance). It is completely fair practice to use these as launch pads, since they already have a number of fully completed compositions. If you click into the “platform-ref-gcp” configuration, you can explore the XRDs and compositions that make up the configuration.
All of these examples are but a few ways that Upbound Marketplace bootstraps platform builders’ knowledge and accelerates them down the path of getting started building with Crossplane. There’s plenty more for Crossplane users to explore with the Marketplace, like publishing your own configurations and providers. If this is one of your first times hearing about Crossplane and you want to learn more, check out the getting started guide or join the community on the Crossplane slack.
Best,
Craig D Wilhite
This post was originally published on The New Stack here.