What you read in this article:
Why are microservices a bad idea for many businesses?
I’m Arsalan Mirbozorgi. in theory, microservices may be the answer to all of your IT woes.
In theory, they can speed up your software development while letting you grow different aspects of it at different speeds.
Microservices, on the other hand, have hidden costs. However, I don’t think you can completely comprehend their complexity unless you make them yourself.
Here are some of the points I’ve learned about microservices through constructing (and occasionally failing) them.
Data Managing Is Nightmare
Data synchronization between microservices might be difficult.
The best practice is to have a database for each microservice. Service-specific teams can operate autonomously without stifling collaboration on a shared codebase.
But what happens if one of the two microservices that are scheduled to fire at the same time is unable to do its job? Even while one of these microservices refreshes its database on a regular basis, the other does not.
Situations like these can cause inconsistencies in data.
Data inconsistencies between systems might be a hassle to investigate, according to personal experience. To fix the mistake, a person must work across different services because it is cross-service in nature. As a result, microservices can no longer deliver on their original promise of providing services tailored to certain teams.
You could easily avoid this problem in monolithic software by putting both database calls in an atomic transaction, so either the inserts succeed or fail. It’s a cinch.
Loose connection, on the other hand, makes this more challenging with microservices.
Taking More Time to Set Up
It takes longer to implement a microservices architecture than to implement the same functionalities in a monolith.
However, the complexity of a set of services that interact is substantially more than that of equivalent monolithic service.
Public functions can be called from within a monolithic function and vice versa. In a microservice, on the other hand, you can only call functions within the same microservice.
This demands inter-service communication. Creating APIs or a message system to support this is not a simple task.
Additionally, there is no way to eliminate code duplication between microservices. An application’s modules and libraries must be defined for each microservice, whereas a monolithic application can define and import modules indiscriminately.
For large teams, microservices are the best option
Large technical departments have the luxury of delegating microservices to separate teams.
Even though it’s one of the architecture’s most promoted advantages, it’s only possible if you have enough engineers to devote to each service. Reducing the scope of a developer’s code allows them to comprehend their code better and improves their productivity.
But for most entrepreneurs, this isn’t an option.
As an early-stage company lacks resources, some engineers will be required to work on all services.
As a result, switching between programs can have a significant impact on productivity.
I found it exhausting to investigate bugs in microservices I hadn’t worked on in a while.
DevOps is far more challenging
The ability to execute different services on different types of servers is one of the most compelling reasons to use microservices.
Why? A React frontend can have vastly different memory, CPU, and uptime requirements than a service that trains machine learning models. Choosing the correct infrastructure for each service can save a significant amount of money.
However, it has its own set of obstacles.
If you’ve ever forgotten to restart the service after making code changes, you may have lost a lot of production data. The out-of-date code received data through API queries, but instead of saving it, it silently failed. That information is gone for good.
This is an example of why it’s more difficult to maintain, monitor, and configure several microservices than a single monolithic application. As a result, hackers have a wider range of options to attack.
Even if all of the other services fail, “loosely connected” services should be able to continue to operate. While it would be ideal, loose coupling is rarely attainable in a corporation with several consumers.
Ultimately, the strength of your software is only as strong as its weakest link. The greater the number of components, the greater the potential for inaccuracy.
Microservices are often used by firms that don’t actually need them. Although microservices have gained a lot of attention recently, they aren’t for the faint of heart.
Monolithic systems are better for most firms than microservices, which are better for some companies but not for others.
If you’re an established software company, don’t start from scratch with a microservices design.
Your startup is probably not ready for prime time. We wasted a lot of time and effort because mine wasn’t.