Want to learn more how to build your platform with Kratix? Get in touch!
The modern digital organisation is populated with customer-focused teams delivering business value. These teams need to create differentiated products for their customers, but are too often dragged into wrangling commodity infrastructure components. This is the "Platform Gap", previously discussed in Crossing the Platform Gap.
The platform gap tends to increase as organisations scale, since the number of requirements, policies, compliance requisites and business rules grow. Different teams spend increasing amounts of time dealing with these sets of requisites, which in turn means they spend less time adding value to the products they build.
An internal platform should make the customer-focused teams more productive, efficient, and secure.
A direct reaction to this gap is the development of an internal platform, created based on the discovery and understanding of the common needs of the teams within the organisation. The internal platform should serve to reduce cognitive load for its users by moving towards an “as-a-service” interaction mode.
What makes a good platform?
There’s a lot of information out there right now about the growing trend of Platform Engineering teams building their own internal platforms. Regardless of what you name your teams and which engineering practices you use, chances are good that you have an internal “platform” of some description.
The platform can take many shapes, for example: an email address where users can request services, an account on a public cloud, access to a hosted Platform-as-a-Service (PaaS) product, or access to a Kubernetes cluster.
Although all of the above-mentioned examples work at different levels, they also bring a new set of problems. It often means:
Teams are blocked while they wait for the provisioning of the infrastructure
They still have to deal with the cognitive load associated with the platform solution, such as the cloud-specific APIs and services
Compliance, governance, and other business requirements are still responsibility of the application teams
Every application team is, in a way, running their own platform
A good platform aims to minimise the problems above. It is on-demand and self-service, allowing teams to get what they need instantly. It reduces cognitive load for its users by meeting those needs "as-a-service", with business rules automatically applied to the created services. It allows for a variety of skill sets, with a good set of defaults for the average users while not blocking advanced users from getting exactly what they need. It provides more than a set of services, but raises the "value line" by providing developer experiences, like fully-configured environments.
You can't buy your Platform
A corollary of raising platform abstraction levels is that you can’t just buy what only your organisation needs. You can get a long way by using public clouds or a PaaS, but to optimise for the problems above you’ll need customisation.
The internal platforms and software solutions are nothing more than a codification of your business’s abstract processes, workflows, and opinions—the essence that makes your company unique.
Public Cloud, OSS ecosystems, and off-the-shelf software are all part of the solution. However, mature 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.
How Kratix helps you build your Platform
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, encapsulating the concept of golden paths in a single Promise, i.e., 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. Platform teams can start by hand-picking Promises from the Marketplace and providing those to the application teams. Over time, as the needs become clearer based on feedback from the platform users, the platform itself can evolve. High-level Promises can be created by combining lower-level Promises, delivering more value than the sum of its parts. Kratix makes dealing with the growth of requirements easy.
Kratix is built on top of Kubernetes and provides multi-cluster and off-cluster scheduling and dependency management. You install Kratix into a ‘platform’ cluster, and then register your worker clusters. When an application team requests an instance of a 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.
A central part of Promises is the Pipeline. Through the pipeline, you can inject the platform opinions and business rules. It allows you to do any off-platform orchestration required by your organisation. It’s how you encode the 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.
You can check out Kratix in action on kratix.io.
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.
Additionally, the pipelines are composed of multiple containers that run sequentially—platform teams can write the Slack alerting container image once, and re-use it across multiple Promises seamlessly.
Crossplane
Crossplane provides a Kubernetes-native approach to handling the lifecycle of your cloud infrastructure. With Crossplane, you’re able to declaratively state what cloud services you require across any cloud provider, which allows you to iterate on your platform quickly.
With Composite Resources, platform teams can define what components need to be instantiated in the cloud provider, abstracting away the complexities of cloud infrastructure and providing the platform users with a clean API to request their services. In addition, it allows for the API to remain unchanged even when the underlying cloud infrastructure changes.
Kratix and Crossplane complement each other very well. By combining both tools, it becomes even easier for platform teams to create and provide full developer experiences, like golden paths, to the platform users.
Paving a golden path with Kratix and Crossplane
Let's imagine your application teams require Postgres and a monitoring tool for their environments. For production-type of environments, they 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-type environments, their requirements are less strict and they would benefit from having faster services. Your organisation also wants to keep costs low wherever possible. You decide to go with in-cluster Postgres backed by an Operator, and a simple OSS Prometheus setup.
With Kratix, you can author a single Promise that delivers on the application team's needs for both types of environments. The demo below will cover this scenario.
Demo: on-demand developer environments
We will start by creating three Kubernetes Clusters with KinD:
A Platform Cluster, where Kratix and the Environment promise will be installed
A Dev Cluster, to run Dev-types of workloads
A Prod Cluster, to run Production-types of workloads
On the Production Cluster, we will install Crossplane with the AWS Provider. We will later install Crossplane resources through the installation of an Environment promise.
With the clusters ready and registered with the Platform, we can go ahead and install the Environment Promise in the Platform cluster. In the Promise definition, we determined what should be installed in which cluster at Promise installation time. For this Promise, it means:
Installing a PostgreSQL Operator and Prometheus in the Dev cluster
Installing Composite Resource Definitions and Compositions for a RDS PostgreSQL database and CloudWatch
Once the Promise is installed, developers using the platform can now request an environment and get exactly what they need, on-demand and self-served.
To request a new environment, the user must provide the type (prod or dev). This API is defined within the Promise and can be extended to take all sorts of arguments—like the DB size, region, or version—if the platform team later learn their customers need different configuration options exposed.
Switching hats now to a developer using the Platform, let's send a request for a new development environment. When the request comes in, Kratix executes the Request Pipeline. The pipeline determines what should be instantiated based on the type of environment. For dev, it's the open source Postgres distribution and Prometheus. These workloads are placed onto the dev Worker Cluster, which is primed with the Operators. Once the provisioning completes, the developer can start using the environment.
For production environments, the pipeline 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 are two Crossplane Claims for the resources. The workloads get assigned to the production cluster, and then Crossplane reconciles these requests and creates the services in the 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.
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.
Conclusion
In this blog we’ve summarised what it takes to build great platforms and how platform teams can, by leveraging open source projects like Kratix and Crossplane, provide more to developers than simple access to low-level services. Instead, platform teams can raise the value line of the platform and deliver entire developer experiences as-a-service.
We, at Syntasso, are experts in building platforms. If the above sounds interesting and you’d like help in shaping your platform with Kratix, please get in touch for a chat or explore Kratix's docs.
Cover photo by by Taylor Heery on Unsplash
Comments