Skip to main content

Developer platforms built on Cloud Native tools

There is an industry joke going around about the learning curve of cloud native, this CNCF landscape image encapsulates it perfectly.

In reality, the situation is not this bad, but the truth is, cloud native benefits from having a core concept to build the process around.

Organic efforts often fall short to fully make use of the tools offered by the CNCF. Or they can take many quarters addressing the latest practices in deployment, security, and developer experience.

Organic efforts take time​

I have seen organic platform building efforts go through very specific phases of maturity. Covering cluster features and deployment baselines first.

But organic efforts often do not reach advanced concerns, like network policies or advanced rollout strategies. This is somewhat sad, as cloud native has so much to offer.

My platform building efforts also started organically. First, a CI deploy plugin, then a CLI to encapsulate common developer actions. First, as a part-time effort, then focusing on developer experience full time.

Only over time, as I built platforms for more companies, could I really address the advanced concerns.

What this book is helping you with​

This book is set out to show you how to build a developer platform on top of Kubernetes.

This puts focus on decisions that are around deployment, security, observability, and operability, resulting in a shared baseline, a developer platform used by many teams. To benefit from this, we also created a public knowledge base, where people like you can go and ask for help.

Well-known industry standard tools to create a developer platform​

This book focuses on well-known industry standard tools from the Cloud Native landscape. We use these components to provide Kubernetes features to create a developer platform.

As you know, Kubernetes is a platform of platforms. It provides a common API that every vendor in the tech industry embraces and provides extensions to the default features of Kubernetes.

There is a minimum set of tools that you always want on your cluster, and there are optional ones. This book shows you a set of tools that cover a wide range of features: from ingress to security components.

Our assumption is that you know your way around Kubernetes, even installed some tools on it, like an ingress controller or a custom application.

Kelsey is right, and this book is going to help you with most of those concerns.

Except with the glue part. Glue usage is actually going to be limited, thanks to the gitops approach we are taking.

Platform components​

We are going to cover a large number of Cloud Native components.

Here is an exhaustive list:

  • Ingress Ngingx controller
  • CertManager
  • Prometheus
  • Grafana
  • Loki
  • Tempo
  • Grafana Cloud
  • Sealed Secrets
  • External Secrets
  • Kyverno
  • Linkerd
  • OAuth2 Proxy
  • Velero

In each chapter, you will get:

  • a conceptual introduction
  • a basic feature introduction
  • daily workflow tips
  • guidance on how to perform common maintenance tasks

You want to get started, don't you? Let's just stop for a moment before we jump in, and cover a guiding principle for building developer platforms.

Before jumping in: a guiding principle for building developer platforms​

Developer platforms abstract away complexity. There are two mistakes one can make here:

  • requiring too large upfront effort to adopt the platform
  • having too rigid abstractions that trap users

Ideally, your developer platform builds on the ecosystem's de facto tooling, not reinventing existing solutions. This also gives advanced users the possibility to default to well-known tooling, if their abstraction becomes limiting.

PaaS solutions often make the mistake of providing their many benefits to small niches of teams only. The moment your needs don't fit their abstraction, you are constantly going to fight the tool.

So as a rule of thumb:

  • stairstepping is a good approach: allow teams to adopt your platform in steps. Don’t require them to do enormous upfront work
  • you should also provide an escape hatch for advanced users in situations that don't quite fit your abstraction