The Issues of Microservices

The Issues

Microservices probably do not need much introduction anymore; it has emerged as a phenomenon in recent years. Microservices is a software development technique that structures an application as a collection of loosely coupled services. In contrast to Microservices is Monolithic, where all components of the application are placed together into a unified entity.

In my time, or perhaps many of the predecessors who were primarily exposed to Monolithic. If you, dear reader, are not aware, I used to be a PHP developer. PHP has many frameworks, which are organized in a way that places all application processing logic within them. One project is enough. After modifying, uploading it to Hosting means the update takes effect immediately.

When I interned at a company in the role of JavaScript, I participated in many real projects and was quite surprised to see that applications were no longer simply deployed in one step as before; instead, they contained discrete pieces from many parts that constituted the system. Each component communicated with each other through some means, such as calling APIs or listening to Message Queues. Upon deeper investigation, I realized this was an architectural approach with a hint of Microservices.

Modern Microservices. That is true. I have absorbed the philosophy of Microservices to make your system as loose as possible. Any component can be separated and replaced with another component. Each piece handles a single task, existing independently of one another, making the system more transparent than ever.

Later, when I switched companies, most were young enterprises, also known as Startups. This architectural style remained popular. From then on, I had more exposure. Gradually, I pondered, if Microservices were born, why was Monolithic created? Isn't a clear architecture like Microservices supposed to have defeated Monolithic right now, at this moment? Microservices are flushing away the sluggishness of Monolithic.

Until one day...

That was when I began building a blog for myself. What do you think would happen if a helper had bricks and mortar in hand, preparing to build his first house for himself? The only thing he surely lacked is experience. After building the blog with Microservices architecture, followed by the process of tearing down and rebuilding in Monolithic style, I felt like I slapped myself in the face for those bold statements above, realizing a truth that Microservices is not a silver bullet.

In this article, I will recount to the readers my dark period of applying Microservices to my personal project. Of course, this does not equate to saying Microservices is bad. It is only bad when it hinders the operation process. I hope through this article, readers will envision the message I want to convey and I look forward to receiving appropriate advice.

From Monolithic to Microservices

To build an application with Microservices architecture, in summary, it means separating processing logic components into distinct blocks wherever possible. Deploy them by any means, any language, and have them communicate with each other through some means, such as HTTP, gRPC, Webhook...

The system I built is divided into many small components. Among them, there are the blog interface (page), admin page (admincp), API, an image management service (image), a background task processing service (background), and a few other bits I can't quite remember. The components primarily communicate with each other through REST APIs. You know, after completing everything, I placed them all on the same server, in Docker containers. Somehow, it sounds like Microservices but is very Monolithic.

In the operation process, the most visible advantage is transparency. The components are distinctly separated, making it easy to recognize or add features. However, after doing it for long enough, the horrific truth gradually revealed itself.

Firstly, the debugging process is extremely difficult. The connections between the loosely coupled systems are dependent on one another. If during the debugging process, you suspect any section, which component is most likely to be faulty, you are forced to reconnect them to recreate the error. In other words, you need to prepare all services, start them together to begin. Repeat this process continuously between services until the error is found.

Secondly, there is the issue of tracing. Many people will think the best way is to log the system. But managing logs is a task in a different realm. You need to manage that pile of logs and know how to connect them back together to find valuable information. Otherwise, everything only resembles a placebo. Just recording everything that happens without knowing how to detect them. If later on, as the data increases, many other issues arise, such as storage and garbage.

Managing these services is not easy with limited human resources. If the system has 2 services, it’s not a problem. But later, it expands to 3, 4, 5... even up to dozens of services, what will that story be like? Imagine the daily tasks you do on a project? From managing source code, documentation, versions, dependencies... to the CI/CD process, deployment. All that work multiplies according to the number of projects you have. Believe me, it feels like a nightmare.

One more point is that it is more complex than necessary. Avoid falling into the trap of having everything perfect from the start. Design a system appropriate to the current situation rather than to bear the load of millions of users simultaneously, while in reality we don't even have 100 views daily. Face the truth and don’t add more burden to yourself.

From Microservices to Monolithic

For the above reasons, I decided to tear down and rebuild my blog after many contemplations. Combining everything I had into a unified block, as if it were Monolithic. Indeed, this was the wisest decision I could have made earlier.

Monolithic proves to be reasonable for personal operation, and I think it is also suitable for a small team. Now I only need to focus on a single project. Easy to debug, easy to trace, and no more time wasted managing projects exponentially. Thus, it shows Microservices is not a silver bullet, and Monolithic is a more suitable solution in this context.

Tearing down and rebuilding the blog is a time-consuming process. Many may think that organizing under Microservices previously was a waste of time, but for me, it was a valuable period to draw many lessons. One of them is to recognize the pros and cons of Microservices.

In conclusion

Microservices is a modern software development technique, but it is not for everyone. Developing applications in this architectural style requires a lot of operational effort, system control. Otherwise, you won’t truly know what is happening inside your application. If you are alone or in a small team, consider switching to Monolithic - traditional, simple, and accessible.

Moreover, I believe there are still many people who know how to operate their microservices systems. Please share your story in the comments for me and everyone to know. Thank you.