Reminder: Microservices are not a free lunch
We see more and more organization moving their traditional monolithic application to microservices architecture. Like every trending thing, microservices architecture is being misused. Everyone wants to use microservices, I have literally seen people using microservices that can easily be handled by the monolith. I am not saying microservices are bad, they are really good and they bring a lot of nice things with them. On the other hand, microservices also introduce more complexity to your system. Today, let us explore together the scenarios where microservices may not be a good choice.
You are just Getting Started.
If you are just building your startup and maybe you just have 2 or 3 people in your team, then using microservices maybe is not a good idea. Microservices require extra effort, and those extra efforts can significantly slow your team. For deploying in production, microservices also require a lot of automation, you will have to develop some sort of platform which will do all of deploying for you. In simple monolith applications, it's way easier to deploy applications. Honestly, if you will carefully design your application by paying a lot of attention to modularity then it will be way too easy to switch to microservices architecture when the time will be right.
Even though now we have some off-the-shelve CI/CD pipelines available like one being offered by AWS. Again they also add more complexity to your system and every complexity to your system will push your release date back by many weeks. You should honestly ask when starting up: are microservices worth it at this time for this project?
Simple Application.
Let’s say you are designing a simple application that may never require to be scaled and there is also no complex business involved. In such cases using microservices is a bit of overkill. You will spend a lot of precious time building microservice and preparing some sort of platform to deploy them. What is the point of wasting so much time when it will never be used at the scale microservices are intended to? Also, Microservices architecture requires some extra resources to exist. If your application is simple enough then maybe extra resources required because of the introduction of microservice architecture can even exceed resources required by the application itself.
Let’s say you are creating an application for keeping data of students studying in a college. Now, do you really think you will need that scalability of microservice architecture? I don’t think so. Also, not all applications are large enough to be broken down into smaller services and in such cases, microservices architecture shouldn’t be used.
Not enough Microservice Experience.
Microservices only work when they are designed well. If microservices are not designed properly they can easily backfire. There are a lot of books written about how a microservice should be designed. Still, people make a lot of mistakes when designing microservices. Not only design but a lot of skills are also required when developing microservice. Developers should be production aware as well as should know about operations also. Developers just can't throw anything over to the operation team to deploy on production.
If even one of the developers was not enough skillful then it won't slow down just 1 microservice but it will have a ripple effect around the entire application. It's also true most developers love learning new things but it's not true for all. It also takes time and effort to learn microservices architecture and management should be aware that there can be some big mistakes in the first version of the application. Sometimes mistakes are so big that you have to start from scratch. Management should give enough space to developers to do their job and if they can’t then microservice architecture isn’t for you.
Fail often. Fail early. Fail fast. Embracing failure is a means to a successful end. Instead of fearing failure, become empowered by it.
Gary Burnison, CEO of Korn Ferry
Management should know the risk, and if they are not willing to take it then don't use Microservices.
Trying Something New.
If you are building an application on some idea and you really don't have much trust in that idea. In such cases nearly always using microservices is a bad idea. You really don't want to add a lot of complexity to the solution, you will just want to create a simple application that will test your idea. If your idea works then maybe you can switch to microservice architecture later on. In case you are building a simple application to test your idea, it's really important to launch your application as soon as possible. The microservice architecture will just slow you down.
And not only this microservice are harder to debug and testing is also not simple. When you break a monolith application, communication costs between different services will also increase, increasing latency. If your application requires updating multiple resources across services frequently then it can cause a lot of issues in the microservice world; as you would be using something like a SAGA pattern which will just introduce more complexity.
Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single transaction. Microservices require multiple resources to update, and distributed transactions are frowned on (for good reason). So now, developers need to be aware of consistency issues, and figure out how to detect when things are out of sync before doing anything the code will regret — Martin Fowler.
If your application doesn’t need such complexities then these should be avoided as much as possible.
Conclusion.
Microservices bring a lot of good things to your organization but before adopting them one should also be aware that they also bring some new complexity. One should also remember that maybe organizations like Netflix and Uber become successful because they could scale enough because of microservice architecture but they also didn’t perfect it in a single day. Companies like Netflix and Uber have gone through various iteration of improving their microservice and they also started from monolith only.
Just because your application is using all the latest technologies doesn’t make your application good. If you can do a task with a simple shell script in a few lines of code then it isn’t necessary to write an application in the spring batch because it is cool. Your application will only be good if your application is functioning as intended and doing this by using only resources which are needed. Developers shouldn't forget the basic principles of any software design: YAGNI and KISS.
Last but not least one should always keep learning all those new technologies because you don't know when you have to use those technologies to make your life easier.
