Microservices

Microservices or Micro Service Architecture (MSA) is being advertised heavily these days mostly by Thoughtworks.

At first it looks like a great idea, in fact it is a great idea if you look at this this way:

• There are boundaries between services.
• Each service is small enough to understand, to be re-written, etc.
• Each service is supposed to do only one thing.
• Each service can be so fine grained that it can even correspond to a single database table (extreme?)
• etc.

I would like to call it a “pattern” as it has its own pro’s and con’s. But none of these are new concepts or best practices on their own. To me MSA at its core seems like a style (or part) of SOA since services are the “things” you work with.

On the other hand there are few areas where the current articles and enthusiasts are not very clear about:

• How do we orchestrate a ton of services? In all videos and articles they diminish ESBs. I am not a fan of ESBs but they do a fine job of orchestration but MSA is not clear about it. I have seen suggestions on using a thin layer of orchestration, using messaging or RESTful styles, etc but if you have a million of microservice then it would be a nightmare.
• If we create too restricted boundaries around our services and they become so isolated then how do they communicate from a database perspective? How sales database can be so separate from ordering database?
• Lots of small services makes transaction management a big job.
•  etc

Given these concerns you have to be very careful when you use MSA. I feel this is an old concept with a new name which is not yet mature to become a full fledged style of architecture. Probably it is good in smaller applications with mostly read-only services or services which are inherently separable….Time will tell…