This X thread from the ever-insightful Kelsey Hightower has been living in my head rent-free for the past week or two. The entire discussion is worth reading, but what particularly caught my attention was the final statement: “Eventually, you'll end up automating the abstractions and repeating the cycle.”
I’ve been building platforms long enough to have seen this several times. I’ve seen the evolution from manually installing software via SSH and RDP to using automation tools like Chef, Puppet, Ansible, and Terraform. I also enjoyed seeing the abstraction levels rise from VMs and storage to things like Heroku, Kubernetes, and FaaS.
Innovate, leverage, commoditize (platform services)
Regardless of the tech used, the most successful platform teams I saw adopted the “innovate, leverage, commoditize” playbook. Simon Wardley has written a lot of interesting things about how this pattern can be applied in business.
If you’re building a platform, providing the correct abstractions (and APIs) for your platform components is vitally important. However, providing a mechanism to “automate the abstractions” and create other compounding higher-level abstractions is the key to long-lasting success.
I saw this with the rise of package managers (APT, RPM, etc), Chef cookbooks, and Terraform modules. Enabling teams to build platform components consisting of components (consisting of components) is the most effective way to scale; and the most effective way to innovate, leverage, and commoditize.
A rising abstraction lifts all boats: K8s, KRM, and Promises
As infrastructure has become more diverse and developer requirements more demanding, we’re now seeing a necessary rise in the abstraction of platform components. At the same time, the Kubernetes APIs and the Kubernetes Resource Model (KRM) have evolved to fill this gap. Platform-building tools like Crossplane, ArgoCD, and Kratix use the K8s API.
Diving a little deeper, let’s take a Kratix Promise as an example. Anyone in the organisation can write a Promise to expose an “X-as-a-service”, where X is required to enable the deployment and operation of their apps. Innovation is relatively easy.
Often, platform teams provide Promises for core services and related workflows to manage organisational policy and scalability requirements. Outside of this, any team can create their own services with Promises that build on the core Promises.
The Promise of offering everything-as-a-service
The real magic happens when the platform teams identify Promises that are being reused or have the potential to be leveraged by other teams or organisations.
For example, a financial risk management team creates a fraud detection Promise from lower-level Promises (consisting of several apps, compute, storage, etc). This type of Promise can be pushed to a marketplace and reused as a building block for other teams. Promises can be easily commoditized and reused within the bank, offered externally as-a-service, or form part of a larger Promise.
And as Kelsey stated, the cycle begins again...
Learn more about Kratix and the Promise API at kratix.io and please join the Kratix Slack.
Comments