If there is one big transition that took place in the past decade or so in terms of application development style and deployment patterns then it has to be migration from Monolithic application development to Microservices.

The latter had provided us with various advantages by splitting the bigger application into various smaller chunks with each chunk being called a microservice.

• Each chunk can be written in a different programming language and have its own database that suits the scale at which the chunk operates.
• Each chunk can scale independently based on the amount of processing it does.
• Build time and application startup time will be drastically reduced which allows us to have a lesser downtime in case any of the microservice crashes due to an outage in resources or any unhandled exceptions.
• More importantly, if something goes wrong in one service, it will not impact the overall funnel.

There are many such advantages that the newer microservices architecture brings to us but there is one thing and one major thing that this approach is failing to provide us which is TRUST.

When I say trust, it’s a trust put by one service on all the dependent services and the dependent services on their respective depending services. The reasons for not being able to trust the other services being

• The communication happens through a network which might be unreliable.
• The core functionality of the other services is abstracted out in such a way that the caller won’t be sure how big of processing the other service does in order to serve the response required by the caller.
• The caller was restricted in a boundary wherein if something goes wrong outside his boundary, he/she won’t be able to figure it out.

#resilience #microservices #scalability