In this blog we’ll discuss how Syntasso is making it simple to build custom platforms using OSS projects Kratix and Crossplane. We will cover:
What is Platform-as-a-Product?
Pave your golden paths
How PaaP helps with paved paths
How Kratix helps you build your PaaP
Pave your development path with Kratix
Pave your production path with Kratix and Crossplane
Introduction
There’s a lot out there right now about the growing trend of Platform Engineering teams building their own internal platforms. Regardless of how you name your teams and what set of engineering practices you use, chances are good that you have an internal “platform” of some description.
This platform often looks like a combination of public cloud services, open source tooling and internally written code, wired together to offer developer workflows. Curating this set of technologies into a coherent, user-friendly, easy-to-consume experience is hard.
This platform can also look like paying to use a Platform-As-A-Service (PaaS). You’re able to get started more quickly, but PaaSes often make it difficult to enable the customisation options you need for your own opinions and workflows.
We think Platform Engineering teams can balance the build vs buy equation—we see it is possible to simplify the platform building experience; to incorporate developer needs; and to customise your offerings based on business requirements around security, compliance and more. To demonstrate we’ll use the open source tools Crossplane and Kratix to enable building a Platform-as-a-Product (PaaP) that offers better developer experiences.
What is Platform-as-a-Product?
Platform-as-a-Product is what happens when you apply a product mindset to your internal platform. It is a user-centric approach aimed at understanding the needs of the platform consumers, most often application teams, and delivering a valuable platform that meets those needs, whilst minimising complexity and friction. The needs of the application teams evolve over time, and the platform product must evolve to match those needs.
Platform products often begin with quick wins, such as integrating off-the-shelf or cloud databases, application serving, networking, and so on. Building these services internally would be wasteful, and the range of off-the-shelf services is continuously improving.
Maturing internal platforms incorporate needs that are unique to the organisation and extend beyond what's provided by cloud services, such as in-house tooling, security, compliance, governance, network topologies and more. This is why platform teams are needed in organisations at scale; only a team with the context of the organisation can provide the high-value, custom aspects of the internal platform.
Pave your Golden Paths
One common pattern we’ve observed is platform teams that spin up on-demand environments for application teams. Organisations recognise that fast deployment of opinionated environments composed of all necessary software configured to operate together is essential to delivering high value to their customers. The pattern of simplifying workflows to provision environments is often referred to as providing “paved paths” or “golden paths”.
The creation of paved paths is highly specific to an organisation and requires careful curation to incorporate the right level of guidance whilst still providing flexibility. Curation is only successful when platform teams collaborate with application teams to ensure their needs are identified, understood, prioritised and delivered.
Implementing paved paths is non-trivial. Platform teams often need to create and configure both internal tooling and cloud services and adhere to company-specific workflows to ensure billing, security and audit supply chains are adhered to, all whilst keeping velocity high and costs low.
How Platform-as-a-Product helps with paved paths
Let’s consider in more detail what a paved or golden path for an application team looks like. It might include a complete environment setup, with the networking, integration, security, governance, compliance, and deployment aspects of the software delivery pipeline all available on-demand. This can be made more complicated when requests are made for separate ‘development’ and ‘production’ golden paths.
As our platform team is treating the platform-as-a-product they take this requirement, prioritise it and want to build it out. But how? This is where the unique combination of Crossplane and Kratix can help accelerate platform teams to deliver the right platform to their users.
How Kratix helps you build your Platform-as-a-Product
Kratix is the open-source framework to deliver Platform-as-a-Product. It enables platform teams to deliver value to application teams through Kratix Promises. Promises are written and installed into the platform by the platform team as the set of offerings that application teams have access to on-demand. Promises can be simple, such as providing a team an instance of Jenkins. They can also be complex; they can define the golden paths we wrote about above—one Kratix Promise can offer teams a complete development environment.
The complexity of Kratix Promises on a given platform grows organically as product development for the platform happens. The platform team has fast feedback with application teams, and the platform evolves as application teams’ needs change. Kratix Promises make encapsulating growing requirements easy, and they provide a well-defined API for the application teams to consume.
Kratix is built on top of Kubernetes and provides multi-cluster and off-cluster scheduling. You install Kratix into a ‘platform’ cluster, and then register your worker clusters. When an application team requests an instance of a golden path Promise, the scheduler places the workload on the correct cluster based upon the Promise definition. For example, a request for a golden path Promise for a development environment would provision the services for the environment only on development clusters.
When an application team requests an instance of a Promise, a Kratix Request Pipeline produces the workloads that are installed into the worker cluster via GitOps.
But the Kratix Request Pipeline does much more than producing workloads.
It allows you to do any off-platform orchestration required by your organisation. For example, the pipeline might make an API call to your organisation's billing application, send a Slack alert to the platform team, or pull down default secure Jenkins pipeline configurations that your organisation has mandated.
It also allows you to encode aspects of your golden path that aren’t directly related to the application team's needs but are critical for your organisation. Things like executing secure supply chains and completing billing checks.
And it allows this flexibility to scale. The pipelines are composed of multiple containers that run sequentially—platform teams can write the Slack alerting pipeline once, and re-use it across multiple Promises seamlessly.
Pave Your Development Path With Kratix
So we’ve explained Kratix and how it enables your platform teams to meet user needs by providing a curated platform product and paving golden paths within your organisation.
Crossplane provides a Kubernetes-native approach to handling the lifecycle of your cloud infrastructure. Being able to declaratively state what cloud services you require across any cloud provides a simple abstraction to work with and allows you to iterate on your platform quickly. Combining Kratix and Crossplane together makes it even easier for platform teams to create golden paved paths.
Let's imagine your application teams require Postgres and a monitoring tool for their environments. You decide that for production application teams need enterprise-grade versions of these services. You decide to offer AWS RDS and CloudWatch. You want to use Crossplane and its official AWS Provider so that you have high confidence that you can manage these services easily in Kubernetes.
For development environments your application teams need faster services with fewer features, and your organisation wants to keep costs low. You decide to go with in-cluster Postgres and a simple OSS Prometheus setup.
With Kratix, you can now author a single Promise that delivers on the application team's needs for both types of environments. The request for the Promise takes an input of type for environment, which can be ‘prod’ or ‘dev’. It can also take inputs for other details application teams may need to define, such as the Postgres size. When the request for a development environment comes into the Kratix platform, the Request Pipeline executes. Because the request is for a development environment, the workloads defined are for deploying the simpler open source Postgres distribution and Prometheus. These workloads are placed onto a worker cluster with the dev label. The application team has successfully self-served a development environment.
Pave Your Production Path With Kratix and Crossplane
When the application team requests a production environment, the Request Pipeline executes and produces the workloads for CloudWatch and RDS, which utilises Crossplane's AWS provider. Because Crossplane handles the complexity of managing the lifecycle of the cloud resources, all that the Kratix Request Pipeline outputs as workloads are two simple Crossplane claims for the resources. The workloads get assigned to the production cluster, and then Crossplane reconciles these requests and creates the services in your cloud. If the time comes when the platform team decides to introduce another cloud service, all they need to do is add an additional resource and let Crossplane do all the heavy lifting.
You paved a golden path for your application teams that allows the teams to have a seamless way to get all the services required to run their application in development and production. Success! You can continue to iterate from this point by collaborating and learning with the application teams to add/refine Promises to reduce their heavy lifting and make their lives easier.
For example, the platform team could identify that on-demand clusters are required and choose to enhance the environment Promise by adding the on-demand provisioning of the worker clusters using Crossplane to create instances of EKS, removing the requirement for the worker clusters to be pre-created by the platform team.
Or if you decide you want to move to a hybrid cluster approach you can easily combine the provisioning of cloud services across different clouds by installing and using multiple Crossplane Providers, like Azure and GCP to provision AKS and GKE clusters. Using Crossplane as a consistent way to manage all of your cloud services makes switching between them simple.
Summary
In this blog we’ve summarised at a high level what it means to treat your platform as a product and how it is possible to enhance the developer experience for application teams through pathing golden paths using Kratix and Crossplane.
Want to learn more?
Book time with our team or try out our workshop:
Platform Review A free 1-hour session with experts to review your platform.
Engineering Collaboration A free 1-hour engineering session to build your first Kratix Promise.
Build Your Platform A self-paced workshop that will enhance your platform engineering skills with Kratix.