Crossplane Community Day December 2020 Recap

Next-gen DevOps with Crossplane by Tobias Brunner

Lightning talk at the Crossplane Community Day December 2020

I attended the Crossplane Community Day (actually evening for the Europeans) on December 15th 2020 which was titled „Modernizing with an API-centric Control Plane“.

In my lightning talk „Crossplane as a cornerstone in a next-gen hosted DevOps platform“ I introduced the project which we’re currently working on with Swisscom and revealed the Open Sourcing of our Crossplane Open Service Broker API integration. This Open Service Broker (OSB) integration with Crossplane allows to consume Crossplane objects by any OSB capable client infrastructure like Cloud Foundry and makes it possible to offer any kind of services via the many Crossplane providers. More of what we do with this integration will be written in an upcoming blog post. The application is currently in a PoC state and available on GitHub under https://github.com/vshn/crossplane-service-broker-poc. We’re actively working on the production implementation in https://github.com/vshn/crossplane-service-broker.

Crossplane was released in version 1.0 at this event. I was eagerly waiting for this release since about a year when we first discovered Crossplane and experimented with it. Congratulations to the Crossplane community and contributors and I’m really looking forward to see what happens with Crossplane in 2021 and beyond – also what we’ll do with it at VSHN. Exciting times ahead!

There where many great and very interesting talks to listen to. The recording of the full event will be available in the next days, check back the social media channels to get notified about it.

During the event I was active in the Crossplane Slack channel and was able to capture some very interesting questions and answers around Crossplane and the wider ecosystem.

Here are my highlights quoted

Question

Why would one want to use Crossplane rather than the hyperscaler’s operators, like AWS ACK and Azure Service operator directly?

Answer

Good question – I think the key reasons you might choose Crossplane boil down to the XRM and Composition.
XRM is the Crossplane Resource Model – if you’re using more than one cloud, our CRs work the same way across them all. Similar patterns.
(Or even if you’re using providers for things like SQL users and database, or Helm charts.)
Composition is a layer we provide on top of XRM compliant resources that let you define your own APIs (your own CRs) without writing code. So you can build your own classes of service and opinionated APIs atop those raw low level APIs.

Also bears mentioning that we are working with them on code generating crossplane controllers from the same codegen pipeline, so below a certain level of abstraction we will be sharing code for interacting with provider SDKs.

https://blog.crossplane.io/accelerating-crossplane-provider-coverage-with-ack-and-azure-code-generation-towards-100-percent-coverage-of-all-cloud-services/

Question

How about advantages if any for on-prem private clouds?

Answer

The answer is about the same there, as compared to something that might operate databases etc on-prem. Admittedly though our provider support for on-prem is lighter on the ground. Definitely appreciate contributions there!

The other thing I’ll add here, is Crossplane can give you a cloud-like provisioning experience in your on-premises environment which can be a big win for developers.

Question

Is it correct that external resources are not namespaced in Crossplane? If so, what is the rationale? If there’s a design doc that covers it, that would be great

Answer

With the whole separation of concerns thing we treat managed resources (our CRs that represent ERs) as a platform / infra concern, so they’re cluster scoped like a node or a PV. The claims that represent them are namespaced. This is kind of handy in two ways:

• If you imagine an API server that’s dedicated to Crossplane, the platform team can view all the managed resources in one big global view, but see the claims that represent those resources broken down by namespace (i.e. often by team).
• Sometimes we don’t want to offer a claim for an XR – e.g. a VPC XR is probably only something the platform operators want to control.
• The big one – sometimes we want cross resource refs that would violate namespace boundaries. Imagine for example the platform folks create a VPC XR, and folks making claims down in namespaces can make a claim for a database that they want to be connected to that VPC. If the VPC was off in the “platform-infra” namespace or whatever they’d need to reference it across namespaces.

An alternative answer is that we designed for a world where we can partition concerns just like PV/PVC

Question

Re the current Terraform talk – is the idea to use Terraform providers to generate Crossplane CRDs and controllers that run independent of Terraform… or is the idea to proxy the CRDs through an in-cluster Terraform controller?

Answer

More the former. Terraform is actually a couple of processes running together – each provider is a process that has a gRPC API, and the terraform CLI tool sits in front of that. We run those provider binaries, but we put a Kubernetes controller in (i.e. a Crossplane provider) in front of them instead of the terraform CLI.

Furthermore I discovered some new tools:

• Kubernetes External Secrets: „Kubernetes External Secrets allows you to use external secret management systems, like AWS Secrets Manager or HashiCorp Vault, to securely add secrets in Kubernetes“
• CDK for Kubernetes: „Define Kubernetes apps and components using familiar languages“ with integration for Crossplane discussed here: Crossplane issue 1955.