The Microservices Dilemma: When to Implement and When to Avoid

Microservices has become one of the most popular architectures for modern software, but are microservices always a good idea? This blog post will explore when microservices might be a bad idea and when microservices can be beneficial.

In the previous blog article, we get familiar with monolith and microservices architecture. We have seen that each architecture has some benefits as well as challenges. When considering the advantages and disadvantages of each architecture, it’s time to consider essential factors that you should consider before you choose microservices.

Why Might You Choose Microservices?

I can’t tell you what your company does or the goals it wants to achieve, but I know that many companies worldwide are using microservices for various reasons. I can outline the reasons why companies using microservices around the world. 

Team Autonomy

Missing autonomy is critical for a company’s ability to grow and scale. Many companies have shown the benefits of creating autonomous teams. Keeping organizational groups small and allowing them to work effectively has helped many companies grow and scale faster than their peers. Autonomy work at smaller and most modern companies. You should always be looking at how to improve team autonomy. Having the proper autonomy can help people to grow and get jobs faster. Distribution of responsibility can play out in many ways. 

The importance of knowing what responsibilities each team has and how they can work together to get the job done is critical. It’s not just about efficiently organizing tasks but also understanding that taking on some responsibility might be better suited for another person or group with strengths in different areas. That ensures that all available resources are used as effectively as possible, making everyone more productive. 

 To better manage the workload of a codebase, we have identified which areas need more attention and assigned them accordingly. Giving proper responsibility, e.g., Matt knows display slider best, so he is responsible for that. Steve knows how to optimize DB queries best, so he is responsible for that. When teams own microservices and have complete control over those services, they increase their autonomy within a larger organization.

Reduce Time to Market

One of the best benefits of microservices is that they allow for independent deployment, so you don't have to wait until coordinated releases. We can provide the functionality to our clients more quickly by creating and deploying microservices individually and without waiting for coordinated releases.

Scale Cost-Effectively for Load

Our processing can be scaled independently by dividing it down into independent microservices. That means we can have cost-effectively-scale. We can scale up only individual parts that are handling our load. It also follows that we can scale down those microservices under less load or even turn them off when not needed.

We add redundancy to our system by running many copies of your monolith, potentially behind a load balancer or another load distribution mechanism like a queue. By dispersing instances of our monolith across several failure planes (e.g., not having all computers in the same rack or data center), we may boost the robustness of our applications even further.

Figure 1 - Microservice organization

For example, for “Black Friday” customers will buy more products and most likely order and product services get under the load. You need to scale order and product services to handle that load. There are several ways to do it. 

Vertical 

Vertical scaling means adding more power to an existing machine. The machine for purchase order microservices gets more CPU and RAM.

Figure 2 - Microservice organization with vertical scaling

Horizontal

Horizontal scaling means adding more machines. Product microservice gets replicated into a different machine, providing the ability to support even heavier loads. With horizontal scaling load balancer should be adapted to route the request to the corresponding instance. 

Figure 3 - Microservice organization with horizontal scaling

Another great benefit with microservices is that you could replace technology with alternatives to handle a better load. Keep in mind that this is not a trivial undertaking. First, consider working on existing improvements and optimizations over to a new type of database or programming language. Reducing the impact of change as well as technology is more effortless. You may change the technology used only inside the one microservice that requires it, leaving the rest of the services unnotched. 

Improve Robustness

The move from single-tenant software to multi-tenant SaaS applications means the impact of outages can be more widespread. Softwares are used today more than ever before, support different countries, time zones, and many other complex tasks. By breaking our application into individual, independently deployable processes, we open up a host of mechanisms to improve the robustness of our applications.

Scale the Number of Developers

The adage of throwing more developers at a project to make it go faster is not the answer. Some problems, however, need an extra push from team members to get them done. 

One significant product domain gets decoupled into subdomains. Each subdomain may have an independent team responsible for the entire lifecycle of the product, from development to deployment. Based on the business functionality of each subdomain, we can scale the number of devs. For example, product service has more business functionality, and we need three team members while user service needs only one member.

Figure 4 - Team organization with microservices

With clearly identified boundaries, each boundary can own a team. One significant product will be divided into small subdomains where each subdomain can own a team. Consist that some boundaries are more complex and require a bigger team, we can scale the number of developers based on domain complexity. For example:

That is important to follow Agile and DevOps methodologies because each one with different skills learns how to work together on the same product.

Even teams are independent; microservices will end up communicating with each other. It means you still need to manage integration between the teams at a certain point in time. Services need to communicate between, and team members have some communication. Each service might have its own version control system, such as Git.

Embrace New Technology

Monoliths typically limit our technology. Usually, we have one programming language on the backend with fixed to one deployment platform, one operating system, and one type of database. 

We gain the flexibility to choose those options for each service with a microservice architecture. One service boundary can have the benefit of technology isolation as an example, report DB. You can have a microservice architecture that contains individual services written using various programming languages and tool kits.

When Might Microservices Be a Bad Idea?

There are many benefits that microservice architectures bring, but I don’t recommend microservices in a few situations. Let’s take a look at some of those situations.

Unclear domain

You have domain model unclear results in frequent changes to the models and aggregates. It can lead to the wrong identification of service boundaries and a more significant number of cross-services changes, which can be very expensive. Considering that each service is a hosted-CI solution, each change leads to a high cost and ownership. A monolith is a much better choice if you don’t have a clear domain. If you want to decompose an existing codebase into microservices is much easier than trying to go to microservices from the beginning.

Startups

It might sound controversial as many companies considered as startup companies are famous for their use of microservices. It’s important to highlight that many of those companies, including Netflix, Airbnb moved to microservice architecture only later in their evolution. 

Startups often experimenting with various ideas in an attempt to find customers. In that journey, many times, they have to change the original vision of their product. Adapting your product to your customers requires huge changes in the product domain. It requires considerable changes to services boundaries that are original design. As mentioned, it can cause many cross services changes. It’s easier, faster, and less expensive to do changes in monolith architecture. 

Your customers don’t know which architecture you are using. Your focus should be on being a success! When you establish the fundamentals of your product and the right market, it’s easier to do decomposition into microservices. When you reach the point that your product runs, a market is established, and cash-flow, it’s time to think about how you take “scale-ups“ advantage of the microservice architecture. 

I’m not saying never do microservices for startups, but those are factors that you should consider.

Boundaries that are clear at the beginning you could split and keep the rest on the more monolithic side. You will be able to identify your operation capacity like; if you struggle to manage two services, managing ten will be more difficult. 

Customer-Installed and Managed Software

If you want to create software that is packaged for customers who then install and manage it, then microservices may not be the best choice.

Usually, customer-installed software targets a specific version. Targeting one environment such as Windows Server or Linux is well understood by people who manage these systems. You should consider customer skills and size. It might be difficult if they need to run and manage 10 or 20 processes. Managing and monitoring those processes may be an issue for customers. Considering that some companies have required skills but the company is not large enough to manage those services.

If your software run on a Kubernetes cluster, or each process uses a different technology? Most customers are not ready to obtain those skills and technologies. 

It’s easier to run and manage a single process, so monolith architecture is preferred in customer-installed software. 

Not Having a Good Reason!

Assuming that “If microservices are good for Amazon, they’re good for us!” that is the biggest reason why you should avoid microservices. 

You must have a clear vision and goals and what you are trying to achieve. You should closely identify which benefit you can adapt from microservices. 

Conclusion

When you’re considering how to scale your engineering team, the size of your application, or both, it may be time for a new approach. Microservices allow teams to work independently and iteratively with each other in order to build better software while maintaining high levels of robustness. 

The advantages that microservices bring come with a cost, and that is complexity. Microservices are much more complex than monolithic, which creates many challenges that must be overcome for a microservices implementation to deliver more value. Developing microservices, running them in production, and maintain them over time is hard.