Backstage is a framework for building developer portals. Kratix is a framework for building platforms. The two technologies were designed to work perfectly with one another.
Kratix takes the design position that Kubernetes is ubiquitous in most organizations. This choice has enabled us to build Kratix by extending the Kubernetes API to provide a consistent platform UX experience. Every time you load a Promise into Kratix you are extending the K8s API through the creation of custom resource definitions (CRDs), controller processes and custom resources. Platform teams often wish to abstract away this complexity and provide higher abstractions to ease platform usage – not just in the case of Kratix but in the case of all internal platforms. This need for simplicity has led to an exciting rise of technologies such as Backstage.
Backstage is a framework that enables UIs to be declaratively created with the aim of unifying infrastructure tooling, services, and documentation to produce a great developer experience. The difficulty with Backstage is it’s plugins often require complex backends that are required to be written in Javascript. Javascript is great for front end development but sadly less so for unifying infrastructure concerns.
If you wish to build a Backstage workflow that depends on Terraform, Kubernetes and an off-platform technology such as SAP then you will be left with an integration Problem. The Backstage plugin managing the workflow would need to orchestrate all of those integrations to achieve the required results. This could be considered a leaky abstraction and leaves your UX with too much knowledge of the underlying platform. This design also introduces a high cost of change if you wish to introduce another UX technology. In our experience Backstage – and UI architectures in general – shine when their responsibility is limited to the UX experience of the platform not being the source of knowledge on infrastructure orchestration. This is where Kratix can really compliment Backstage.
Kratix is the framework for building platforms. A platform team can compose their Kratix-built Platform by loading in new capabilities via a powerful abstraction known as Promises. Promises provide the perfect surface area to orchestrate the concerns of the platform. To take our example from above, the platform team needs to orchestrate Terraform, Kubernetes and off-platform tools such as SAP. With Promises they define a single consistent API for platform interaction – the perfect abstraction for a tool like Backstage to interact with. Promises also provide built in Pipelines, and via the simple building blocks of containers the platform team can orchestrate any other tools such as Terraform and SAP.
Building on the ability to define Backstage plugins in a declarative way, Promises provide a single declaration of both the API and the matching UI. When a new Promises is written to include Backstage configuration, then once installed in a cluster, the Backstage portal is immediately updated with UI views that represent that Promise – for free driven by Kratix.
If this is something you think would help you, contact us for a more in depth demo and help getting started quickly.
In summary, it is important to keep the areas of responsibility in your platform design clear. Backstage is brilliant at building your UX portals and can provide a rich user experience to enhance your underlying platform usage, but it relies on that clean API to be successful. Kratix is the tool that Platform Teams can use to build their platform, to integrate existing tooling and to a build rich platform experience, Promise abstractions enable existing tools chain to be integrated cheaply and easily while also designing a first class Backstage UX. To get the best out of it use the right tool for the job and drive Backstage from Kratix’s simple declarative APIs and keep the areas of responsibility clear.