The past, the present and the future of platform engineering

The good old baseline is “iam an an developer, i write code - now i have to do stuff to continue writing code”. Most developers will continue on to “now i have to write scripts” on order to just do their jobs instead of working on infra.

These scripts evolve to tools which evolve into an internal platform (if everyone starts using it). Other base components can also feel like platforms (for example application servers).

The early day evolution

  • Hudson
  • Docker: Not really building platforms, rather standardized application packaging
  • Kubernetes (and Nomad + Swarm): A new concept of scheduling instead of jsut running the application in a container

=> We’ve been building platforms (or failing to build them) for years and years but now we kinda agree about what a platform is

Present

We have the base idea of a platform

graph LR
    ServiceConsumers-->|Consume through|HTTPAPI-->|Trigger work on|Controllers-->|So|Services
    ServiceOwner-->|Manages|Services
  • The fist question: Do we use public controllers (e.g. the cncf landscape projects) or build our own?
  • Result: Mostly a mix starting with public, realizing needs and expanding

Make it your own

  • Goal: Make the platform domain specific for your developers
  • Evolution: Tools like DAPR for developers or Crossplane for api-building
  • Build the API and Controllers first - dashboard, gitops, observability, … second
  • Remember that kubernetes can manage anything - not just containers

TODO: Steal image

Blueprints

Take all of the projects you need, combine them and hide the complexity High level architecture of internal platforms is the same as public ones (aws, …) but internal and built on kubernetes.

TODO: Steal images for platform blueprints (3 slides)

Future

  • Platform Engineering certification by the CNCF is on the horizon
  • Do we need to hide kubernetes from developers? Maybe -> The CNCF is starting groups to get app devs closer to platform engineers
  • More multi-cluster specialized tools are sprawling in the last year (scheduling, discovery, management)
  • AI things are happening and we should utilize it but not just by calling a llm directly and calling it a day -> e.g. dapr llm abstraction api
  • Platforms are not built in isolation, we need to help each other