Lots of you reached out after my last mail, thanks :) Hopefully, this one will be interesting too. To recap, in my last email I highlighted a possible scenario you might be confronted with if you go cloud-native and you don’t watch out for common traps. In this mail, I want to share a few practices that I observe other teams use to mitigate such potential downsides.
So here we go, this is what I propose you at least consider when or while you’re “going cloud-native”:
- Come to an agreement around 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. - 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 the 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. - 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. - 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. - 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.
Hope this helps - if you disagree, reach out if you want to chat about this too!
Also: +++ I will be at KubeCon in Valencia in May and I’d love to meet you in person +++. If you are around, reach out!
Cheers,
Kaspar
