Reasons to avoid monoliths
If you already have a single server that includes all backend features, you have a monolithic service, even if you start two or more instances of this service. A monolithic service has a few disadvantages it is impossible to scale vertically, it is impossible to update and deploy one feature without interrupting all the running instances, and if the server fails, it affects all features. Let’s discuss these disadvantages a little further. This might help you to convince your manager to break your service down into microservices.
Impossible to update and deploy only one feature
If your backend works as a monolith, you can’t update only a small part of it. Every time you add or change a feature, you have to stop, update, and start the service again, which causes interruptions. When you have a microservice and you have find a bug, you can stop and update only this microservice without affecting the others. As I mentioned before, it can also be useful to split a product into separate development teams.
The failure of one server affects all features
Another reason to avoid monoliths is that every server crash also crashes all of the features, which causes the application to stop working completely, even though not every feature is needed for it to work. If your application can’t load new user interface themes, the error is not critical, as long as you don’t work in the fashion or design industry, and your application should still be able to provide the vital functions to users. If you split your monolith into independent microservices, you will reduce the impact of crashes.