Crossplane Curious? Marketplace Makes Onboarding Easy
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 the hassle of figuring out which properties to set or what sizes are outside 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.
The Marketplace promotes a set of popular providers on the front page, of which the GCP Crossplane provider happens to be one. Users can also use the search bar to browse a catalog of nearly 30 Crossplane providers. If a user were to search “Google,” two results would return: one implementation that is maintained by Upbound (the benefits are explained in this blog post) and one maintained by the Crossplane community.
The Upbound Marketplace already has popular providers like AWS and Azure, and the Crossplane community continues building more Crossplane providers with each passing week, making it easier to get started with Crossplane.
If a user were to click into the Upbound official provider, GCP, they’ll be taken to a page where users can browse what the provider has to offer. This page allows users to explore the API types available for them 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 of search terms. The Marketplace conducts searches based on a few fields exposed by the CRD (custom resource definition). For example, if you search for “VM,” you will get no results, but “instance” gets accurate results.
If a user clicks the CRD that has an “Instance” kind under the “compute.gcp.upbound.io” API group, the user will be able to read the description provided by the CRD and will see, “Instance is the schema for the Instances API. Manages a VM instance resource within GCE.” Confident that they’ve found the correct base CRD to build on top of, the user 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 that these fields will need to be set when they instantiate them as part of their API abstraction. For example, when scanning the fields of the Instance CRD, users can see that “boot disk,” “machineType,” “networkInterface” and “zone” are required.
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.
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.
A third way in which 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 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.
These examples are but a few ways that Upbound Marketplace bootstraps platform builders’ knowledge and accelerates them down the path to 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 your first time hearing about Crossplane and you want to learn more, check out the getting started guide or join the community on the Crossplane slack.