We have been building monoliths, big pieces of software, we then moved to SOA but we still had problems, now we are moving to microservices, Russ Miles recently described current state of software development in an introduction to designing and building antifragile microservices, using Java as a platform.
Russ compares with boulders, rocks and pebbles where monoliths are like boulders, very hard to change or move. SOA are like rocks, still hard to shift and not really giving the payback we expected. Microservices are like pebbles, very easy to shift around.
Antifragility for Russ means we embrace that system will break; we need to not just embrace change but thrive on it, so that we get better. The starting point to achieve this is for Russ simplicity, with lots of small things that do one job, having one single purpose. Designing for simple components and systems is key when moving to microservices. The focus is on evolution of components, how we build systems that allow evolution and change.
Russ defines microservices as single purpose services that do one thing and do it well at the level of granularity that supports your systems evolution and the strains that you consider important for runtime and design time. The main focus is trying to build software that can adapt and we can only do that if the pieces are small enough to support the differentiation in change across your architecture.
Is Microservices doing SOA the right way? One problem Russ has with SOA is the substantial baggage he thinks goes with the term. He argues that the biggest architectural difference between SOA and microservices is the flow of data through a system, a pipeline of data which he sees as a key abstraction, comparing it with a UNIX pipeline. Russ believes that this pipeline is important and the key motivator driving which microservices to create. In SOA, typically with a hierarchy of services organised in layers, we lose this flow of data because it’s orchestrated within the services.
One big complaint Russ hears is about problems in management and monitoring when breaking one system into many small services. His best advice is to not build services that send out messages either that they are OK or that they are failing, instead have them send “actionable information”, a service should inform about its problems but also what should be done.
