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.

« April 2015 | Main | April 2016 »

September 28, 2015

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

Author: Archana Kamat, Product Technical Architect

In my previous blog, "Macro to Microservice Architecture - Shrink or Sink? Part 1", we explored the basic characteristics of MSA and how it differs from Service-oriented Architecture (SOA). While MSA enables higher service independency, it cannot be applied to all business scenarios. 

To better understand MSA's benefits and challenges, let us consider the real-world use case of an online shopper's basket. Typically, the shopping process involves the buyer browsing through different product catalogs after which he or she will interact with the shopping basket to add or remove items. Finally, the buyer checks out the shopping basket by providing required information.

The illustrative class diagram below shows SOA and MSA style designs for this use case. In SOA, related functionalities are encapsulated in one service with modular operations/methods. Cross-cutting aspects logic common at service level is modeled as reusable operations. However, cross-cutting aspects logic common across all services/ components is modeled as separate foundational services and consumed by other services. On the other hand, in MSA style design every function is modeled as an independent service with independent data access logic, audit logic, etc.

View image

Using the above example, we can analyze the benefits and challenges of MSA.

Benefits of MSA:

  • Simplicity - Since each service performs only one function, it is simpler to understand and enhance
  • Flexibility - As each service is independent and loosely-coupled in all aspects, there is greater flexibility for technology selection, design pattern, modification, replacement, enhancement of functionality, and deployment
  • Parallel development and DevOps model - Multiple developers with different skill-sets can be engaged in development and software development lifecycle (SDLC) activities. With its high granularity and isolation, MSA can support the DevOps model, thereby enabling continuous delivery and frequent releases without impacting availability and stability of the remaining systems.
  • Scalability - Individual services can be easily scaled up without impacting other services
  • Application programming interface (API) integration model - Micro services are best-suited for exposure as APIs in API-oriented architecture
  • Agility - With better simplicity, flexibility, scalability, etc., it is easier to incorporate modifications to existing services as well as on-board new services.

Challenges of MSA:

  • Chatty interfaces - As seen in the illustration, MSA requires more interfaces when compared with SOA. To execute a simple workflow of a shopping basket, the service consumer needs to instantiate and invoke a number of services.
  • Higher cost - The decentralization or isolation of team, technology stack, process, and governance can create chaos and increase costs. Further, fine-grained services can result in overheads in collaboration, synchronization, etc.
  • High resource provisioning - Owing to higher number of services in MSA, there is a greater need for resource usage such as CPU, memory and network for interaction, data marshalling, containerization, and other processing needs of chatty interfaces.
  • Security issues - Security risk increases as more and more services become disjointed.
  • Production and operational costs - The cost and effort to deploy, manage and monitor services is higher for MSA than SOA. For instance, one log analysis in SOA style may require N log analyses in MSA style for the same use case. 

The good news is that, to handle the challenges involved in MSA, there are a number of new tools and technology products coming up such as those for automated deployment, monitoring, aggregation of logs, and other maintenance activities. However, one still has to consider all existing challenges before transitioning to MSA style.

Deciding what's best for your business

Enterprises with heavy core lines of business (LOB) systems may not benefit a lot from a pure MSA approach. Such businesses can adopt a hybrid approach that incorporates the best of both styles such as moderate granularity and isolation from MSA along with the cohesiveness, uniformity and governance of SOA.

MSA may be the best-fit for use cases that do not depend on core business logic and are peripheral or accelerators to the business. For example, consider an e-Commerce application that needs to launch a quick promotion program for special discounts, auctions, etc. Such requirements have a short lifespan and may last only for a specific season. Here, agility becomes more important than long-term durability or maintenance. In such a situation, MSA is a better fit since multiple, disciplined and cross-functional agile teams can execute a "quick 'n dirty" (Q'n'D) but robust implementation and get these promotions on-board within the desired timeframe.


The success of any architecture paradigm, whether new or old, depends on understanding the key characteristics and patterns of the architecture style. This is an important step since most architecture styles may not directly fit the requirements of an enterprise without some degree of customization. For instance, to get most from that style architects have to tweak them by customizing, simplification and sometime complicating it too.

Same was true with SOA. When SOA was introduced as a new style, many small, medium and large enterprises were able to transition to SOA from traditional layered architecture style. Many success stories reaped benefits, but some failures too.  

Similarly with micro-services bandwagon, industry is stirred up with its adoption wave. Before embarking the transition journey in big-scale it is essential to analyze challenges and benefits relevant to the enterprise requirements. Some cases granularity and isolation of MSA may pay off, but in other cases the cohesiveness, redundancy and centralization of SOA may be worth considering.

After all, no single architecture is a silver-bullet for all requirements.

References - Good Reads

MSA proposal By Martin Fowler and James Lewis:

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.