Microservices are all the rage these days. But does your startup really need them? Most likely not, says Adam Drake over on his blog. They should only be used when your monolith gets so complex making the app just more modular won’ t cut it.
Microservices are all the rage these days. But does your startup really need them? Most likely not, says Adam Drake over on his blog. They should only be used when your monolith gets so complex making the app just more modular won’ t cut it.
Microservices are praised for decoupling systems and pursued because the tech giants like Uber and Twitter use them. They might need them, argues Adam, but you probably don’ t. Microservices come with problems and your app will have to be pretty huge and complex to tip the balance in their favor.
Adam examines the typical reasons for favoring microservices and finds them wanting. The two most common are: to remove dependencies between teams and make scaling easier. It’s true as startups grow separate teams form and this results in merge conflicts. The junior devs who work in these companies then think microservices are the answer. Adam stresses that the problem is more a communication/coordination problem than a technical one. Better organised teams and more modular code could solve the issue just as well. These guys are confusing decoupling with distribution. Scaling can be solved too in a much simpler way. You could just deploy several copies of your monolith behind a load balancer.
The key question to ask before you leap is: are you ready for microservices? Your team should have the ability to quickly provision, monitor and deploy your current systems before even considering the move. So, with provisioning, if you have only a couple of team members who can provision new services, you’ re not ready. You’ ll also need close familiarity with your system metrics (e.g. CPU, RAM) app metrics (e.g. latency, errors per endpoint) to understand how your systems perform. Lastly, for deployment, if you don’ t have a good continuous integration and deployment process in place, how are you going to manage deploying microservices?
Even if you meet these requirements, hold your horses. Adam recommends considering the downsides. First, the overhead: many startups lose time managing complex ops tooling instead of building features. Two, app performance can go down as well as up if the network delay between machines running different services is an issue. Local development and scaling can also be a pain with microservices.
So what do you do if you have problems with your monolith but microservices are not the answer? Adam recommends cleaning up your app, refactoring it into well-defined modules with simple APIs. You can then try creating a new app out of one module and putting it on a separate hosting system and finally giving it responsibility for its own data. But in most cases, Adam says, you don’ t even need to go that far.
