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.
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: http://martinfowler.com/articles/microservices.html