Hi everyone!

Today I’ve got two things to announce! First up, copies of my book “Antifragile Software: Building Adaptable Software with Microservices” has been reduced to a minimum price of $10, in-line with the current amount of the book that’s been written.

I’d like to say a huge thanks to everyone for buying this book! At these early stages your purchases don’t just help fund the writing of the book, they also show a real belief in the value of what the book might convey once it’s written. That’s a level of faith in me as the author that is truly humbling, and I’m very grateful. 

However, in terms of pricing I think I initially made a mistake and so have changed things up a bit. 

One thing that I’ve struggled a little with myself is charging full face value for a book that is under development. The wonderful Ralf Westphal has pointed out, quite rightly, that this can be a cause for concern for those that want to buy the book and feel that full-price for a book that’s not more than a third finished just yet is a risk too far. I’m inclined to agree, but seeing as already over 100 books had been sold at various prices I couldn’t see a way of easily rectifying the problem.

At the same time, I’ve been getting prepared to donate 20% of net book income to charity. The charity I’ve selected is YoungMinds.org.uk. This is a charity dedicated to improving the mental health and wellbeing of today’s youth, a subject very much close to my heart.

Ralf pointed out that there might be a solution to the pricing problem in the association with this charity, and so here’s what I’m proposing to do along the lines of his original idea.

So I’ve lowered the price of the book inline with the amount completed with the opportunity of course for folks to up the amount they pay if they think it is worth more. 

At the same time for those that have already bought the book I’m going to calculate the paid money difference from $10 to what they paid and then donate that to  YoungMinds.org.uk, announcing the total on the homepage. Going forward 20% of the net income will be donated to the charity, and I’ll keep a running tally on the book’s homepage.

Finally I’m going to gradually increase the price of the book as it is completed, likely in $5 steps, increasing the amount being donated to the charity as the book is completed. 

I hope everyone agrees this is a good way forward. I’m really stoked to be helping a great charity, and at the same time asking a fair price for the book as I’m writing it.

Thanks so much for everyone’s faith in this book so far and I am looking forward to turning that faith into a great book on software development as I continue to write it over the summer.

Cheers!
Russ
(from Heathrow Terminal 1, bound to Ace! Conference in Poland) 

Recently I was interviewed by Ralph Winzinger of InfoQ on the subject of building antifragile software with microservices, the main aim of the interview being to demystify these two concepts as much as possible.

During the interview I covered the following:

• Putting antifragility in the context of software systems.
• How antifragile systems can be constructed from a variety of components/services that may be fragile/robust in nature.
• The relationship between microservices and antifragility.
• Why size of a microservice is not the important thing.
• Technologies, tools and platforms that support microservices well, and those that go further to encompass antifragility.
• The relationship between antifragility and building software that adapts and is therefore agile.
• How simplicity is a key principle of a microservices architecture.
• Approaches to transforming legacy, possibly monolithic, systems towards microservices and antifragility.

The full interview has now been published on InfoQ.

I'm very pleased to announce that the second meet up event of the London Microservices User Group has been announced!

Provisionally titled "Clustering Considered Harmful: Simplifying your System with Microservices", this second free event will feature David Dawson, Principal Consultant at Simplicity Itself, sharing his experience of building microservice-based systems on the foundations of immutability to remove the immediate need for the complexity and false robustness of clustering.

After the huge success of the first meet up, sign-up now for this event to avoid the waiting list!

There are going to be code samples to accompany the "Antifragile Software: Building Adaptable Software with Microservices" book, LOTS of code samples (especially accompanying Book 3!). To organise the code and make it freely available I've created a new one-stop Antifragile Software GitHub organisation that will house each of the repos of code associates with the book.

Right now, it's empty but it's worth a watch as code will be appearing there soon.

The aim is to license the code using the Apache Software Licence as the code is added so that everyone can use it with as little restrictions as possible. After all, this is learning material!

In addition, the hope is that others might extend the ideas into new implementations and repositories of their own, and perhaps ask for those repos to be formally associated with this GitHub org. As long as the licenses are open then I'd be very keen to hear in time from others who would like to contribute their own samples to this reference organisation.

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!

The "Building Microservices with Antifragility" public course is now scheduled this year in London at Skills Matter. Dates currently available are:

• Monday 19th to Wednesday 21st May, 2014
• Wednesday 13th to Friday 15th August, 2014

The course covers:

Day 1 - Architecture & Design for Simplicity and Antifragility:

• Introducing Antifragile Software and Simplicity
• Defining Microservices in term of their Principles, Benefits and Challenges
• Understand and explore the forces (stressors) of change on software
• Applying Simplicity, with O.R.E.
• Architecting and Designing for Software System Evolution with the Life Preserver tool
• Organising for concerns and simple components
• How to collaborate to discover change stressors on your software system
• Organising components for change

Day 2 - Implementing Antifragile Software with Simple Components, Events & Microservices:

• Exploring and Managing change-stressor fault-lines between areas of your system
• Designing software bridges that handle change across fault-lines
• Applying de-coupling intelligently, balancing flexility and complexity
• Applying Request-Response, Messaging and Events
• Designing when to apply and implement Postel’s Law

Day 3 - Deploying, Running, Testing & Managing Antifragile Software with Microservices:

• Extracting components into Microservices
• Building, Deploying and Managing Effective Unix-style Microservice Pipelines
• Simplifying Microservice Management using Immutable Service Deployments
• Designing and Implementing Reactive Microservices
• Applying effective health and monitoring for microservices
• Designing and Implementing Microservice Failover and Auto-Recovery Strategies using the Circuit Breaker Pattern and Friends
• Designing and Implementing for Autonomy with Microservice ‘Cells'
• Enabling Governance and Innovation with Microservices
• Enabling Variation and Experimentation in Languages and Frameworks through Microservices
• Testing stressors for failure to avoid failure
• Testing and Continuous Delivery for Microservices

I hope you can make it!

I've started a new meet up group in London especially for those interested in getting the real advantages of microservices and sharing their experiences on the way.

To get the ball rolling I'm going to be kicking off the user group with an inaugural meet up at Skills Matter on Thursday 12th June, 2014. The title of the talk is "Separating Fact from Fiction: What do Microservices really look like?" and it's going to be a real show-and-tell on the challenges of building a microservices-based system.

I hope you can join me for this event!

Additional Announcement! We'll be raffling a ticket to µCon: The Microservices Conference at the meet up as well! Current list price for the ticket is £200 on an early-bird discount, but will be going up to ∞500 nearer the event so this is a pretty good raffle prize!

Additional, Additional Announcement! As well as the above talk by Russ Miles, Gawain Hammond will also give a talk on innovation in relation to his experiences at Sky:

"The origin of species: evolution and innovation"

In this talk, Gawain Hammond will explain why your toe cheese is more innovative than you, what can make you better at innovation, and how to help your organisation to reap the benefits. We have a lot to learn from bacteria, they have survived for millions of years, far longer than your company. But what characteristics ensure success? And how can microservices help us emulate their success against all the odds?

Additional, Additional, Additional Announcement! I (Russ) will be giving away three free copies of my book, "Building Antifragile Software with Microservices" to the three best questions on microservices asked through Twitter prior to this event.

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!

The first step to building antifragile software is often to 'break apart the monolith’. A monolithic piece of software constrains your choice of technologies, languages and speed of change to the lowest common denominator, and also represents a system to make robust (at best) or to accept is fragile (at worst).

Antifragile software systems aim to thrive on change, and any such system if it is robust or fragile in its entirely will resist or fear change respectively. Therefore the monolith is often identified as the main problem.

But how to go breaking apart the monolith? This is why I invented the simple Life Preserver design tool that I’ve now used successfully with hundreds of clients across dozens of domains. A couple of examples of the Life Preserver in action are used by the new Spring.io site and linked to below:

• Designing and Implementing RESTful Web Services with Spring
  
• Data Access with Spring
  
• Designing and Implementing a Web Application with Spring

In a nutshell, the Life Preserver tool looks to answer the following questions:

• Where does my component go? - The Life Preserver tool helps you group together components into areas where they evolve at the same rate as other components.
• What should my component do? - Components can be analysed and migrated towards single-purpose and ensure that they do no accidentally cross-boundaries between evolutionary rates of areas of your application.
• What should be the coupling between my components/areas of my architecture? - Various components and techniques can be assessed for the level of de-coupling they provide between evolutionary areas of your application, allowing you to choose the right level of complexity of approach for the right level of de-coupling. This is the jumping off point to begin to break out some of those single-purpose components as services in their own right, as and when the advantages of microservices become attractive.

Simple to use but sometimes tricky in nuance, my book “Antifragile Software” goes into more detail on how to use the Life Preserver (or at least it will by the end of this week!) with the aim to prepare your architecture to gain the advantages in the right places of separating out antifragile, reactive microservices.