Microservice Architecture overheads

Courtesy: Benjamin Wootton

1. Release and Deployment management of the set of Micro services requires a highly mature R&D automation support. 
2. Operational overhead -- Testing, deploying and maintaining a set of microservices is time and energy intensive.
3. For failover and resilience, Microservices need clustering, therefore a Monolith will now comprise tens of services (instead of 1 in a monolith). 
4. Coupled with messaging layers, and loadbalancers, the landscape gets complicated. 
5. Keeping this complex landscape functioning, by way of monitoring and production support would be daunting -- 1. Ensuring the processes stay up 2. Ensuring they don't consume up disk space + housekeeping 3. Deadlock management, etc. 
6. All the above factors mean, a strong DevOps profile is needed, which may be hard to source. 
7. Change to syntax or semantics of components results in a need to alter them on the other components as well. And to put these changes to production require a coordinated release. 
8.   Suppose there is a need to recalculate tax differently for a particular product line. Now we have multiple options - - 1. Add a new service and call this service from other services. 2. Add the recalculation bit to all the services that require recalculation. 3. Have a tax calculating library (which requires parallel releases to ensure interface sanity) Either ways, the test and deployment effort is huge.
9. This whole lot leads to a complex distributed system where network latency, fault tolerance, message serialisation, unreliable networks, asynchronicity, versioning, varying loads of application need to be taken care of. 
10. Microservices architecture leads to asynchronous systems, however where synchronicity is desired,  managing correlation IDs / transaction IDs could be cumbersome. 
11. Microservices landscape is dynamic with numerous inter-service interactions going on. Recreating test environments to carry out manual / automated tests may be difficult to achieve.