Currently, Antifragility and Microservices are trending topics and this might be a hint that there are new architectural paradigms or design patterns on their way for building application systems. InfoQ discussed these new concepts with Russ Miles to find out what they are good for and how to apply them in an architect's or developer's daily business - for existing applications and those to come
InfoQ: In the recent months, Antifragility and Microservices became trending topics. It seems there might be new architectural paradigms on the horizon. Could you please tell us a little bit about Antifragility? At a first glance, it seems to be the same as robustness …
Russ: Antifragile was a term coined by Nassim Nicholas Taleb in his book of the same name. This fantastic book explores antifragility as the opposite of fragility, rather than robust.
My main takeaway from Taleb’s position in his book is that systems that are fragile will typically collapse in the face of stressors (change being one big group of stressors, especially on software). Robust systems at best ignore stressors, and at worst resist them. Antifragile systems not only embrace the stressors on them, but in fact improve and thrive in the face of those stressors.
Applying this thinking to software is an interesting challenge, as one of the main tenets of Taleb’s thought is that it is organic systems that exude the clearest examples of antifragility. One analogy is to think of a muscle that, when placed under periodic stress say from lifting weights, will react by eventually being stronger. The muscle system has improved in the face of manageable stress. Of course there is a limit to the stress that the muscle can take, but that is true of any system.
So in fact what antifragile software is all about is attempting to bring these same organic qualities to software, and there is a fair amount of debate in the international software development community on how this could be achieved.
My take is that microservices-based architectures can provide an architectural and design approach that supports building software systems that exude these antifragile properties. That’s not to say that microservices necessarily must achieve these properties, but if the right non-functional constraints are considered and microservices are built to be single-purpose services that do not share state and that typically have uniform interfaces (such as REST), then the potential is there to build software that thrives and improves on stressors such as change.
Antifragility is an entirely new system of thinking when it comes to software. In many respects we’ve been aiming for the Platonic ideal of perfect, robust systems in the past, and this has led to systems that are only as robust as their weakest element. This has also led to software systems that ignore or resist change, which often ends up finding itself diametrically opposed to the realities of embracing change in agile software development processes and practices.
Agile software will most likely be antifragile software; software systems that can adapt and thrive under the stress of change as well as your agile processes and businesses can. This is the potential promise and it is my job to turn this into reality. First step is to help software developers pragmatically understand how to apply antifragility as a value in their software systems, and that’s what I’m looking to do with the launch of the London Microservices User Group, my talks and tutorials this year at GOTO Amsterdam, Copenhagen and Aarhus, and of course my book and courses.
The danger is that Antifragile Software, and in particular microservices, will become another excuse to waste money on fanciful consultant-driven ivory-tower architecture. My aim is to avoid that by making things as real as possible while making sure as many people as possible understand the value we’re supposed to be getting out of these principles and architecture and design approaches.
InfoQ: When put under pressure, as I understand it antifragile software can be made up of fragile components/services. From a software-designers point of view - what does this mean?
Russ: By allowing the ongoing sacrifice of those fragile components in the face of stress, you allow the system as a whole to expect them, and give it a mechanism to adapt to those stresses through the process of replacing the sacrificed components.
For example, this is the very process that Netflix applies with it's Chaos Simian family. In this scenario, you are constantly destroying infrastructure and creating an expectation of failure and an emphasis on constant re-creation. If the re-creation process can go beyond simply rebuilding what was there before, you have an antifragile system. If it simply goes up to the previous line, you have a resilient system.
Fundamentally the main focus will be for the designer on architecting and designing a system that can embrace stressors. This can be achieved within a monolithic application and my Life Preserver design tool helps with achieving this. However the real potential is best realised when you break apart the monolith into discrete services, an optional step facilitated by the Life Preserver, as at that point you can begin to incorporate the antifragile characteristics to those discrete services and the interactions between them.
At that point microservices can be built to almost function as autonomous cells, and the organic analogy begins to make more sense. At this point various failover and lifecycle strategies can be applied, such as the circuit breaker pattern, to your services in order to make them as fragile or robust as they need to be to support the desirable overall antifragility of the system.
One interesting secondary-effect of microservices is that they fly in the face of the dictate that you should ‘postpone technical decisions until as late as possible’. If you’re dealing with one, small single-purpose service then in fact you can consider technology (language, framework) as early as you like, as it will likely very much inform the simplicity of the design and implementation approach of your service.
Postponement of these choices through abstraction was a good idea when everything would need to change based on the decision. Microservices not only allow you to select implementations that are unique to the service, but also support the idea I call the ‘lunchtime spike’, where often a complete service can be reimplemented using a different technology to demonstrate that it has been made simpler in the course of a lunchtime. When changing your mind is that low-friction an exercise, the possibilities of applying the right technologies to the distinct single-purposes of your services becomes more than a pipe-dream. This is exactly what I had in mind when I gave my talk at GOTO Amsterdam last year.
InfoQ: How can Microservices contribute to the design of antifragile software?
Russ: Simply put, microservices are an architectural and design approach that enables the possibility of building software systems that exude antifragile properties.
InfoQ: We've heard one question very often in the last years: How big is a service? And actually there are a number of really could answers to this. What about microservices? Could you give some hints on the size of a micro service?
Russ: Size doesn’t really matter; no really! I’ve seen comments along the lines of “less than 100 lines of code!”. To be honest, I think that’s a really stupid measure. LOC was never a good metric for anything so why would it be now? I’m hoping the 100-LOC comments are made with tongue firmly in cheek.
What’s important is that a micro service should have a single purpose and that in the construction of a microservices based system uniformity of the interfaces is important, and deploying services such that they can failover and meet the properties of antifragility is even more important.
InfoQ: We think that microservices will lead to much more loosely coupled systems than those we built in the recent years. Are there any technologies, platforms or frameworks that seem to support the idea of microservices very well?
Russ: I couldn’t agree more. Depending on whether you’re building monolithic software systems that will do their best to have antifragile properties internally, or deploying single-purpose, loosely-coupled services will inform your choices on technologies, platforms and frameworks.
In terms of internal design, the event-driven reactive approach to building services makes a lot of sense to me. Tools and frameworks that support this mode of operation, such as Akka or even to a certain degree frameworks such as Apache Camel and Spring Integration, have something to offer here.
The main challenges come in the build, deployment and runtime management and monitoring of microservices. Things could be a lot easier here.
First let’s take a look at microservices in terms of management and monitoring at runtime. For me, trying to treat microservices like we treated our precious monolithic applications is totally the wrong way round. Instead I treat my microservices like cattle, rather than pets is the analogy, and let them die and re-spawn as needed. The more autonomous microservices are, the less management and monitoring they need. Instead of producing a collection of needy and noisy microservices, my design approach is generally to ensure that my microservices can take care of themselves with the majority of stressors and that they send me actionable information rather than heartbeat monitoring messages. This is how I can manage to create systems out of 1000s of microservices, because they’re not all screaming at me “we’re fine!”.
Some believe that microservices-based deployments increase the dependency on specialised tools and skills, as per the excellent article written by Benjamin Wootton that is concerned with showing that while microservices is a good idea, it’s no free lunch. I would agree that today this is the case, but I would also point out that there is a space for something that allows you to build antifragile microservices without the increased onerous dependency on specialised skills and increased management overhead.
And that’s really the challenge right now; there is no simple and easy solution out there that actually gets antifragility and allows people to develop and deploy microservices as easily as they should be able to. At the moment, I think there’s some disagreement that this is even needed. However there are lots of smart people out there looking into this, and I’ve been really excited to see some of the developments coming down the pipeline, but at the moment unfortunately Benjamin's statements are quite correct. However I would say that whether it’s a free lunch or not, the effort is worth it.
InfoQ: As software becomes more flexible and adaptive by applying antifragility and microservices, will it also become more agile? Now that teams learned to "embrace change" for maybe 10 years, is it now our software that will learn to do the same, so we can leverage agile methodologies even more?
Russ: If we remove the buzz-word laden landscape of Agile it can be distilled into processes, practices, tools and techniques that help businesses embrace change. In this respect, antifragility has a lot to bring to all levels of 'agile' development.
With microservices we’re clearly focussed on getting the benefits of antifragility at the level of the system and its technical implementation so that it doesn’t fight the agility and adaption that we’re trying to embrace in our ways of working.
InfoQ: Simplicity is another way to raise efficiency maintainability in software development - does it also fit in the antifragility and microservices world?
Russ: Absolutely. Each microservice will be simple as it will be single-purpose, avoiding system-level entanglement between concerns. This also extends of course into the implementation of a service too, where simplicity and avoiding entanglement of concerns is more commonly applied to writing simple code (something I call ‘cartoon code’, I want your code to be as easy to read as, say, Calvin and Hobbes, but with a little less laughing).
InfoQ: Are there any ideas how to transform legacy architectures into antifragile architectures? Do we have a big bang transformation or is it possible to apply antifragility step-by-step?
Russ: Green or brown-field, the approach is remarkably similar. Designing or re-designing a system towards antifragile microservices is exactly what the Life Preserver tool is designed to do.
The Life Preserver is just a thinking tool that asks the right questions to drive the separation of concerns and the grouping together of parts of your system that change together.
I invented the Life Preserver because I was very frustrated with existing architecture and design techniques, especially diagrammatic approaches, that never seemed to consider evolutionary change of the system at all. A great diagrammatic tool should answer important questions, and ask some too. Most diagrams produced in the name of software architecture do neither.
InfoQ: Suppose I'm an old-school architect / designer - how hard will it be for me to shift paradigms? In what way should I look at software design to come up to speed? How can I get familiar with antifragility, microservices and simplicity as fast as possible?
Russ: Well of course there’s starting with the “Antifragile" book by Nassim Nicholas Taleb to start your journey to understanding why antifragility is important in the first place. Then I’d take a look at how companies who are taking advantage of antifragility are building and working their software systems, a key example here is Netflix and the great work that Adrian Cockroft did while he was there and that his team are continuing to take advantage of.
When it comes to applying antifragility to your own systems it is a bit of a shameless plug but that’s where my book “Antifragile Software: Building Adaptable Software with Microservices”, and even my courses in London and the tutorials I’ll be doing at various conferences over the coming year come in. If you are in London then there’s also the free meet up group that you can join, and I’m also planning to run the first ever microservices-dedicated conference in London in November, called µCon, where we have a really stellar collection of speakers starting to build up for this two-track, two-day conference.
Microservices are a hot topic, and I think antifragility gives us the foundation as to why. Hopefully there’ll be enough interest in things for us to take activities such as µCon on the road to other parts of the world as well. It’s definitely a space worth watching and I’ll be doing my best to keep everyone abreast of things on my blog as things progress over the next 10 or so years. It’s going to be an interesting ride!
About the Interviewee
Russ Miles is Chief Scientist at Simplicity Itself. As well as being the author of “Head First Software Development” and more recently the LeanPub book “Antifragile Software: Building Adaptable Software with Microservices”, Russ also consults, conducts courses and speaks internationally on the subject of building software that is simple and thrives on change.
