I was asked recently to answer some question on Microservices before the excitement of the sell-out MuCon conference kicks off next week. Here are some of those questions and my answers. Hopefully they give a bit of a hint as to what my keynote that kicks off the conference is going to be all about.
Question 1. Is this an accurate description of microservices?:
“Microservices are simple, lightweight architectural components that create software that thrives on change, that is secure and stable, and that can be delivered faster.”
“Microservices are simple, lightweight architectural components that create software that thrives on change, that is secure and stable, and that can be delivered faster.”
My Answer:
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.
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.
Question 2. Are microservices the future direction for software architectures?
‘Microservices' for me is a reminder term, something that is attempting to remind us of something to design for. In actuality, the real problem is attempting to architect, build and deploy software that embraces, or even thrives, on change; software that keeps up with the agility that our BizDevOps (Business, Development and Operations working together) teams will demand as they attempt to innovate quickly in order to help a company be competitive.
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.
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.
Question 3. What are the main benefits that microservices offer?
For me this comes back to real business benefits. Any system, software or otherwise, that meets a company’s needs for change such that they can compete is going to be very successful. Microservices is an outcome of designing for a software system that is made up of small, independently evolving pieces that can importantly embrace the necessary change that meets the business need.
The benefits are all about the business really, which is nice for a software architectural approach.
The benefits are all about the business really, which is nice for a software architectural approach.
Question 4. What do you personally like best about what microservices offer?
The direct relation to building systems that thrive on change, that therefore support innovation, that therefore support the real end goal which is supporting a company to compete.
Question 6. Don’t people need a lot of training to become proficient in using microservices?
It’s true that it does require a different approach to systems architecture and design and so there is a learning curve there. Once you have a model, like the Life Preserver tool I use in my course, that helps you decide how big your microservices need to be, what they should do, and where they should be in your system then the actual building of the microservices themselves tends to be relatively trivial.
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.
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.
Question 7. Have microservices been used for long enough for anyone to be sure that they can be the future?
I’m really wary of stamping anything as ’the future’. This industry has never been very good at defining its future, and being antifragile and stoic in my approach (both useful system properties that we look for in microservice-based architectures ironically) I’m wary of most predictions as they rarely survive the impact with reality.
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.
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.
Question 8: What's the bottom line for you in terms of Microservices?
Bottom line for me, microservices is a useful term to get people thinking about building antifragile software systems that bring business beneficial properties. It’s likely the term will retire into the background as these approaches become recognisably mainstream, and that will only be a good thing for both software development and businesses in the future.
RSS Feed
