Microservices Archietcture : Quick Intro

After the evolution of cloud application development & deployment has changed drastically but one core thing remained same about the applications is the time to market. Any small change requires entire application to be tested and deployed which limits the business to achieve the goals to maximize the revenue of each opportunity available in the market. Traditional architecture approach which is generally known as monolith is now getting transformed into new microservices based architecture model. Before jumping into the detailed understanding of the microservices let us see what is monolith & attributes associated with it…I will be publishing learning series to help understand the underlying core concepts of microservices architecture(MSA)

Monolith : It typically starts with a common simple codebase with defined tech stack and becomes non-maintainable over the period of time that qualifies to be called as “monolith”. Some attributes associated with it are….

  •  Long testing cycles for each deployment cycle(Automation helps but to limited extent)
  • Defined tech stack
  • Results in too many issues for small changes
  • High learning curve (complex codebase)
  • Maintained by large teams
  • Too many/Complex dependencies etc (Tightly coupled)

SOA came to the rescue but….

  •  Resulted in tightly coupled services based monolith
  • One dimension scalability
  • Carried forward all the problems from traditional monolith design, development & deployment

Microservices is an architecture paradigm which breaks large software monolith architectures into loosely coupled services, which communicate with each other through simple APIs and can be independently created, deployed without impacting the ecosystem. Adheres to some common principles…

  •  Single Responsibility Principle (Self-contained & autonomous)
  • Owned by small team
  • Small code base
  • Supports Polyglot tech stack with technology agnostic interfaces
  • Deployed in independent containers
  • Domain Driven Design

Microservices Architecture (MSA) is topping the charts of technology industry discussions, People are both overwhelmed & confused about architecture pattern which has announced itself with great promises. We have to be cautious not to get carried away with the blind implementation irrespective of the scenario of business context.

Please understand the details of MSA and your business context before jumping into the implementation. MSA does require high degree of commitment, skills and there is additional complexity, structural changes for which your team/organization needs to plan well to scale the operations to live with it. MSA is not a free lunch 🙂


Below I’m calling out the advantages, disadvantages & implementation challenges of MSA based on exposure to some of the ecommerce based implementations:



Implementation Challenges

  • Loosely coupled systems
  • Independent & modularized, can developed by different teams
  • Polyglot
  • Flexible for scaling
  • Failure/Fault isolation(Design for failure, Tolerance/Resilience built-in)
  • Faster Time to Market (Quick updates without downtime)
  • Independently deployable
  • Compute based resources
  • Cloud based infrastructure with automation
  • Supports event driven programming
  • Created based on domain lines mapping to the business capabilities
  • Distributed & localized governance
  • Supports Domain Driven Design
  • Eases team structures (Conway’s Law)
  • Reduces code complexity for developers (Small Services = Small Codebase)

  • Increased Complexity due to highly distributed systems
  • Effort intensive operations
  • Complex configuration management
  • Majority of them are stateless
  • Eventual Consistency
  • Code duplication goes unnoticed
  • Contract definitions (implicit interfaces)
  • Trap you into distributed ball of mud
  • Hype around MSA
  • Not all developers embrace it
  • Communication overhead
  • Polyglot complexity
  • Operational complexity
  • Spike in infra use
  • Transition to Distributed Systems
  • Testing MSA
  • Scattered business logic (all over the place )
  • Lack of dependency view for change impact
  • Have to live with CAP
  • Modelling ( Domain & Data)
  • Need for high quality devops skills
  • Expensive (during nitial cycles)
  • Asynchronous communication
  • Services versioning
  • Increased/Multiple no of databases
  • Network communication & security
  • DevOps skillset availability (CICD Pipelines & dependencies, Configurations, Monitoring, Maintenance)

Above challenges are only subset of the bigger list and most of them have solution in their own context of design & architecture problems but there is no one solution which that fits all. Hence please ensure the due diligence to apply the fixes for the problems. Also some core things you can do are…

Ensure you have ….

  • Right team who are up for the challenge
  • Start small to make improvements on the way (Big bang is the recipe for failure) – Simplicity helps
  • Leverage right tools & automations to help the MSA cause
  • Embrace team, customer & product goals
  • Pragmatic approach works 🙂



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s