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.

Since it’s fairly well known that complex distributed applications are a difficult undertaking, the fact that many people in the software industry seem to believe a large-scale orchestration of microservices to produce a complex resulting application is simple is ridiculous.

The most commonly touted MSA I’ve seen gives no thought to shared storage or eventing, which should be the first two things settled on before attempting any distributed architecture. MSA in many ways does simply take SOA and go further, but that further doesn’t make it easier, it makes it more difficult. Done properly, it should also offer better horizontal scalability, more flexibility when refactoring, etc., but those don’t come for free.

The easiest way to begin thinking about it is that with your finished microservices 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.

The quickest answer is to look at the required functionality for a complex distributed application, because in essence, that’s what you’re creating. The simplicity of the services themselves only moves the complexity up the stack. From that functionality you can determine the state that needs to be maintained by each service and the shared context that all the services will need access to. Finally you need to make a decision on what will have the capability to modify that context and how you’re going to make it easily and quickly available to every service involved in the orchestration.