This content originally appeared on Level Up Coding – Medium and was authored by Kit Isaev
If you google “benefits of microservice architecture”, you will, most likely, see one of the following statements:
- Microservice architecture helps with modularity, making the application easier to understand, develop, test, and become more resilient to architecture erosion. This benefit is often argued in comparison to the complexity of monolithic architectures.
- Microservice architecture parallelizes development by enabling small autonomous teams to develop their respective services independently.
Sounds pretty good, but unfortunately this is WRONG.
It’s not microservices that help you decouple your code, it’s interfaces. Microservices force you to create well defined, organized and isolated interfaces between different parts of your application. But you can have that without microservices.
All modern languages have built-in modularization features — modules, libraries, visibility modifiers, etc. Your can, and should, modularize your code. You may put building blocks of your app into separate codebases or even separate repositories as you see fit. It doesn’t automatically imply that you need to build multiple separate executables and have them communicate through HTTP or message queues.
Inter-process communication, especially across network, is complex. It introduces new issues to consider and new errors to handle. What if a backing service is down? What if there is a network issue? What if the services deployed are of different versions? How do you serialize and deserialize the information that you pass across the boundary? The bottom line is, don’t do IPC unless you literally have no other choice.
Instead of making an authorization service, a billing service, etc., consider making an authorization library and a billing library, from which a single executable is built.
So when is it a good idea to use microservices? In my opinion, there are actually only two valid reasons.
- When parts of your app use different tech stacks.
For example, your REST API service is written in Node.JS, because it is easy to find JS developers. But you also have machine learning features that are backed by a service written in Python, since Python has good ecosystem for ML stuff. A perfectly valid reason to have separate services.
Another example: you are migrating your app from one tech stack to another, and want to make the transition gradual. You have a legacy service written in Java, an updated service written in Kotlin, you are migrating API endpoints one by one, and have a gateway that routes the requests.
2. When parts of your app have vastly different runtime characteristics.
You have a REST API that follows the usual “stateless” request-response model. But you also have a WebSocket service that works with streams of realtime data. These services are quite heterogenous in nature, they roll out differently, they scale differently, they log different volumes of different data, etc. In this case, please do extract a separate service.
Let me know in the comments what you think about the microservice architecture, whether you feel that it’s often misused, and whether or not you agree with the points from this short article.
And if you want to see more posts like this, consider subscribing to my Telegram channel, Kit’s Guide to Software, where I share my thoughts on technical and business side of the software development industry: https://t.me/kitsguide
Stop using microservices for code organization was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding – Medium and was authored by Kit Isaev