Skip to main content

What developer platforms offer to developers

Kubernetes became the API that container deployments are standardized on. Kubernetes is a de facto standard, no committee or association made it the standard, it emerged by many different vendors basing their portfolio on it.

Kubernetes brings a nice set of abstractions, an API, but the building blocks it provides are too low level for direct consumption by developers.

It also lacks components that would make it useful in practice by default. Good examples for this are the Ingress resource and the LoadBalancer service type. Kubernetes does not provide an implementation for these, so without 3rd party components, the deployed applications cannot be reached by end users.

So far, we have talked about third party components that are required to be installed on Kubernetes to make it useful in practice. These platform features are now mostly ready.

For developers, however, the workflow is not comfortable enough yet to adopt. To make Kubernetes easier on developers, the developer platform we are building needs to solve a set of problems.

Reducing boilerplate​

One thing that developer platforms must help developers with, is the authoring process of deployment manifests. When a developer wants to deploy a new service, they need to be assisted with a manifest baseline, so they can iterate quickly.

The Yaml​

Kubernetes has a powerful deployment manifest, or "the yaml" as people often call it.

It allows for great flexibility with its many options and knobs, but that also means that putting it together requires extensive boilerplate.

The bigger issue is that it's not easy to piece together a Kubernetes Deployment, Service and Ingress objects, as there is no go-to place besides the Kubernetes documentation.

Therefore, most people copy it from somewhere. If they need to extend it with new features, they search for a snippet to copy as well. When they start a new project, they copy their proven yamls.

At some point, they may want to make their yamls more clever, support variables, apply pieces conditionally, so they come up with some templating solution.

This scales to a certain point, but there has to be a better way. A developer platform supported way.

Helping the yaml authoring process​

Platforms help the yaml authoring process either with company wide Helm charts or with abstractions and defaults that help developers with the most common scenarios.

There are companies out there which maintain internal Helm charts, just like they do with Docker base images.

Another technique is to have application generators. When you start a new service, the generator creates all the necessary manifests, CI pipelines, and codebases that a typical service at your company needs.

A developer platform must reduce the boilerplate, either by abstractions, or generators. Plus, it has to help with the discovery process as well. So when you need to change an existing service, you should be able to figure out easily what options you have.

Deployment automation​

Once the deployment manifests are ready, there must be a deployment automation process that takes care of the deployment process in a repeatable, trackable way.

Continuous Integration (CI) systems are generally used for this task. The very last step of the CI pipeline is typically a deployment step. The pipelines either run on push or tag events on certain branches, otherwise you have to be able to trigger a deployment pipeline in the CI system.

Rollbacks also need automation because companies usually have ways to deploy to throwaway environments to preview a feature or to deploy a preview of a Pull Request.

Developer platforms help with overview too​

Developer platforms also serve as catalogs to find various services in and determine their health and deployment state. Dashboards are also good for seeing the big picture and discovering information or anomalies.

Such systems are Backstage or Gimlet Dashboard.

Developer platforms don't stand in the way of expert users​

Developer platforms can cater to expert users with features while providing escape hatches, so the experienced developer doesn't have to satisfy the platform just to get something done.

You know a developer platform failed, when experienced people are ready to go any length to work around the platform.