Beyond the computing science jargon, the advantage of this approach is that it allows complex web applications to be developed by different teams without the danger that either will disrupt the other. Changes to a microservice never risk bringing down the others cooperating in the larger workflow. It also scales far more efficiently than simply firing up a new instance of a monolithic application because it allows the specific microservice needed to be scaled individually. In theory, this offers big efficiency gains for cloud applications based on virtualised infrastructure.
Microservices explained - the dictatorship of terminology
But is it really as simple as this? A common criticism is that microservices ends up looking like a reheated form of Service Oriented Architecture (SOA), albeit more defined than SOA ever was. It is also not clear that applications built on microservices architectures are mature enough to make fine judgments about their strength over time. Further objections were made by ThoughtWorks in an influential article on the topic published in 2014:
"In any effort at componentization, success depends on how well the software fits into components. It's hard to figure out exactly where the component boundaries should lie," wrote Martin Fowler.
It's a valid point. Exactly which microservice should do what is not easy to state independent of a specific project. Put another way, microservices will vary from implementation to implementation.
"Another issue is If the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components. Not just does this just move complexity around, it moves it to a place that's less explicit and harder to control," continued Fowler, who went ton to fret about the possibility that microservices could also be implemented badly by weak teams lacking experience.
Microservices explained - conclusion
These are the words of a microservices fan and so it's not hard to imagine that there are also sceptics out there who believe the whole idea is just a reheating of established principles in a new guise. Software development architectures seem to be prone to these complex controversies. What microservices aren't is a simple in situ replacement for monolithic applications.
In the end, the best argument for microservices architectures are the companies using it in real applications, assuming one accepts that so many diverse implementations can be satisfactorily filed under one label. Poster kids for this include Netflix, which describes how it has used microservices to optimise performance. Another big fan has been music site SoundCloud, which migrated to a microservices way of looking at the world after starting in with monolithic applications.
A key feature many microservices-oriented firms have in common is that they are new, or the systems they have built using them are recent. Oddly, many seem to have been using them long before anyone called them microservices. This tells us that the term is like every other term to hit software development since the beginning of the modern era of business - it's always more evolution than revolution.
Sign up for Computerworld eNewsletters.