I've just published a new version of "Antifragile Software: Building Adaptable Software with Microservices". This book is incredibly close to my heart as it is beginning to capture not only how I build software systems but also how I approach the thinking process of architecture and design; this book is going to go philosophical as well as practical and I'm proud of that! 

That said, the book has been through quite a journey but the mission for the book (and it's sub-books) is now clear and so a huge thanks is in order to those that are early-adopters! The book is really beginning now to take shape not least in response to my work with Skills Matter on the first Microservice conference, µCon, and the announcement of my public courses that accompany this book too.

As such expect to see a lot more activity on the book than there has been in recent months (I apologies for that!). The ideas are now in place, the table of contents and flow I believe is a final one and I'm off and running with the writing.

Hopefully going forward the only thing I'll need to apologise for is the fact that readers are being asked to update their copy of the book too frequently!

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

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!?

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.

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.

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…

At QCon London this year there was one tweet that really stood out for me. The tweet went "QCon London: Microservices, microservices, blah, blah, microservices". It was a fair summary.

The interesting thing is that I've been harking on about using simple, single-purpose components in order to enable the properties of antifragility in software now for a couple of years. I'm just about to launch a course on the subject, and what excited me was that in fact what was being branded as microservices at that point was what I was simply referring to 'adaptable components'. So, for me, microservices works.

After just about every conversation I had after QCon being dominated by the subject I felt, and so did Skills Matter, that it was time to take things to the next level and so µCon (pronounced, and hash tagged, as 'muCon') was born.

But why do we need this conference? Here are my reasons.

Any company that can innovate rapidly and successfully has a competitive advantage in modern times. Just take a look at Netflix, a relative newcomer who is generally scaring the proverbials out of the resident incumbents.

Netflix, and other innovative companies, is not just down to processes and practices, it's down to philosophy. Netflix designed and architected for unpredictability from the word go, both in terms of requirements and runtime conditions. They coined the term 'cloud native' for this style of architecture, and it is made up of another term they adopted 'microservices'. I think these terms are a little too implementation specific, what they are in fact achieving is antifragility in that they have designed and architected to thrive on change in requirements as well as to thrive in the face of runtime instability.

Netflix have designed microservices so that their system is antifragile, while accepting that some services can be fragile, some may be robust. Antifragility is a property of the system itself, and microservices have as an underlying implementation choice been the natural destination to achieve this valuable antifragile property.

If your software system can thrive on change both at design and runtime, this means it can adapt as fast as your agile company might need it to. This is the most exciting thing that microservices underpin, the fact that you might be able to innovate as fast as you can. 

We've spent over 10 years now becoming agile in our processes and practices, even our organisations, but our software architecture and design has had difficulty keeping up. 

It's not just about comprehension and clean code, the software itself needs to be designed with change in mind. This is where simple, single-purpose services that do one thing well and are able to live and failover and deal with transient environmental conditions successfully are so important. It's no surprise that these are the natural properties of a system that is labelled as following a micro service architecture.

So why a conference? Well, the fact is that with any new set of priorities, principles and approaches that hit software development, there is a lot of confusion out there.

You can see this confusion in ongoing discussions around "What is a microservice?", or even "Isn't a microservice architecture just SOA?". These are important discussions, but they tend to cloud the real underlying properties that are being sought, those that I'm characterising as innovation enabled by antifragility.

So this conference intends to set the record straight. To share real-world experiences of building microservices architected systems and how they enabled the benefits, such as antifragility, that they were aiming for. We're going to discuss values, principles, architecture, design and real implementation techniques. This won't be for the faint-hearted, but it will be a heck of a lot of fun!

So if you're interested in building software that can adapt as fast as you and your business can, then this could well be the one conference you need to be at this year. If that hasn't sold you on the conference, then the forthcoming speaker announcements surely will do, and let's not forget the obligatory evening-keynote and launch party on the first night.

Microservices holds a lot of promise, and so I hope to see you there at µCon in November. 

It's going to be an amazing learning experience and a lot of seriously technical fun, and right now it only costs £200 for two-days as well, so get in early while the earlybird discount is still available!

I was recently asked by Annapurna IT (one of the nicest recruitment companies I've ever encountered) to record a short interview for their Technology Transformation Network and its accompanying online TV channel on enabling innovation in large companies.

In this interview I talk about the major challenges to innovation in established businesses, and how this can be overcome with a fairly simple process that buys the companies options on how they then want to deal with the resulting innovation. It's these options that reduce the risk of enabling innovation through emerging technologies.

A followup event is being planned, watch this space for details.