Cloud Native Computing Foundation Crossplane Community Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Crossplane and Promises - Steve Cavallo, Cloudcheckr

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Crossplane and Promises - Steve Cavallo, Cloudcheckr

Configuration management has become virtually standard in every industry. As we have moved to infrastructure as code, and most recently serverless, the tools have changed but many of the principals for governing systems have remained the same. In this presentation I will talk about the Promise theory and how it applies to several of the most popular infrastructure-as-code solutions - Crossplane, terraform, cloudformation. https://www.linuxjournal.com/content/promise-theory%E2%80%94what-it Most notably, how Crossplane keeps promises and how this is fundamentally different than other existing toolsets, to quote Mark Burgess, "by shifting the attention away from what changes (or which algorithms to enact), onto what interfaces exist between components and what promises they keep and why." The approaches to describing systems will have different output and challenges when applied at scale.

A

Hi, I'm steve cavallo and I'm going to talk about cross plane and promises.

A

Promise theory is a way we can think about interactions between agents within a system in promise theory we say get into the state. Instead of do this we're familiar with working the promise theory way, maybe from using chef and puppet and other config management tools or most likely from using kubernetes in kubernetes. We define and think in terms of end state in kubernetes you don't write a stateful set script. You define and apply a stateful set manifest and kubernetes promises to attempt to get into your desired state.

A

Kubernetes uses a very literal implementation of promise. Theory and many benefits can be realized at scale when promise theory is applied, it's also best if we can break things up into small sets of primitives, which can be applied independently.

A

How does it all stack up and how can we apply promise theory to some existing tools in terraform? We define our model in hcl, but the challenge in terms of promise theory is we don't know exactly what our model is until we run a plan or apply to generate it until then. It's not a true promise in our first example, we're creating a spot instance, but we don't know what it will evaluate to until runtime and in fact we don't know what it will evaluate to in multiple different environments until runtime.

A

In our second example, we didn't know that this terraform apply would destroy our resource.

A

Any human invention required makes it difficult to support at scale.

A

With terraform there's also no control plane, so there's no guarantee of system state and we have no way of knowing whether our existing promises are being kept.

A

Where terraform is great, though, is determining what changes to enact to bring a system into the desired state. However, at scale managing anything is procedural and when terraform must be run in a specific order or has specific dependencies, it gets very difficult to manage.

A

Taking my previous examples. If a human has to intervene to see if any resources will be changed as part of a deploy, it gets very difficult to to maintain its.

A

Skill formation allows definition in json yaml with very low interpolation. It is much closer to a promise.

A

Cloud formation also has a control plane, so control theory can be applied.

A

We have much better idea of what the state of our system is.

A

So at scale with cloud formation, we get high predictability of outcome. We have a better model of our end states. We have a control plane that can maintain drift in states.

A

We still have the challenge, though, when we have many cloud formation stacks with dependencies and specific orders that it becomes imperative.

A

Cross plane allows definition in json, yaml and by nature must be aligned with promise theory, because it's a kubernetes operator very, very close to the little literal interpretation of promise theory, because it has a controller. It can maintain our state. So, as you can see my example, we have controllability observability and the controller ensures that we're in our expected state so at scale. Crossplane gives us high predictability of outcomes.

A

In fact, all of its dependencies are promises you can see. In my example, I am role policy attachment policy. R ref is a promise. A roll ref is a promise. We no longer have to worry about order. Crossplane will keep retrying until those promises are satisfied and versioning will allow us to verify which promises are deployed.

A

Now in this screenshot I have all of my cross plane. I am rolls inversions and visibilities into various environments. So using your favorites flavor of cd, you can get visibility into what versions of the promises exist and whether they're in the promised state or not.

A

In the promise theory, we can think of many many resources, each maintaining the promise date and trusting all the other actors in cooperation in harmony so at scale we can see cross planes, maintaining all of its promises across multiple systems and much larger systems.

A

In conclusion, cross plane keeps its promises.