Literature Review of Key Benefits Link to heading
This section highlights the key benefits of microservices architecture according to several sources.
- According to Martin Fowler’s article Microservice Trade-Offs:
- Strong Module Boundaries
- Independent Deployment
- Technology Diversity
- According to Chapter 1 of Building Microservices (First Edition):
- Resilience
- Scalability
- Organizational Alignment
Strong Module Boundaries Link to heading
Chunks of software that are decoupled from each other […] Good modular structure is useful in any program, but becomes exponentially more important as the software grows in size.
Modularity is a key principle of microservices architecture. Each service should be small and focused on doing one thing well. This approach aligns with the Low Coupling, High Cohesion principle, ensuring that services function as independent units with minimal interdependencies. Each service is responsible for a clearly defined piece of functionality.
To achieve this, it’s essential to define service boundaries that align with business domains, making it clear where each piece of functionality belongs.
Independent Deployment Link to heading
A key principle of microservices is that services are components and thus are independently deployable.
However, many attempts at microservices fail at independent deployment. Multiple services sometimes require careful coordination to be released together, which undermines one of the fundamental benefits of microservices.
Technology Diversity Link to heading
Since each microservice is an independently deployable unit, you have considerable freedom in your technology choices within it. Microservices can be written in different languages, use different libraries, and use different data stores.
This flexibility allows teams to evolve their parts of the system independently, adopting technologies that best fit their needs. It gives you the freedom to choose the most suitable stacks and to release new versions at will.
Resilience Link to heading
If one component of a system fails, the failure doesn’t cascade.
By running multiple instances of the same service, the system can continue to operate in a degraded mode, ensuring overall functionality even when individual services encounter issues.
However, microservices also introduce new points of failure. Networks and machines can fail, so you must plan for this and understand the impact on end users.
Scalability Link to heading
With a large, monolithic service, we have to scale everything together. With smaller services, we can scale only those services that need it.
When considering scalability, ask yourself: What problem are we solving? Do we have enough data to justify splitting services for performance or scaling reasons? Can our system scale and remain resilient simultaneously? Microservices encourage distributed systems designed for size and resilience, but this introduces complexities: backpressure, circuit breakers, queues, jitter, and sensible timeouts all become essential considerations.1
Organizational Alignment Link to heading
We also know that smaller teams working on smaller codebases tend to be more productive.
Conway’s Law suggests that software structures often reflect the communication structures of the organizations that build them. Aligning service ownership with teams that share physical proximity and focus on the same bounded contexts is crucial. Autonomous microservices teams should be loosely coupled, responsible for a specific business function, and free to develop, deploy, and scale services as they see fit.
Literature Review of Key Challenges Link to heading
It’s important to maintain a balanced view. In the following sections, we’ll address the potential drawbacks and challenges of implementing microservices.
- According to Martin Fowler’s Microservice Trade-Offs:
- Distribution
- Eventual Consistency
- Operational Complexity
Distribution Link to heading
Distributed systems are harder to program, since remote calls are slow and always at risk of failure.
- Performance issues: Remote calls add latency.
- Asynchronous programming is challenging: It’s more difficult to get right and much harder to debug, yet sometimes necessary for acceptable performance.
- Fallacies of Distributed Computing
Related blog article: My microservice architecture is timing out
Eventual Consistency Link to heading
With a monolith, you can update multiple things together in a single transaction. Microservices require multiple resources to update, and distributed transactions.
Microservices often lead to data fragmentation across multiple databases or storage systems, each optimized for a particular service. This makes maintaining data consistency and integrity across the entire system more complex.2
The SAGA pattern is commonly used to handle eventual consistency.
Operational Complexity Link to heading
You need a mature operations team to manage numerous services, which are redeployed regularly.
Effective operations require a DevOps culture, with greater collaboration between developers, operations, and everyone else involved in software delivery. Microservices demand more operational competence than monoliths.
The Golden Rule Link to heading
Strong Module Boundaries and Independent Deployment principles emphasize a critical point3:
Without decoupling, everything breaks down for us. The golden rule: Can you make a change to a service and deploy it by itself without changing anything else?
To achieve this, you must:
- Model your services correctly (e.g., using Bounded Contexts).
- Get the APIs right.
Start by Drawing Boundaries Link to heading
If you are unable to design a monolith that is cleanly divided into components, you will also be unable to design a microservice system.4
Give Yourself Time to Reflect Link to heading
Microservices architecture has distinct advantages and challenges. While it has significantly influenced software design over the past decade, adopting it demands careful consideration. The following checklist, reflecting my own perspective, can help guide your decision-making process.
| Theme | Question | Yes/No |
|---|---|---|
| Strong Module Boundaries | Do we have domain experts? | |
| Independent Deployment | Can we easily set up the necessary CI/CD pipelines, containerization, and orchestration for independent deployments? | |
| Do we have the operational capacity, as well as the monitoring, logging, and tracing capabilities, to manage multiple independent services? | ||
| Technology Diversity | Do we need flexibility to use different technology stacks, frameworks, or databases for different parts of the system? | |
| Structural Organization | Are our teams structured so that each can own a service end-to-end without heavy cross-team dependencies? | |
| Does the team have the ability to develop, deploy, and scale services as they see fit? | ||
| Resilience | Is it crucial to maintain partial system functionality if one component fails? | |
| Scalability | Do different parts of the system have distinct performance or scaling requirements that justify targeted scaling? | |
| Human Resources | Do we have the talent to handle the increased complexity in infrastructure, deployment, and maintenance? | |
| Do we have the budget to handle the additional complexity and operational costs (e.g., tooling, cloud infrastructure)? |
The Modular Monolith as an Alternative Link to heading
- In reality, few companies require extensive scalability or resilience. Often, the primary goal is to improve software decoupling.
- In many organizations, software becomes a Big Ball of Mud, difficult to refactor and maintain, and hard to sustain productivity over time.
- Many decision-makers believe that adopting microservices will solve all their problems. However, the core issue often lies in achieving proper modularity.
Sam Newman, in Building Microservices (2nd Edition), endorses using microservices only after becoming convinced of their benefits, rather than defaulting to them in every project.
A monolithic architecture is a choice, and a valid one at that. I’d go further and say that in my opinion it is the sensible default choice as an architectural style. In other words, I am looking for a reason to be convinced to use microservices, rather than looking for a reason not to use them.
Taking Advantages of Both Worlds Link to heading
A modular monolithic approach addresses modularity concerns effectively.
There’s no reason why a monolithic system shouldn’t have a good modular structure.
By emphasizing clear separation of concerns, different functionalities can be encapsulated within distinct, well-defined modules. These modules interact through in-memory calls, maintaining efficient communication without the overhead of network calls. A consistent codebase and shared runtime environment help enforce boundaries while preserving simplicity and coherence across the system.
Further Reading Link to heading
General Articles
- Microservices Guide
- Microservice Trade-Offs - Martin Fowler
- Monolith First - Martin Fowler
- The microservice architecture is meant to simplify and accelerate development, but only when done correctly
What’s Wrong with Microservices
Modular Monolith Approach
https://www.shopify.com/enterprise/blog/disadvantages-microservices# ↩︎
Building Microservices (First Edition) page 3 ↩︎
https://softwareengineering.stackexchange.com/a/339234/385571 ↩︎