Workshop
Platform Engineering
From Kubernetes clusters to paths that development teams use voluntarily.
Platform engineering means: one team builds the paths on which all other teams put their software into operation. Instead of every development team handling clusters, approvals and delivery on its own, there is a prepared, documented path. The comparison that usually holds is the publishing house: template, editing and printing come from the house, while what goes into the book is decided by the authors.
Whether such a path holds up is decided less by the choice of tools than by whether the teams use it voluntarily. This workshop therefore starts from the current state of your delivery. What platform engineering is in general is covered in What is platform engineering?
Four questions say more about your platform than any tool debate: how long does a new team need until its first own deployment? How many requests land with the platform team per week, and how many of them are the same one? In how many places would you have to build in a new requirement for all deployments? And do the teams use the intended path voluntarily? Every platform team can do this self-assessment in an afternoon. In the workshop we rate the four numbers together and derive the next three steps from them.
Schedule
Agenda
One day of presentation and discussion along your existing platform. Optionally a second day follows with hands-on work on your own cluster.
Modern Kubernetes
What is standard today and what you no longer build yourself: cluster provisioning, ingress, certificates, secrets, policies.
GitOps as a delivery model
The cluster as an image of the repository: where the model holds up, where its limits are and which pitfalls come with the rollout.
Terraform in a team
Modules, state, review and drift: how several teams work on the same infrastructure without overwriting each other.
Golden paths
Making the safe way the most convenient one: templates and standards that teams use because they are faster, not because there is an instruction.
Measuring developer experience
How to tell whether the platform helps: lead time, onboarding duration and ticket volume instead of gut feeling.
Internal developer portal
When a portal pays off and when it is just another interface that nobody maintains.
Operating model and on-call
Who runs the platform, how on-call is organised and what the platform team should not take on.
Practicalities
Who it is for, what you bring, what you take away.
Dates and terms are agreed individually.
Contact
Request this workshop.
Write to us which group is to be trained and what should be different afterwards. You get a proposal for scope and schedule.