The Microservices ManifestNO,
Dutch Edition
Like all good and simple technical phrases, there’s always room for misinterpretation and confusion (that luckily leads to large bonuses for consultants and large support contracts for vendors, not to mention the lucrative possibility of certification!). So following in the well-trodden and money-paved path of our elders in the Reactive and Agile movements, we’ve decided that we’d like to start a pyramid scheme of our own around … #microservices.
After at least 20 minutes of vague scanning of the web and caffeine-driven discussion, we’ve come up with the following ‘clear’ key principles for the “Microservices Manifesto(TM)” (helpfully collated from too many sources to attribute/blame directly).
The undersigned illumaniti state that Microservices value:
• Being antifragile.
• Being darwinian in nature.
• Being exactly 100 lines long.
• Be in its own process.
• Using lightweight mechanisms to work with other microservices.
• Being independent.
• Do one thing, and do it well (as opposed to not doing it well…)
• Being independently deployable
• Being small and self-contained
• Being consumer-driven contacts
• Being clearly bounded
• Being discrete (and discreet?)
• Have “just enough” validation
• Being one business capacility
• Being isolated, and separate from other things
• Being named
• Being a sub-process
• Being able to scale well
• Being small
• Being small enough to throw away
• Have no shared DTOs
• Use REST at all times
• Use the right protocol for the context
• Being organic
• Being hot and new, and confusing
• Embrace fall-back
• Being self-healing
• Being about components
• Being the smallest level of abstraction possible, but no smaller
• Being resilient
• Being decentralised
• Being antifragile.
• Being darwinian in nature.
• Being exactly 100 lines long.
• Be in its own process.
• Using lightweight mechanisms to work with other microservices.
• Being independent.
• Do one thing, and do it well (as opposed to not doing it well…)
• Being independently deployable
• Being small and self-contained
• Being consumer-driven contacts
• Being clearly bounded
• Being discrete (and discreet?)
• Have “just enough” validation
• Being one business capacility
• Being isolated, and separate from other things
• Being named
• Being a sub-process
• Being able to scale well
• Being small
• Being small enough to throw away
• Have no shared DTOs
• Use REST at all times
• Use the right protocol for the context
• Being organic
• Being hot and new, and confusing
• Embrace fall-back
• Being self-healing
• Being about components
• Being the smallest level of abstraction possible, but no smaller
• Being resilient
• Being decentralised
To ensure that things look more established and solid than they are, we then completed the following signed version of this manifesto so that we could be the only people that signed it for prosperity (our prosperity to be clear).
Like all good manifestos, if you’re not doing the above you’re not doing microservices. It is our hope that this definition will cause widespread and wasteful intellectual war over a term that was simple and useful in the first place. After all, how else are we all going to make some money!?
Introducing the Microservice Alliance & Certified Microservice Architect(TM) Master
In addition we’d like to announce the formation of the Microservice Alliance and Certified Microservice Architect Master(TM) training programme.
Due to demand this certification is only available for those willing to swap pre-paid tickets for Virgin Galactic’s early flights, but we think you’ll agree that the rarified air of being able to describe yourself as a certified Microservices Architect will more than make up for that pesky trip-of-a-lifetime into space.
Explaining Our Logo
All impenetrable and confusing manifestos and technologies require a cute logo to pretend that the the approach or technology is actually friendly and approachable. Ours is no exception. After several rounds of voting the blessed signatories of our manifesto here in Holland have selected the current logo that can be found at the beginning of this manifesto.
For those not sure what it is, we were going for an emphasis on ‘micro’, and so selected a cuddly-toy version of the Chlamydia virus. Other options were considered, most notably MRSA shown below:
The advantage of these logos is that they are already marketable commodities available on Amazon here, and here.
We believe our choice of logo accurately reflects our hope that our manifesto will spread like a virus and confuse the world in its erroneous understanding of what the one, true microservice manifesto should be.
Footnote...
Just in case it’s not entirely obvious … this was just for fun! To point out the conflicting views and confusion around microservices.
Today my attendees on the #antifragilesoftware course, the ’signatories’ above, have been creating microservices in order to construct systems that thrive on change and encourage de-centralised innovation, and creating this manifesto was some fun at the beginning of the day to highlight just how varied definitions are, and how we can ignore them when we look just for the benefits (which are the #antifragile qualities of a software system).
To be clear, I am philosophically opposed to ossifying manifestos, but that’s a subject for another blog post…
RSS Feed
