Update: Created a Github Repo where we can gather resources and links etc.
Update 2: Quite a lot of feedback about the second bullet. I think it may treat a symptom rather than the problem. Discussion here:
https://github.com/julz/cloud-native-programming/issues/3
The way we write Cloud Native Software is wrong. Or at least, over-complicated. Or at least, we can do better.
Many of us are spending far too much time talking about infrastructure details. About CRDs and yml and template languages and ReplicaSets and service meshes. These things are great, but they're tools. And, let's be honest: they're over-complicated tools an awful lot of the time.
Wasn't Cloud supposed to make things better? Easier, faster, simpler? Does anyone else miss Heroku and 12-factor apps?
How have we gone forward five years and made it harder to ship software?
Why the Agile Manifesto succeeded
The Agile manifesto was originally quite controversial. It argued against the received wisdom that because some projects need a large amounts of up-front planning, design, contract negotiation and rigorous processes all projects should use those techniques. And actually, many didn't need to.
The Agile Manifesto has a great way of framing this: it's not that Big Up Front Design (for example) is "wrong", it's that Responding to Change is more important. This way of thinking clarifies the trade-offs.
If you need contracts, or a lot of planning, or comprehensive documentation, or lots of process - the agile manifesto says - that's fine: but prefer individuals and interactions, responding to change, and shipping working software, where you can.
If you need YML and ReplicaSets and Pods and Nodes that's fine (especially when it supports the goals of shipping and iterating faster and easier!): but prefer consuming higher level abstractions and favouring simplicity where possible.
A Cloud Native Programming Manifesto
The function of the Cloud is to make it substantially faster to ship and iterate on distributed software. Many of the hottest ideas in Cloud are absolutely necessary for extremely large scale systems, but have trade-offs when applied to systems that don't need them.
I propose building a Cloud Native Programming manifesto to clarify best practices and thoughts around these trade-offs. It might look something like this:
Four Values
- Consistency over configuration - that is, where possible we prefer to focus on code, not CRDs or yml or ReplicaSets or helm charts or Dockerfiles. 12-factor apps and serverless functions can help with this.
- Monoliths over micro-services - that is, where possible we resist breaking down a system in to more micro-services than required (generally, a service per team is a good rule-of-thumb)
- Routing over deployment - rather than managing multiple environments, where possible we prefer progressive deployment, observability and feature flags
- Services over managing state - that is, we prefer to use existing services at the highest level of abstraction possible rather than managing databases and complex systems
Top comments (2)
There are two parts of the world as I see it. There is "cloud native" movement fueled by CNCF and and locked in mentally into Kubernetes and microservices. There is another world of "serverless" and using backend as a service as much as possible. One world is fueled from behind by big G and traditional on-prem players who want the broad audience to adopt K8S. Second world is fueled by big A, which wants people lock in their cloud platform. Where have we lost as engineers joy from building stuff driven by sane choices not agendas of hyperscale companies?
PS: I love both worlds as engineer and on daily basis my teams build things in both of them.
Nice to see you here, @doctor_julz !