Micro-services or Monolith – One Question can Help
Photo Credit: Sandra Strait
Like any other programming fad, the tide has begun to turn against micro-services. In the last 6 months I’ve read post after post after post decrying them.
Like anything else, they have plusses and minuses. Certain problems call for them while others don’t.
Usually it’s a warning sign if your team is always choosing micro-services or always choosing monoliths. In either case, your organization might be the victim of dogma. People have lost their ability to think critically.
Assuming your team isn’t choosing one or the other arbitrarily, I’ve found a question that helps determine whether to split a piece of functionality into a micro-service:
Should this code be deployed separately?
- If the code is tightly coupled to the larger application, the answer will usually be ‘no’.
- Otherwise yes.
After all, the advantage of micro-services is that you can deploy all the parts of your application independently. But if those parts are tightly coupled what’s the point? You’re needlessly complicating your architecture and possibly introducing bugs if you split things out when there are many interdependencies.
If you go from a monolith to 2 or 3 tightly coupled services, you risk breaking any of the dependent services whenever you deploy any of them.
Also remember that every time you spin up a new service you pay the cost of deploying a brand new application. You might have to spin up a new production machine, write new deploy scripts, deal with authentication separately, or harden the production environment for security.
In addition, micro-services are usually stored in their own code repositories. This can be a hassle, depending on how you develop code. I find it annoying to have to pull down another code repository just to see the implementation of a 10 line function. And if I make any changes, I now have to open 2 pull requests instead of one.
Anyway, all of the costs of a new micro-service make sense if you need the ability to deploy that piece of functionality separately. If it’s completely unrelated to the original application, and you were only keeping the code in the same place for convenience, then it might make sense to split it out.