A Cloud Native Programming Manifesto

We need a manifesto for Cloud Native Programming that focuses on shipping software, not managing infrastructure

Julian Friedman
Aug 5, 2019 · 2 min read

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 better. 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 could 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.
  2. 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)
  3. Routing over deployment — rather than managing multiple environments, where possible we prefer progressive deployment, observability and feature flags
  4. 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

— —

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:

Julian Friedman

Written by

IBMer & PM of Cloud Foundry’s Container Engine “Garden” & “Eirini” CF/Kubernetes Integration project. Fan of PaaSes. (Words and thoughts his own, only his own)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade