Stop blindly using microservices

Author | GreekDataGuy

Translated by | Sambodhi

Planning | Xin Xiaoliang

Why are most companies best off avoiding microservices? Microservices look like a good solution. Theoretically, microservices can speed up development while allowing you to scale different parts of your application independently. But in reality, microservices have hidden costs. That said, I don't think it's possible for you to understand how complex microservices are without building them yourself.

Here's what I learned when building microservices (and sometimes failing).

Managing data is a nightmare

Keeping data synchronized across microservices can be a challenge.

Each microservice has a database, which is the recommended pattern. It allows for loose coupling and allows specific service teams to work independently without slowing down their collaboration to share code. But what happens if one of the microservices that should have started synchronously fails? For example, one of the microservices updated its database, while the other did not. This situation can lead to data inconsistencies.

Based on personal experience, investigating data inconsistencies across services can be very painful. The cross-service nature of errors requires one person to work in different services to correct the errors. Unfortunately, this leads to the advantage of microservices, which are specific to teams, and don't work.

In a monolithic application, this can be easily avoided by merging two database calls into a single atomic transaction, so all insertions will succeed or will not succeed. It's very simple. However, loose coupling makes microservices more difficult to achieve.

Longer setup time

It takes much more time to build a microservices architecture than to incorporate the same features into a single application. Although a single service is very simple, the set of services that interact is far more complex than a single monolith. In a monolith, a function can call any other public function. However, functions in a microservice are limited to calling functions in the same microservice. This requires communication between services. It's not easy to build APIs or messaging to facilitate this. Moreover, code duplication across microservices is inevitable. While a single application can define one module at a time and import it multiple times, the microservice is its own application: modules and libraries must be defined in each module.

Microservices are best suited for large teams

The extravagant practice of assigning microservices to individual teams is left to large engineering departments. While this is a big advantage for this architecture, if you have enough engineers to assign a few for each service, then this is only feasible. Reducing the scope of the code allows developers to have a better understanding of the code and speeds up development. However, most startups don't have such luxury. In an early-stage company, some engineers had to work between all the services due to a lack of adequate resources. Unfortunately, doing so can reduce productivity because jumping between different apps can lead to changes in the environment. I find it very exhausting to investigate bugs in microservices that I haven't been following for a long time.

DevOps is more complex

One of the most compelling reasons to choose microservices is that you can run different services on different types of servers. Why? The memory, CPU, and startup time requirements of the React front end are very different from the services for training machine learning models. Choosing the right infrastructure type for each service can greatly reduce costs. However, it also presents a challenge for itself.

For example, early in my career, I lost a lot of production data by forgetting to restart a service with updated code. Out-of-date code receives data through the API, but instead of storing the data in the database, it fails silently. Such data will be lost forever.

I'm making this to show that configuring, maintaining, and monitoring multiple microservices is much more complex than a single monolithic application. Has multiple applications and adds multiple attack surfaces for hackers.

Theoretically, "loosely coupled" services allow each service to continue working if other services fail. But this is just wishful thinking: for complex businesses with customers, it's hard to achieve true loose coupling.

Ultimately, how reliable your application architecture is depends on the weakest parts. The more pieces of debris you move, the more likely you are to go wrong.

Summary

Many companies don't really need them when they use microservices, and while microservices are popular now, they're not for beginners. The best practice for most companies is to build a single body and then split parts of the single body into microservices when absolutely necessary.

Leave the opportunity to build a microservices architecture from scratch to the big tech companies with deep pockets.

Your early-stage startup may not be ready. My company wasn't ready, and as a result, we put in a lot of time and effort.

About the Author:

GreekDataGuy, developer.

https://betterprogramming.pub/stop-using-microservices-build-monoliths-instead-9eac180ac908