Platform Engineering is an emerging trend as it promises a productivity boost for the product teams by optimizing the developer experience. As per Gartner, By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery. These Platform teams are responsible for building an internal developer platform (IDP). IDPs provide a curated set of tools, capabilities, and processes. Subject matter experts select and package them for easy consumption by development teams. The goal is a frictionless, self-service developer experience that offers the right capabilities to enable developers and others to produce valuable software with as little overhead as possible.
Image credit: Gartner Report on Platform Engineering
X-as-a-Service
X-as-a-Service component is critical in these Internal Developer Platforms, where X can represent any reusable component such as relational or No-SQL databases, vector stores, or CI/CD tools such as Jenkins. Today, these software are distributed in a cloud-native manner and hence come packaged as Helm Charts. So the question becomes how to deliver these Helm Charts as-a-Service. The goal is to offer the ability to provision this software X in a self-service manner and at the same time monitor and govern the provisioned instances in the background.
In this blog post, we present how Platform teams can build cloud-native APIs to deliver X-as-a-Service using our open-source Kubernetes Operator KubePlus. These APIs enable Product teams to provision platform components or tools in a self-service manner. For the Platform teams, the APIs provide a central point of control for applying any organizational policies related to governance, resource quota, and monitoring of service instances.
Cloud-Native APIs for Platform components or tools
Today most of the platform software is available as a Helm chart. However, the Platform team should keep these Helm charts private from the product teams. If they directly share the Helm charts, they will not be able to govern or manage the instances of the applications efficiently. Moreover, this burdens the product teams with understanding the Helm tooling. The ideal setup is where Platform teams create APIs for provisioning various platform components and product teams use these APIs to provision them.
Can Platform teams create such APIs for any platform components packaged as Helm charts? These APIs need to expose only those details that product teams need for configuring the instance of the software they are provisioning.
KubePlus Operator
Our KubePlus Kubernetes Operator addresses this need for Platform teams. It enables the creation of Kubernetes-native APIs to represent Helm charts on a Kubernetes cluster. Platform teams create the API providing a Helm chart as input. KubePlus creates a Kubernetes Custom Resource Definition (CRD) to represent this Helm chart on the cluster. Product teams can instantiate the platform service by creating an instance of this CRD.
Suppose a Platform team wants to enable its product teams to create Jenkins instances on demand. In the picture below, we see the Platform team defining the “JenkinsService” API (Kubernetes CRD) representing the Jenkins helm chart.
KubePlus creates the CRD in a cluster and generates appropriately scoped credentials (kubeconfig files) for performing CRUD operations on it. Platform teams can share these credentials with the product teams. Whenever a product team needs to create a Jenkins instance, they create an instance of this CRD. KubePlus Operator intercepts such requests and creates Jenkins Helm releases. The spec properties of the Kubernetes CRD wrapping the application Helm chart are the fields defined in the chart’s values.yaml file.
KubePlus uses the multi-instance multi-tenancy pattern when creating instances of the registered API (CRD). KubePlus isolates each instance in a separate Namespace. It adds a safety perimeter around such Namespaces using Kubernetes Network Policies and non-shared persistent volumes. It monitors the usage of CPU, memory, storage, and network traffic at the instance level. The collected metrics are available in different formats and can be pulled into Prometheus for historical usage tracking.
KubePlus has been verified to work correctly with Bitnami Helm charts. We have used KubePlus to provide Jenkins-as-a-Service to students in the Cloud Computing class at UT Austin.
Conclusion
Rapidly creating APIs for provisioning platform software components or tools is a key requirement of Platform Engineering teams to deliver them as-a-service. KubePlus enables the creation of such APIs from existing Helm charts. If you are a Platform Engineering team, check it out. It might be the solution that you have been looking for.
