Some Thoughts on Microservices Architecture
Microservices architecture is not a bad thing. Microservices offer inherent horizontal scalability, decomposition into small parts, etc. But microservices architectures are also the fastest way to lose your shirt if you don’t think fully through what you’re attempting to accomplish.
Put it this way: what are the major differences between a complex distributed application and a large-scale orchestration of microservices?
· The base protocol of most microservices, REST, is one of the most limited protocols available, particularly in terms of recoverability from network errors.
· There is no developed, proven framework for orchestrating microservices, whereas the Actor framework in distributed applications is well-known, well-proven and available today on a number of platforms beyond ERLANG and Smalltalk.
· The pieces of a distributed application were designed with that application in mind.
· Some thought has usually been given as to how the overall state of the application is to be maintained, while many microservice developers and management proponents seem to think that it will magically maintain itself.
And the biggest difference? Terminology, nothing more, nothing less.
Since it’s fairly well known that complex distributed applications are a difficult undertaking, that many people in the software industry seem to believe a large-scale orchestration of microservices to produce a complex resulting application is going to be easy is beyond ridiculous. And if you ask someone to demonstrate an example, they can’t.
The most commonly touted MSA I’ve seen gives no thought whatsoever to shared storage or eventing, which should be the first two things settled on before attempting any distributed architecture. In fact, it appears to be a means of managing developers on projects that are simply too large for an agile team of < 10 developers, not a software architecture at all.
MSA in many ways does simply take SOA and go further, but that further doesn’t make it easier, it makes it much more difficult. Done properly, it should also offer better horizontal scalability, more flexibility, easier refactoring, greater reusability, etc., but none of those come for free.
The easiest way to begin thinking about it is that with your finished microservices (oh yea, you have to write reliable, reusable microservices as well as orchestrate them) you have a set of reusable functionalities, but you don’t yet have a system. How you go about building a system from that set will determine in the end whether you have a flexible, maintainable architecture or a stress-inducing money pit that accomplishes little to nothing.
