The document discusses the concept of application-driven infrastructure using Crossplane, emphasizing the importance of DevOps practices such as shift-left and shift-right methodologies in the software lifecycle. It explains how Crossplane allows platform teams to create higher-level self-service APIs for developers, improving automation, consistency, and collaboration across infrastructure management. Additionally, it highlights Crossplane's ability to manage resources as part of the Kubernetes ecosystem, although it notes the complexity and development stage of its providers.

1. Application-driven
infrastructure with
Crossplane
17/11/2022

2. IMAGE GOES OVER HERE
Daniele Monti
● Platform Engineer @ SparkFabrik
● GitHub: https://github.com/Monska85
Twitter: @danielemonti
Linkedin: https://www.linkedin.com/in/danielemonti1985/

3. DEVOPS AND SHIFT LEFT PRINCIPLES

4. “DevOps is a set of practices that combines
software development (Dev) and IT operations (Ops).
It aims to shorten the systems development life cycle and to provide
continuous delivery with high software quality.”
https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/

5. “The shift left approach consists in pushing the beginning of the quality related
tasks at earlier stages of the software lifecycle.
Shift left as a principle was created thinking about testing, but now it involves
also other disciplines such as security and deployment.”

6. Shift left
Lifecycle
SHIFT LEFT & CLOUD NATIVE
Quality related tasks
Software lifecycle
● This approach reduces risk since many issues are addressed long
before the release
● Releases can be made more quickly and with better quality
● Earlier tests ensure most problems are caught much earlier, when
they are easier to debug and fix (less problem detection, more
problem prevention)
● More reliable estimations of effort and resources

7. SHIFT LEFT & CLOUD NATIVE
Security concepts must be introduced in the early stages, so
the entire application development workflow will follow
defined security standards.
This prevents code rewritings close to the deployment and
leaves only minor security fixes for the production checks.
Shift left
Security
DevSecOps

8. SHIFT LEFT & CLOUD NATIVE
Shift left
Costs
This graph is based on the data taken from The Economic Impacts of
Inadequate Infrastructure for Software Testing, National Institute of
Standards and Technology (NIST) report. Read the entire document here.

9. SHIFT LEFT & CLOUD NATIVE
Shift right
Complements
to shift left
Shift right is not the opposite
of shift left
It takes place in the production environment. The unexpected
behaviour and the performance analysis will produce more
value in the production environment.
The continuous deployment of small changes and the
monitoring of the system are the best practices used
in this stage.
The chaos engineering is the discipline of testing resilience of
the system in the production environment.

10. TO SUM UP:
● Shift left spreads the QA tests during the entire
process
● Shift left is not only related to the software testing
● The automation of these tasks is mandatory
● Having less problem detection and more problem
prevention has an high impact on the costs
● Shift right complements the shift left
SHIFT LEFT & CLOUD NATIVE

11. SHIFT LEFT & CLOUD NATIVE
You build it, you run it.
2006 - Werner Vogels, CTO and vice president of Amazon

12. SHIFT LEFT & CLOUD NATIVE
Cloud native
model
Ops for Dev
“Giving developers operational responsibilities has greatly enhanced the
quality of the services, both from a customer and a technology point of
view.” - A conversation with Werner Vogels
The old model of throwing the artifact over the wall of confusion1
and then
forgetting about it is no more suitable in the cloud native model.
1. The “Wall of Confusion” is a DevOps term popularized by Andrew Clay Schafer (AgileRoots 2009 ~17:00 mark) and Lee
Thompson (Dev2Ops Interview). It refers to the phenomena where one group in a value stream approaches their job as
complete when they’ve passed it onto the next group.

13. INFRASTRUCTURE AS CODE & PLATFORM ENGINEERING

14. Infrastructure
as Code
IaC & PLATFORM ENGINEERING
● Easier to read, maintain and distribute
● Consistent over time: each deployment
has the same configuration
● Reusable code (modules)
and cost efficient
● Automation (no human errors)
● Self documented
● Versioned

15. Infrastructure
as Code
IaC & PLATFORM ENGINEERING
GCP
Deployment Manager
AWS
CloudFormation
AZURE
Resource Manager
...

16. IaC Terraform
Examples
IaC & PLATFORM ENGINEERING

17. IaC Terraform
Examples
IaC & PLATFORM ENGINEERING

18. IaC & PLATFORM ENGINEERING
Platform
Engineering
Cloud Services
Organization
Best
practices
Policies
Security
models
Platform
Dev team Dev team
Dev team

19. IaC & PLATFORM ENGINEERING
The Platform
The Platform offers a simple access
to a complex set of resources
The scope of The Platform is to expose a simply way (API) to
obtain a piece of infrastructure or a service encapsulating all
the organization rules.

20. IaC & PLATFORM ENGINEERING
The Platform
Interaction modes
There are only three ways in which teams should
interact:
● Collaboration: working together for a defined period
of time to discover new things (APIs, practices,
technologies, etc.)
● X-as-a-Service: one team provides and one team
consumes something “as a Service”
● Facilitation: one team helps and mentors
another team
The team interaction modes
https://teamtopologies.com/key-concepts

21. IaC & PLATFORM ENGINEERING
The Platform
API
Development team needs:
“Our new microservice needs a Postgresql database
and an S3-like object storage bucket.
The microservice will be deployed on K8S”

22. IaC & PLATFORM ENGINEERING
The Platform API
K8S + Terraform

23. IaC & PLATFORM ENGINEERING
The Platform API
K8S + Terraform
🚨 COGNITIVE LOAD ALERT 🚨
A new tool to learn for the
development team.
Hard to integrate with a K8S
CI/CD pipeline.

24. THE CLOUD NATIVE CONTROL PLANE FRAMEWORK

25. CROSSPLANE

26. CROSSPLANE
The Platform API
The Kubernetes way

27. CROSSPLANE
Crossplane enables platform teams to assemble infrastructure
from multiple vendors, and exposes higher level self-service
APIs for application teams to consume, without having to write
any code.
Crossplane extends the Kubernetes cluster to support
orchestrating any infrastructure or managed service.
Crossplane is an incubating project in
the CNCF landscape
Crossplane
CNCF Project

28. CROSSPLANE
Providers are Crossplane Packages that bundle a set of
Managed Resources and their respective controllers to allow
Crossplane to provision the respective infrastructure resources.
Each Provider package has its own configuration type, the so
colled ProviderConfig. This resource, for example, is used by the
provider controller to get the API credentials.
Providers are the core concept of
Crossplane
Crossplane
Providers

29. CROSSPLANE
Managed resource is the Crossplane representation of a
resource in an external system.
Managed Resources are the building blocks of Crossplane. They
are designed to be composed of higher level, opinionated
Custom Resources that Crossplane calls Composite Resources
or XRs.
Managed resources are the mapping
between K8S and the external services
Crossplane
Managed resources

30. CROSSPLANE
Anything with an API could be connected to a Kubernetes
cluster where Crossplane is running, giving you a CRD
representing each resource.
This model allows Crossplane to manage infrastructure pieces
or services (or whatever) using a specific provider for those
resources.
https://blog.crossplane.io/providers-101-ordering-pizza-with-
kubernetes-and-crossplane/ this is an awesome example on
how Crossplane could manage any API driven service.
Crossplane is extensible, thanks to its
provider model
Crossplane
Provider model

31. CROSSPLANE
The Platform API
The Kubernetes way

32. CROSSPLANE
The Platform API
The Kubernetes way
🚨 COGNITIVE LOAD ALERT 🚨
There are a lot of moving parts and many
things to configure, including some
properties that should be opinionated by
the platform.

33. CROSSPLANE
The composite resources are the way to create the high level
API and to leverage Crossplane to create your opinionated
platform.
With a single YAML manifest, with a small amount of
configuration, Crossplane will be able to create all the needed
managed resources.
Composite Resources are designed to
build the platform with the
opinionated concepts
Crossplane
Composite
resources

34. CROSSPLANE
The Platform API
Composite Resource

35. CROSSPLANE
Crossplane uses X as shorthand for Crossplane and
Composite.
This choice was made to avoid the confusion
between the kubernetes resources and the
crossplane ones.
Crossplane
Terminology
Custom Resource Definition
(CRD)
Custom Resource
(CR)
Composite Resource Definition
(XRD)
Composite Resource
(XR)

36. CROSSPLANE
Composite Resource Definition
(XRD)
Composite Resource
(XR)
Define
Composition
Use
Managed Resource
Managed Resource
Managed Resource
Application
Application team
Platform team

37. CROSSPLANE
Crossplane
K8S closed box
Crossplane can write all the connection
reference as secrets inside the cluster.
This is really useful to keep all the data
inside the cluster which could be used as
a kubernetes secret in the workloads.

38. CROSSPLANE
Crossplane
YAML for the win
● Consistency across resources
● Application and infrastructure are
deployed at the same time
● Simple text file human and machine
readable
● Versioned

39. CROSSPLANE
Crossplane
Deployment strategy

40. CROSSPLANE
Crossplane
Drawbacks
● The providers are still in development
version (0.x.y in semver)
● Another tool to maintain
● Another set of modules (XRD and
Composition) to maintain
● Balance between complexity and
advantages
● Static YAML

41. CROSSPLANE
Crossplane
Alternatives
● Pulumi
● Serverless Framework
● Terraform
● Rancher terraform controller

42. TO SUM UP:
● Offer the dev teams simple APIs to create
opinionated services
● Platform Engineers should package the organization
model into the Platform
● Crossplane is a framework to develop a custom
platform in the kubernetes way
CROSSPLANE

43. THANK YOU!