The latest articles on DEV Community by Julian Friedman (@doctor_julz). https://dev.to/doctor_julz https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F174028%2F45810a80-bff7-4e6d-8578-e67f03ab9017.jpg https://dev.to/doctor_julz en Julian Friedman Mon, 05 Aug 2019 10:34:55 +0000 https://dev.to/doctor_julz/a-cloud-native-programming-manifesto-41o https://dev.to/doctor_julz/a-cloud-native-programming-manifesto-41o <p><strong>Update:</strong> Created <a href="https://github.com/julz/cloud-native-programming">a Github Repo</a> where we can gather resources and links etc.</p> <p><strong>Update 2:</strong> Quite a lot of feedback about the second bullet. I think it may treat a symptom rather than the problem. Discussion here: <br> <a href="https://github.com/julz/cloud-native-programming/issues/3">https://github.com/julz/cloud-native-programming/issues/3</a></p> <p>The way we write Cloud Native Software is wrong. Or at least, over-complicated. Or at least, we can do better.</p> <p>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.</p> <p>Wasn't Cloud supposed to make things better? Easier, faster, simpler? Does anyone else miss Heroku and 12-factor apps?</p> <p>How have we gone forward five years and made it <em>harder</em> to ship software?</p> <h2> Why the Agile Manifesto succeeded </h2> <p>The Agile manifesto was originally quite controversial. It argued against the received wisdom that because <em>some</em> projects need a large amounts of up-front planning, design, contract negotiation and rigorous processes <em>all</em> projects should use those techniques. And actually, many didn't need to.</p> <p>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.</p> <p>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. </p> <p>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.</p> <h2> A Cloud Native Programming Manifesto </h2> <p>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.</p> <p>I propose building a Cloud Native Programming manifesto to clarify best practices and thoughts around these trade-offs. It might look something like this:</p> <h3> Four Values </h3> <ol> <li> <em>Consistency</em> 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.</li> <li> <em>Monoliths</em> 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)</li> <li> <em>Routing</em> over deployment - rather than managing multiple environments, where possible we prefer progressive deployment, observability and feature flags</li> <li> <em>Services</em> 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</li> </ol> agile architecture cloud kubernetes