In my two last blog posts I shared my thoughts on what I believe your cloud native journey shouldn’t look like.
I suggest you check them out but to recap, we see so many teams completely screwing up their migration to the cloud. Mainly because they don’t set the right expectations and, when they realize they need to build some sort of platform layer to make their setup easier to consume, they end up screwing that up too.
Building an Internal Developer Platform can bring about a lot of challenges: hiring the right team, introducing a product mindset, having a solid feedback loop between platform team and developers, rollout, etc. Here I summarized the top 10 fallacies in platform engineering.
In this blog post, I want to focus on the 5 principles to consider when going cloud native.
#1 Embrace the value of standardization
 Before you do anything, before you build any path-dependency, assemble your wider team, sit in a circle, hold your hands, deeply look each other in the eyes and have a conversation about standardization. Standardization is your friend, it doesn’t have to restrict anybody. I do not mean overdoing it, you can do lots of harm with that too. I’m saying keep a balance. Good standardization means choosing the same tech for team 1 that you already chose in team 2 if the application architecture isn’t making it absolutely necessary to do differently. Team 1 uses GKE? DO NOT use EKS in team 2. Team 1 uses Kubernetes? DO NOT introduce serverless unless there is a miraculous event-driven reason. Cost savings are not an argument. The discussion about the yes/no of this tech already outweighs the cost benefit. A high degree of standardization helps you in training your teams, building better docs, optimizing your toolchain and lots of other good stuff. Have this conversation before you start building. Anchor this so that the next person joining doesn’t even come up with the idea to introduce the tenth IaC framework.
#2 Abstract without abstracting
Don’t fall for the fallacy of trying to make everybody an expert. We published our Kubernetes Benchmarking Study earlier this year, the data is pretty clear. In high performing teams there are few high profile experts on K8s and there is a high level of abstraction to keep cognitive load low for everyone else. I can already hear some of you screaming “you shouldn’t abstract”. It depends, is the honest answer. Abstraction can have a great impact, as long as you do not remove the context. Good abstraction can be a CLI command that gives you an S3 bucket but also points you at the Terraform code so you know exactly what happens. I am not advocating for ClickOps or fancy UIs, that sucks. But I’m advocating for respecting the cognitive load of your team. Not everybody needs to do everything.
#3 Build a platform, treat it as a product
Not super surprising coming from me but I mean it. Think about platform engineering. It’s about standardization by design, it's about abstraction without abstracting and it lets you build golden paths. Before you start, at least think about the perfect experience that you envision. Your golden path. Maybe people deviate but if you don’t even try you leave them in nirvana. And nirvana leads to disaster.
#4 Start by building something small that doesn’t suck
Start small. Take one team with motivated devs and their apps. Build a golden path that they genuinely love. Spend too much time on this. Paul Graham used to say: do small things that do not scale. That’s exactly what you want to do as well. Once you’ve figured out how it works at a small scale, use this initial team to rally about how great this new world is. Lots of endeavors fail because the new cloud native setup ends up delivering the same value as the old one, but rougher on the edges. If you’re asking people to change, it needs to make sense.
#5 Beware of the tragedy of the commons
 Running a sane engineering organization often requires balancing the interest of the individual against the needs of the group. The individual really wants to code in “Go” now because Martin Fowler said it’s cool. The group is already struggling to support the test-coverage on Python and you add even more on top. Good leadership isn’t autocracy. It’s about explaining to the individual and serving them while firmly standing for what’s good for the org.
Curious to hear what people’s opinion on this is. I will host a webinar on June 1st on the topic, where I’ll present a step by step guide on how to platform your delivery setup. I’d love for you to join the event and Q&A.
Also, we’ll have great speakers covering this topic at PlatformCon this year, on June 9th and 10th. Here are some of them:
Manuel Pais: Platform as a Product
Colin Humphreys: Platform engineering: 20 years of getting it wrong
Aaron Erickson: Why you need a Product Manager for your Internal Developer Platform implementation
‍
