The Lost World of Micro Services

The Lost World of Micro Services

I have seen the designs of new generation travel management platforms where even experienced architects build the complexity in the Micro Services design which makes it really difficult to manage things in live production. Slicing of services to numerous components without having the wisdom view at the “actual service” and then try to orchestrate them through the service registry, eventually ends up in rather “noodle like” design where the architects lose direction. Micro services architecture is introduced to reduce complexity and benefit the business and not just for the sake of it. Architects may think that they can impress an audience with a system diagram to fit to a 12 Ft X 12 Ft sheet. But it comes to actual operations, the stuff fails and creates complexity and frustration in abundance.

Andrew Gasparovic (VP & Cheif Architect of Sabre Labs) had given out a lecture on “Micro Services” architecture in Nasscom product Conclave, 2019 at Bangalore on 6th November, 2019. Andrew had mentioned three important and highly relevant points related to Micro Services. Let me articulate them here.  

  1. Simplicity wins when you are talking about Micro Services at 10 X scale.
    Reduce the complexity when the Micro Services are defined and designed. The complexity increases when the micro services are defined and then bundled together where each of them need to communicate each other in symphony, the underneath technology stack to be resilient enough to assure the availability and performance etc.
  2. Focus on “services” rather than concentrating on word “micro”.
    Architects tend to slice the features to small chunks as small as possible and assign them to individual servers. The services need to have a purpose for its existence. Some service may be compute intensive but stateless, one may be too large with lot of dependencies, another may be stateful, another need to  interact with database frequently etc.  Each of them should have a purpose with right resources to support them. If the design is too flat with very large number of micro components defined, then it eventually brings in the high complexity of management overhead. If the design is too vertical in nature, then it kills the purpose of Micro services by attaching dependency on each other which may affect stability and performance.
  3. Get comfortable with in between “states”.
    When the designers decouple the services for convenience and manageability, orchestrate them to tune the availability and performance to perfection, the state of those services while they interact each other need to be taken care with utmost care. The services need to be backward and forward compatible during upgrades and releases; especially when they are supposed to be “rolling” in nature for maintenance and management to comply to the availability requirements. Losing the way in this might cause more service disruptions and increase the recovery time than bringing in benefits.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top