Benefits and Challenges of Microservices Architecture: Double-edged sword

Published in

Design Microservices Architecture with Patterns & Principles

8 min readFeb 17, 2023

In this article, we are going to learn Benefits and Challenges of Microservices Architecture.

By this article, we are going to understand the best use cases of Microservices Architecture and Design our E-Commerce application with Microservices Architecture.

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

Microservices Architecture

Microservices are an architectural approach to building and deploying software applications that involves breaking down an application into smaller, independent services that can be developed, deployed, and maintained separately. While there are many benefits to using microservices, there are also some challenges that need to be considered.

So what is the Strengths — Benefits — Advantages of the Monolithic Architecture ?

Benefits of Microservices Architecture

Here you can find list of benefits about using Microservices Architectures:

Agility, Innovation and Time-to-market

Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features. Since microservices are smaller and independently deployable, it’s easier to manage bug fixes and feature releases.

You can update a service without re-deploying the entire application, and roll-back an update if something goes wrong. In monolithic applications, if a bug is found in one part of the application, it can block the entire release process. So new features was waiting for a bug fix to be integrated, tested, and published.

Flexible Scalability

Microservices can be scaled independently, so you scale out sub-services that require less resources, without scaling out the entire application. So we can say that, microservices require less infrastructure than monolithic applications because they enable precise scaling of only the required services, instead of scaling the entire application.

Also scaling is very easy with using an container orchestrator tool like Kubernetes, you can pack a higher volume of services onto a single host, which allows for more efficient utilize of hardware resources.

Small, focused teams

Microservice should be small enough that a single feature team can build, test, and deploy it. The microservices model enables an organization to create small, cross functional teams around one service or a collection of services and have them operate in an agile fashion. Small team sizes increase the agility. Large teams tend be less productive, due to communication is slower and management overhead goes up So that occurs the agility diminishes.

Small and separated code base

In a monolithic application, The code base is going to be so bigger over time for code dependencies to become tangled. Try to Adding a new feature requires lots of refactoring on existing code base. Since microservices are not sharing code or data stores with other services, it minimizes dependencies, and that makes easier to adding new features.

Easy Deployment

Microservices enable continuous integration and continuous delivery, making it easy to try out new ideas and to roll back if something doesn’t work. The low cost of failure enables experimentation, makes it easier to update code, and accelerates time-to-market for new features.

Technology agnostic, Right tool for the job

In traditional layered architectures, an application typically shares a common stack, with a large relational database supporting the entire application. This approach has several challenges for example every component of an application must share a common stack, data model and database even if there is a clear, better tool for the job for certain modules. It’s really frustrating for developers who are aware that a better, more efficient way to build these components is available. Also developers is frustrating when the application stack is too old and can’t apply new best practices on their projects.

But in microservices architecture, small teams can pick the technology that best fits their microservice and using a mix of technology stacks on their services. Because of microservices are deployed independently and communicate over some combination of REST, event streaming and message brokers. It’s possible for the stack of every individual service to be optimized for that service. Technology changes all the time, development libraries and tools also evolving very fast so since an application composed of multiple, smaller services, it is much easier and less expensive to evolve with more desirable technology into microservices.

Resilience and Fault isolation

Microservices are loose coupling also builds with fault isolation and better resilience into applications. If one of your microservice becomes unavailable, it won’t affect the entire application. Of course you should design your microservices are fault toleranced and handle faults correctly for example by implementing retry and circuit breaking patterns. Even failures happened, if you fix that failures without any business affect, you customer will always happy.

Data isolation

Since microservices following the database-per-service patterns, databases are separated with each other according to microservices design. So it gets easier to perform schema updates, because only a single database is affected. In a monolithic application, schema updates can become very challenging, and risky.

As you can see that we have seen lots of Benefits of microservices, so now its time to see challenges of microservices architecture.

Challenges of Microservices Architecture

Microservices has significant benefits but also has significant challenges. Moving from monolith to microservices means a lot more management complexity. Here are some of the challenges we need to consider before applying to microservices architecture.

Complexity

Microservices application has lots of services need to work together and should create a value. Since there are lots of services, that means there is more moving parts than the monolithic application. Each service is simpler, but the entire system is more complex. Even deployments can be complicated for hundreds of services deploy different times hard to manage versions.

Distributed System

Microservices are a distributed system, which means that they have many moving parts that need to be managed and coordinated. This can make it more difficult to ensure that the system is working as expected. Think about the communication. Its really easy to communicate components in monolithic application because it is inter-process communication, can be the same machine and same process. But microservices communication is hard topic and need to have a strategy to manage inter-service communications between server even different geo-locations.

Network problems and latency

So since microservice are small and communicate with inter-service communication, we should manage network problems. If we call chain of services for particular request, this will increase latency problems and need correct design to APIs for proper communication. In order to avoid chatty API calls. You need to consider asynchronous communication patterns like message broker systems.

Development and testing

Think about the E2E process one of the long business requirement. If the requirement touch on several microservices that need to act as a 1 application, its hard to develop and testing these E2E processes in microservices architectures if we compare to monolithic ones. Existing tools are not always designed to work with service dependencies. Refactoring across service boundaries can be difficult. So that means Integration testing, as well as end-to-end testing, can become more difficult, and more important than ever.

Data integrity

Microservice has its own data persistence. So data consistency can be a challenge. Mostly we should follow eventual consistency where possible. But transactional operations are always will be challenging.

Deployment

Deployments also a challenge, at least in initial set up. In order to make deployment easier, you must first invest in quite a lot of devops automation processes and tools. Because the complexity of microservices becomes overwhelming for human deployment. Think about how you’re going to roll services out and in what order.

Logging & Monitoring

With distributed systems, you need centralized logs to bring everything together. Otherwise, the scale is impossible to manage. It’s critical to have a centralized view of the system to monitor sources of problems.

Debugging

Remote debugging through your local integrated development environment (IDE) isn’t an option and it won’t work across dozens or hundreds of services. Unfortunately there’s no single answer to how to debug at this time.

Nevertheless, these challenges aren’t stopping to adopting microservices. Most of the organizations accept these challenges and adapting their technologies to microservices architecture in order to get benefits of this architecture.

Monolithic or Microservices Architecture ?

The choice between monolithic and microservices architecture is a common question in software architecture because it is a fundamental decision that affects the design, development, and maintenance of a software system.

For that reason its good to hear from experts on Software Industry.

From Chris Richardson

Let me continue with tweet from Chris Richardson:

As you can see that he is pointing out that there is no perfect architecture and all architecture styles are a architecture pattern and non of them better than other.

From DHH

Lets continue to another tweet from DHH.

The Majestic Monolith — Signal v. Noise (signalvnoise.com)

Here you can see that DHH and Kelsey agree with Monolithic architecture is still very valid architecture in 2020s. So that means we should consider Monolithic architecture as the same level with Microservices architecture when we design our applications.

The main idea is here, we must pick the architecture that satisfies your application’s non-functional requirements, like scalability, availability and so on. Yes everyone wants to design high scalable and high available systems but as an software architect you should focus on problem and ask yourself

Is it required for your application ?

To avoid unnecessary cost and resource usage and to avoid over-engineering of that problem. Because when you apply advanced architecture for your small problem, you did anti-pattern implementation and loose benefits of your application nature like easy to develop , debug and deploy options and so on.

Design Monolithic Architecture — E-Commerce App

If we design e-commerce application with Monolithic architecture, you can see the image below:

There is a big single Monolithic Application Server and one big relational databases.

Design Microservice Architecture — E-Commerce App

If we design e-commerce application with Microservice architecture, you can see the image below:

Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.

What’s Next ?

Step by Step Design Architectures w/ Course