The document discusses the use of Crossplane as a cloud-native solution for managing infrastructure with Kubernetes, emphasizing its role in platform engineering by creating an abstraction layer for development teams. It highlights scenarios where DevOps engineers automated the environment provisioning process and explains Crossplane's architecture, benefits, and drawbacks. The conclusion suggests that while Crossplane is still evolving, it offers valuable capabilities that may become increasingly beneficial in the future.

1. Platform Engineering:
Manage your infrastructure
using Kubernetes and Crossplane
Ahmed AbouZaid
November 2023

2. About
Ahmed AbouZaid
With 10+ years of hands-on experience and an M.Sc. in Data Engineering, I’m
passionate about DevOps and Cloud-Native, specializing in Cloud and Kubernetes.
I’m also a Free/Open source geek and book author.
I enjoy facilitating the growth of both businesses and individuals.
My favorite topics are DevOps transformation, automation, data, and metrics.
Find me at:
DevOpsHive.net | Tech.aabouzaid.com | LinkedIn.com/in/aabouzaid

3. Overview
● Scenario
● What is Crossplane?
● How it look like?
● Crossplane Concepts
● How Crossplane Works
● Pros and Cons
● Conclusion
● Resources
● Questions

4. Let’s have a look at a real-world scenario where the
DevOps engineers decided to build an abstraction
layer to be used by all dev teams (aka Platform
Engineering), and they found the solution!
Crossplane, the open-source control plane!
Scenario

5. Scenario (Cont.)
03
The dev teams follow the
principle of "you build it, you
manage it", but just for the
application, not the
infrastructure, because they
are not experienced with
Terraform.
01
A mid-size company has 10
development teams. Its tech
stack is mainly Kubernetes
for the applications and
Terraform for the
infrastructure.
02
Each team has a 2-week
sprint; at the end of the
sprint, they need to spin a
fresh env for the final
acceptance tests. That env
should have the Kubernetes
deployment for the
application, Cloud Database,
and Cloud Cache.

6. Scenario (Cont.)
06
With more coming custom
changes, it was hard for the
DevOps engineers to handle
all those requests even with
automation. Here the time to
build an abstraction layer to
be used by all dev teams
(aka Platform Engineering).
04
Each time a team needs that
new env, they ask the DevOps
engineers to push the magic
button to spin those new
Cloud env.
05
The DevOps engineers
decided to automate that
process, however, they
needed to implement 2
different systems for that:
the infrastructure
automation for Terraform
and the application
automation for Kubernetes.

8. What is Crossplane?
Crossplane is a Cloud Native Computing Foundation (CNCF) project
built on the foundation of Kubernetes to orchestrate anything.
At the core, it is an open-source Kubernetes add-on that extends
Kubernetes to enable the deployment and management of
infrastructure and services of various Cloud providers and
on-premises environments.
In other words, Crossplane is not just a tool but an extensible
Kubernetes operator and framework.

9. How it look like?
This is an example of Crossplane Claim, namely
PostgreSQLInstance from Google Cloud
Platform Configuration.
It’s same like any manifest of Kubernetes and
could be even be part of GitOps flow, Helm
chart, or Kustomize object.
You can also created your own composition
according to you needs.
apiVersion: gcp.platformref.upbound.io/v1alpha1
kind: PostgreSQLInstance
metadata:
name: super-app-db
namespace: super-app
spec:
parameters:
storageGB: 10
passwordSecretRef:
namespace: default
name: psql-secret
key: password
clusterRef:
id: platform-ref-gcp-cluster
writeConnectionSecretToRef:
name: platform-ref-gcp-db-con

10. How it look like? (Cont.)
Here is an example of a Crossplane claim based
on a Composition I’ve created that spins a new
GKE cluster. Full example at:
github.com/DevOpsHiveCloud/crossplane-composite
-resource-demo
apiVersion: cluster.devopshive.net/v1alpha1
kind: GKE
metadata:
name: ci
namespace: ci
spec:
name: ci-cluster
region: europe-west1
parameters:
cluster:
minVersion: 1.27.3-gke.100
nodes:
autoscaling:
minNodeCount: 0
maxNodeCount: 64
writeConnectionSecretToRef:
name: cluster-conn-ci-cluster

11. Crossplane Concepts
Component Abbr. Scope Functionality
Provider - Cluster
Creates new Kubernetes Custom Resource Definitions
for an external service.
Provider Config PC Cluster Applies settings for a Provider.
Managed Resource MR Cluster
A Provider resource created and managed by
Crossplane inside the Kubernetes cluster.
Composition - Cluster
A template for creating multiple managed resources
at once (think as a Terraform module).

12. Crossplane Concepts (Cont.)
Component Abbr. Scope Functionality
Composite
Resources
XR Cluster
Uses a Composition template to create multiple
managed resources as a single Kubernetes object
(think as a Terraform tfvars file).
CompositeResource
Definitions
XRD Cluster
Defines the API schema for Composite Resources
and Claims (think as Kubernetes Custom Resource
Definition).
Claims XC Namespace
Like a Composite Resource, but namespace scoped
(think as Kubernetes Custom Resource).

13. How Crossplane Works
Component Functionality
Crossplane Configuration Compose Custom API
Crossplane Providers Connect to Cloud API
Crossplane Runtime Manage External APIs (Create/Update/Delete)
Kubernetes Runtime
(API Machinery, Controller Runtime)
Events, Watch, Reconciliation, CRDs, OpenAPI,
Persistence (etcd), Run Workloads, Ingress, RBAC
Components of Crossplane powered Control plane

14. How Crossplane Works (Cont.)
Connect Compose Consume
Managed Resources
XRD
Composite Resource Definition
App
A Cloud API Composition Claim
Provider Configuration
Platform Team Platform Team Development Team

15. Claims are namespaced objects consumed by platform users (e.g., development teams)

16. Pros Cons
● Cloud Native, extensible, declarative,
API-driven using Kubernetes-style
● Could be used with the same Kubernetes
ecosystem tools (e.g. ArgoCD for GitOps)
● Stateless (unlike Terraform, no need to
manage the state)
● Already using Terraform providers and
support most of the Cloud services
● Bootstrap is challenging (it needs an
already running Kubernetes cluster)
● Relatively new compared to other solutions
(missing utils and helpers)
● Hard to debug and troubleshoot (you will
use “kubectl get events” a lot)
● It requires some time to get used to
Composition concepts (module-like config)
Pros and Cons

17. Crossplane is a great framework for managing infrastructure using the Kubernetes style
and benefits from the that ecosystem (ArgoCD, Helm, Kustomize, etc.).
There are many use cases where it can perfectly fit in already. And at the time of writing
these words (November 2023), the Marketplace has numerous enterprise and community
providers configurations. Also Composition Functions graduated to beta.
However, it’s a relatively new ecosystem and still evolving, so it might not be the optimal
solution for every workload. But it’s probably a matter of time to grow more. So, if it’s not
your fit now, consider revisiting in the future.
Conclusion

18. Resources
● docs.crossplane.io
● blog.crossplane.io/crossplane-vs-terraform
● blog.upbound.io/composing-a-platform-by-patching-crossplane-resources
● innoq.com/en/articles/2022/07/infrastructure-self-service-with-crossplane
● thenewstack.io/crossplane-what-most-people-get-wrong-and-how-to-get-it-right
● masterpoint.io/updates/passing-on-crossplane
For more resources:
github.com/DevOpsHiveCloud/awesome-crossplane

19. Thank You :-)
LinkedIn.com/in/aabouzaid
Tech.aabouzaid.com
Questions?
DevOpsHive.net