“Microservices are simple, lightweight architectural components that create software that thrives on change, that is secure and stable, and that can be delivered faster.”
First up, microservices is a blanket term that is being used, and often confused, when referring to systems that exhibit certain really useful characteristics. In many ways the term is a little unhelpful as it focusses attention on the parts of a system, that they should be highly granular and even can be mistaken for only having one way of interacting with them (HTTP typically), when in fact the real value is understanding the systemic properties that the approach helps us achieve.
It’s a confusing thing that in fact the actual microservices themselves are not usually the interesting piece of the puzzle. It’s the ‘glue’ between them and the various options that make up that glue at design and runtime that lead us to systemic properties, such as antifragility, that are more important than whether something is ‘micro’ or not.
It’s a cliche, but size really doesn’t matter, especially when referring to the individual parts of a system. What matters is what you can do with the system itself, and it just so happens that what we are now calling microservice-based architectures exhibit some valuable systemic properties.
This is an old goal in software development, but one that has become uniquely acute in today’s marketplaces where being an incumbent is not usually enough. Being able to compete is essential, and so having software development processes that can bring the agility that allows a company to be competitive, and having software systems that allow that agility, are becoming crucial factors in a company’s success.
It is this goal that I believe is the future of software architecture and design, microservices is a useful reminder term that is asking us to consider how systems need to thrive on change and that will only become more important in the future.
The benefits are all about the business really, which is nice for a software architectural approach.
The challenge usually exists in obtaining the systemic benefits by carefully integratingyour microservices such that they can really evolve at their own rates and give you a platform for change and innovation. That is the difficult part, and requires many of the same skills that have been developed when considering integration in the past with some new nuances.
I’d go as far to say that adopting antifragility, i.e. the need to thrive on change, into our software systems is likely to last a lot longer than the term ‘microservices’. For me, software system design gravitates to the right principles that support the pressures on the software, and I can be fairly confident that the key pressure right now and in the future is likely to be change and fostering innovation.
What are labelled ‘microservices' right now are some useful principles that we can apply to begin to build systems that support those pressures of change. The proof of things for me will be when we stop referring to things as microservices and begin to worry about the systemic properties we need again right at the forefront; that is the point at which microservices is essentially mainstream as the antifragility of our systems, and their ability to thrive on design-time and runtime change, has been recognised as the mainstream concern that it is.