Simply speaking, the Microservice architecture is following the path of further software granularization to construct each software application as a set of small services, each performing one simple function, running in its own process and communicating with lightweight mechanisms, often through an HTTP resource API such as a REST API. These “micro”-sized services can be deployed independently and grouped together to jointly perform required complex capabilities which traditionally would be handled by one monolithic application with many embedded components and dependencies packaged inside. Errors could be isolated and fixed by re-deploying a few microservices instead of bringing down the entire system. Some startup companies promoting microservices have used the analogy of Apple App Store – so that they can offer PaaS with a rich collection of these microservices for a particular platform.

Differing from the plumbing used in many existing enterprise architectures where complex transformation rules, messaging and interchanges between systems are put on the Enterprise Service Bus in the middle, microservices adopt the idea of “smart endpoints, but dumb pipes”. It emphasizes the ready-deployable nature of the lightweight individual services from the start point to the destination without extra handling in between.

The benefits offered by the fine-grained microservices come with certain cost. For example, instead of a limited number of SLAs for an enterprise application, now numerous SLAs need to be created and maintained at the same time. Each microservice also needs load-balancing and fault-tolerance. Deploying, Managing, communicating, versioning and testing the complexity of the system with a huge number of microservices are demanding tasks.

The most intriguing aspect of microservice concept is that from the decentralized nature of its design patterns, it calls for corresponding changes to the traditional organizational structure by invoking Conway’s Law. Melvin Conway, a computer programmer, in 1968 mentioned that, “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” If one reflects carefully, it could be surprisingly true. Thus microservice concept calls for organizations to be organized around business capabilities instead of functions. Because each microservice, although “micro” in context, is an independently deployable service of its own, it must contain all cross-functional service basics as needed and developers must have UI, database, deployment, etc., full stack of skills to build and own the microservices.

Although microservice’s granularization is one form of software modularization, TriStrategist thinks that it may well be short of achieving the goal as tomorrow’s choice for distributed computing. Meaningful architecture abstraction to separate data from mechanisms, separate information from means of delivery will be needed and modularization will be the key for providing the flexibility required for distributed computing, but to meet the desired results, very likely we need both the re-thinking of software application architecture and cloud platform architecture. The future inter-deployable services, micro or not, need to be platform-neutral to truly address the essence of distributed computing. In addition, instead of thinking either smart endpoints or smart pipes, TriStrategist thinks that we need think more towards adding self-managed intelligence at each cross-point in the distributed picture.