Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Agile Contracts | Main | Macro to Microservice Architecture - Shrink or Sink? Part-2 »

Macro to Microservice Architecture - Shrink or Sink? Part-1

Author: Archana Kamat, Product Technical Architect

The world of software service architecture is witnessing rapid change owing to a new paradigm named Microservice Architecture (MSA). There are several debates and questions about this newcomer. Sample these:

  • Is MSA over-hyped?
  • Is MSA opponent to service-oriented architecture (SOA) or merely a specialized form of SOA?
  • What are the benefits and challenges of MSA?

To answer these and other questions, let us first explore the value of MSA versus SOA by understanding their definitions and characteristics.

  • Service-oriented Architecture (SOA) is a matured software architectural style that has evolved over the last decade and comprises of autonomous, stateless and loosely-coupled services.
  • Microservice Architecture (MSA) is a budding software architecture style with a suite of small, granular and independent services.

 While both these architecture styles have services at their core, the differentiating factor is the degree of granularity and independency (isolation) of their services. 

Independency in MSA: With MSA, the services provided should be independent of each other across the technology stack, standards, development teams, deployment, infrastructure, governance, etc. Owing to such isolation, it becomes acceptable to enable service duplication for functional logic, cross-cutting aspects logic, etc. 

Independency in SOA: In SOA, services should be autonomous and loosely-coupled, which means one service cannot depend on the state of other services. Though loose-coupling is the objective of SOA too, it emphasizes on the  cohesiveness across services in terms of reusable functionality, unified technology stack, unified infrastructure, centralized governance, and coherent teams.

Granularity in MSA: The service granularity needs to be very small or fine. Although there are no formal benchmarks for the lines of code (LoC) required for each service, the optimum number to consider is less than or equal to 100 LoCs per service. Here, each granular functionality is modeled as a service. Further, service consumers can integrate multiple services to achieve a business function. 

Granularity in SOA: While SOA can also model the fine-grained services as delivered in MSA, the recommended granularity for SOA is larger. Granularity is at a discrete business function level instead of a minute function level. Each service can be further modularized with independent methods or operations. Common cross-cutting aspects such as data access, logging, auditing, exception handlers, etc., are isolated from individual services and modeled as common horizontal services. Thus, SOA recommends loose-coupling and high-cohesion with balanced granularity.

The graphic below summarizes key characteristics of MSA versus SOA.

View image

On analyzing the above characteristics, it seems like: while MSA is not a revolutionary form of service architecture, it is a specialized branch of SOA that:

  • Delivers fine-granularity
  • Enables a delivery model for DevOps and continuous integration (CI)
  • Yields a containerization concept for high flexibility and scalability

To further illustrate the benefits and challenges of MSA, I have provided an example in my next blog.

Edits for the graphic:



Service design:

  • Fine-grained, small, local services
  • Independent and decoupled
  • Resource-based HTTP services
  • Modeled around business functions and not technology domains
  • Independent technology stack and design

Service design:

  • Coarse-grained, composite, centralized services
  • Balanced, loosely-coupled and cohesive
  • Explicit resources and interface-based services
  • Modeled on business functions as well as technology domains
  • Strategic and unified technology stack and design


  • Smart end-points and dumb pipes, i.e., anti-enterprise service bus (ESB)
  • Integration/ orchestration enabled through service interfaces and application programming interfaces (API)


  • Strengthened by ESB products
  • Integration/ orchestration enabled through ESB as well as other APIs


Deployment - Operational:

  • Decentralized governance
  • Independent/ isolated build and deployment
  • Containerized/ virtualized standalone process
  • Less dependency on infrastructure for non-functional requirements (NFR)
  • Intelligence is built into the service

Deployment - Operational:

  • Centralized, strategic governance
  • Synchronized/ collaborated build and deployment on unified server platforms
  • High dependency on infrastructure for NFR and operational logic


  • Designed for failure and is easily replaceable. In case of service variations, it is better to design a new service rather than modify an existing one.
  • Less decay of monolithic architecture
  • Currently at inception phase where standards, patterns, products, and tools are yet to evolve


  • Designed for durability, robustness and enhancements. Variations can be implemented within the same service as a different version.
  • Evolved architecture with well-matured standards, patterns, products and tools

(Footnotes with diagram)

  • Technology domains refer to services classified as user interface services, data services, business services, etc.
  • SOA does not mandate ESB for implementation. However, the emergence of ESB products for SOA has had a significant impact, causing the majority to consider ESB synonymous with SOA.


Very well explained

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.