Should Microservices Be Your Default Architecture? Key Questions to Ask

Although the microservices concept has been popular for some time, every technology has its pros and cons. After seeing microservices play both hero and villain roles, ThoughtFocus architect Ebin John suggests developers ask themselves the following questions if they tend to treat microservices as the default architecture.

1. Is your application large enough to be split into microservices?

Microservices are a collection of small, single-purpose services; ideally each service is a complete application. Because microservices require additional human and compute resources, even lightweight ones incur higher costs. As your codebase grows, a well‑designed monolith can still be refactored into microservices when you approach the threshold.

2. Do you really need to scale each component of the application?

Imagine a product owner proposes using an HRMS application for an organization of tens of thousands. Your immediate solution might be a microservices architecture. One major advantage of microservices is the ease of scaling individual components, but you should ask whether your application truly requires such granular scaling.

3. Do your transactions span many services?

This is often the hardest strategic decision. Distributed transactions across services burden the architecture, leading to hard‑to‑track deadlocks and race conditions that can jeopardize service health and even engineers' well‑being. By definition, REST services are stateless and should not participate in multi‑service transactions. In high‑performance environments, two‑phase commit (2PC) adds unnecessary complexity, while the SAGA pattern introduces another layer of complexity you may not be prepared for.

Because microservices adopt decentralized data management, they bring eventual‑consistency challenges. A monolithic application can update many entities within a single transaction; microservices require multiple resources to update, and distributed transactions are generally undesirable, so developers must be aware of consistency issues.

4. Do services need to communicate frequently?

In a traditional monolith, modules interact in‑memory with near‑zero latency. Introducing microservices shifts communication to network calls, turning nanosecond latency into microseconds. Imagine three services each making a 100 µs network call; the total latency becomes 300 µs, which can be disastrous for real‑time data processing applications.

Beyond these four questions, other drawbacks of microservices include:

1. Complexity

While microservices aim to reduce complexity by breaking an application into small components, the deployment and maintenance of the architecture itself become complex.

2. Distribution cost

Microservices are modular distributed systems, but distribution incurs cost. A monolith can run on a few large VMs or containers, whereas microservices may require many VMs or containers, increasing overall expense.

3. DevOps adaptation

Establishing a dedicated DevOps team may be beneficial or harmful; small organizations might find the overhead outweighs the benefits, yet without a DevOps team, maintaining and monitoring microservices becomes difficult.

4. Tight integration

Some applications are inherently tightly coupled; separating them to fit a microservice architecture can be disastrous.

5. Lack of experience

Adopting any new technology requires expertise; with microservices, abstract definitions can cause significant pitfalls.

6. Chaotic data contracts

Defining data contracts within a team differs from sharing contracts across teams, especially when teams are distributed and use different programming languages, consuming time and effort.

7. Debugging

Each service generates its own logs; more services mean more log files to review.

These are the key considerations before adopting microservices. Feel free to share your thoughts in the comments.

Source: https://www.cnblogs.com/jackyfei/p/12344446.html