Modern platforms do not operate in isolation. They depend on manual approvals, external systems, the availability of other resources, and compound building blocks. Until now, modelling these asynchronous processes in Kratix has been inelegant, and the underlying Kubernetes pods orchestrating the tasks could remain alive for a long time.
Rolling out changes across a platform fleet is one of the hardest parts of being a platform engineer. Move too fast, and you risk availability. Move too slowly, and the platform becomes a bottleneck.
Imagine you are responsible for maintaining a suite of production services. Some support apps that are more business critical than others - maybe they are customer facing, or back time-sensitive business functions. You receive a notification of a vulnerability that you need to patch. How do you ensure that upgrades to those business critical services are successful and won’t cause downtime or outages?
These SDKs excel at everything from bootstrapping the initial Promise for your organisation's platform to ensuring consistency and testability across all the Promises your platform teams create.
Defining and building platform APIs and services is no easy task in general. Platform engineers who adopt Kratix and create bespoke services – which we call “Promises” – often encounter a significant "wall of bash" when starting their journey towards taming their underlying IaC config, YAML, and API calls.
