Sorry I’ve been a little quiet the last few weeks - with 6800 attendees PlatformCon was amazing but kept everybody quite busy (if you missed it, you can check out the talk recordings here). The community and the momentum around platforms are growing incredibly fast. And the faster it’s growing, the more I get the question “where do I start?”. But before we can answer that, we need to answer “why should we start platforming at all?”.
Allow me a brief thought-experiment at this point and reverse that question into “when do we not need a platform?”. And the answer is pretty simple: if all you optimize for is deploying something against an infrastructure that already exists, if all you care about is a simple git-push-deploy flow, you certainly do not need a platform. A platform only makes sense if you need to optimize things that go beyond the simple update of an image. Meaning if anything in your architecture and the relationship between services and their dependent resources changes. That might be as simple as adding an environment variable, an infrastructure component, scaffolding a new service, updating infrastructure settings across a number of services, rolling back, spinning up a new environment or partially releasing between environments. Really anything that goes beyond the simple update of an image.
Because complexity is relatively low in the static git-push update case, but it exponentially increases with changes that touch the architecture or the environments the apps run in. This complexity, mushed together with an application's life-time, adds so much cognitive load to the individual contributor that they have the choice between distraction or dependency. Deal with it yourself or ask Ops. Both are ineffective.
And so the value of a platform is quite simple to make the impossible possible. Low distraction and cognitive load, low dependency on others, yet full flexibility. The keyword here is golden paths. Platform teams build golden paths for developers:
- By providing a standard way of changing configurations that just work yet doesn’t restrict them.
- By providing a CLI that gives you a new S3 bucket and injects the credentials as secrets into the container at run-time.
- By giving teams a scaffolding option that will deploy your nodeJS service in a fresh namespace, a pre-seeded DB and Route53 configured.
- By spinning up an environment with a 1-to-1 replica of production with an API call.
So this is why you start. And where? Piece of cake. Take 100 deployments. Ask yourself how often you do things that go beyond the simple update of an image. Then if you do it, how much time does that eat from dev and ops respectively? List all of them, force rank by time wasted, start with the one on top. And yes, it’s probably configuration management and not your fancy portal. This ROI calculator can help you figure things out, whether you are using Humanitec as a Platform Orchestrator or not.
Hope you’re enjoying a delightful summer, if you’ve had too much sun, here are a number of webinars you might enjoy!
- What we learned from scanning 10K+ Kubernetes clusters - ARMO CEO Shauli Rozen shares key insights from the Kubescape database including the most common K8s security challenges and how to approach them.
- What you want is Continuous Feedback - OpenTelemetry from code to prod - Digma founder and CTO Roni Dover makes the case for Continuous Feedback (with OpenTelemetry) as the go-to solution for companies to make Observability matter.
- Kubernetes Antipatterns: CPU Limits - Robusta Dev CEO Natan Yellin will explain how they work and go over best practices for using them.
All the best,
Kaspar
