A Cloud Native Programming Manifesto
Tags: agile, architecture, cloud, kubernetes
Published: 2019-08-05 10:34:55

**Update:** Created [a Github Repo](https://github.com/julz/cloud-native-programming) 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](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

1. _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.
1. _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)
1. _Routing_ over deployment - rather than managing multiple environments, where possible we prefer progressive deployment, observability and feature flags
1. _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