When to Use and When NOT to Use Microservices: No Silver Bullet

Published in

Design Microservices Architecture with Patterns & Principles

8 min readFeb 17, 2023

In this article, we are going to learn When to Use and When NOT to Use 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 When to Use Microservices Architecture ?

When to Use Microservices Architecture

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

Make Sure You Have a “Really Good Reason” for Implementing Microservices

Before starting with Microservices, you should check if your application can do without microservices. When your application requires high level of independent scalability and requires agility to time-to-market with zero-down time deployments and updated independently that needs more flexibility, then you should embrace the Microservices Architecture.

But the idea is that you have to Make Sure You Have a “Really Good Reason” for Implementing Microservices. Developers tend to focus too much on the latest technology tool for example microservices. Instead of that, Developers and Architects should consider the reasons why for implementation. And they should also focus on the result that the technology tools drive to achieve that results.

Iterate with Small Changes and Keep the Single-Process Monolith as Your “Default”

When we talked about Modular Monolithic Architecture, we saw that Sam Newman and Martin Fowler offers Monolithic-First approach. Because Modular Monolithic architecture also cover a lot of benefits of Microservices with avoiding lots of complexity of Microservices. Because a single-process monolithic application comes with a simple deployment topology.

Sam Newman and Martin Fowler offers Start With Small Changes and Keep the Single-Process Monolith as Your “Default”. They recommends that even they go to microservices, they should start with modular monolithic and simply refactor with turning a single module from the monolith into a microservice one by one and see how it works.

Required to Independently Deploy New Functionality with Zero Downtime

Then Microservices are extremely useful when an organization needs to make a change to functionality — and deploy that functionality without affecting rest of the system. This is the power of microservices and its allow to deploy new functionality without any downtime.

Independent Services: Each service can be deployed and updated independently, providing more flexibility. An error in a microservice, only has an effect on a specific service and does not affect the entire application. Also, adding new features to a microservice application is easier than a monolithic one. Whether the application is very large or very small, adding new features and maintaining existing code is easy. Because it is sufficient to make changes only within the relevant service.

Required to Independently Scale a Portion of Application

Also if your application is Required to Independently Scale a Portion of Application, then microservices are excellent choose for this kind of operations.

Better scalability: Each service can be scaled independently. Therefore, the entire application does not need to be scaled. This saves a lot of time and money. Additionally, every monolithic application has limits in terms of scalability. However, multiplexing a service with traffic on the microservice is less inconvenient and able to handle the whole load. This is why most projects that appeal to a large user base, have begun to adopt the microservice architecture.

Required to Data Partitioning with different Database Technologies

Also if your application is Required to Data Partitioning with different Database Technologies, Then Microservices are extremely useful when an organization needs to store and scale data with different use cases.

Technology Diversity: Teams do not have to completely choose the technologies on which the services will be developed, they can choose the appropriate technology for the services they will develop over time. For example, a service can be developed with the python programming language in order to use “machine learning” features next to microservices developed on .Net. The desired technology or database can be used for each microservice.

Required to Autonomous Teams with Organizational Upgrade

Also if your company Required to Autonomous Teams with Organizational Upgrade then microservices will help to evolve and upgrade your teams and organizations.

Organizations need to distribute responsibility into teams, where each team makes decisions and develops software autonomously. When teams need to work independently without close coordination, a microservices-based architecture provide that pushes this kind of autonomy within the organization.

When Not to Use Microservices — Anti-Patterns of Microservices

Here you can find list of reasons that you shouldn’t use Microservices Architectures: That means Anti-Patterns of Microservices:

Don’t do Distributed Monolith

Make sure that you decompose your services properly and respecting the decoupling rule like applying bounded context and business capabilities principles. Otherwise, you are losing the benefits microservices. Also make sure that services should be loosely coupling. If your services has chatty communication with strong coupling, you will end up with highly-coupled service architecture that means, you have developed a distributed monolith, which comes with none of the benefits microservices should bring.

Distributed Monolith is the worst case because you increase complexity of your architecture without getting any benefit of microservices. Microservices are all about autonomy. When you lost autonomy, teams must coordinate during development and deployment and teams will highly dependent each other. By time you will loose your agility of new feature deployments.

So if you end up with Distributed Monolith, application has a higher latency, can have synchronization issues, and is a lot harder to manage and debug. When something breaks, coupled services are hell to debug.

Don’t do microservices without DevOps or cloud services

Microservices are embrace the distributed cloud-native approaches. And you can only maximize benefits of microservices with following these cloud-native principles.

Some of these principles are

CI/CD pipeline with devops automations
Proper deployment and monitoring tools
Managed cloud services to support your infrastructure
Follow Key enabling technologies and tools like Containers, Docker, and Kubernetes.
Broke dependencies with following async communications using Messaging and event streaming services.

If you don’t follow these principles in microservices architecture, you will again end-up with Distributed Monolith which is the worst case because you increase complexity of your architecture without getting any benefit of microservices.

Limited Team sizes, Small Teams

If you don’t have a team size that cannot handle the microservice workloads, This will only result in the delay of delivery.

For a small team, a microservice architecture can be hard to justify, because team is required just to handle the deployment and management of the microservices themselves.

If your team size is good enough for those tasks, then it’s easier to justify but if one person out of your five-person team is spending their time on these issues, that’s a lot of valuable time not being spent building your product.

Brand new products or startups

If you are working on a new startup or brand new product which require significant change when developing and iterating your product, then you should not start with microservices. This kind of projects which's are pivot domain models so much, this will become to changes across service boundaries is an expensive way.

In general, I feel it’s more appropriate to wait until enough of the domain model has stabilized before moving the microservices. Because microservices are so expensive when you re-design your business domains. Thats why for startups its good to start with modular monolithic and when domain is stabilialized then go microservices step by step. For startups, it is not clear that even if you do become successful enough to require a highly scalable architecture.

The Shared Database anti-pattern

Yes, it’s possible to integrate a database for microservices. We can create a single shared database with each service accessing data using local ACID transactions. But if you’re seriously considering this, stop right there and think twice.

From Kelsey Hightower

Lets continue to a tweet thread from Kelsey Hightower.

https://twitter.com/kelseyhightower/status/1621184564956893189

Here you can see that Kelsey go one more step and offers that if we follow Modular Monolithic Architecture and build on Serverless and fully managed components, this would be prefect architecture most of software projects.

I also strongly agree with Kelsey for most of cases, but of course in some cases Microservices are un-avoidable chooses for large-scaled applications. The idea from Kelsey is that if you start with that setup, it can evolve and scale very easily for future requirements.

It is important to note that a Modular monolithic architecture is not a replacement for microservices architecture. Both approaches have their strengths and weaknesses, and the choice of architecture depends on the specific requirements of the system being built. A modular monolithic architecture can be a good starting point for a system that may eventually need to evolve into a microservices architecture as the system grows and complexity increases.

Design Modular Monolithic Architecture — E-Commerce App

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

According to architecture, we can encapsulate new feature developments into a module. And every module can implement its own architecture like Layered, Onion, Clean and so on.

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