Recently, I have read some articles and books on microservices and how they may promise better results than monoliths regarding availability, network, scale, and management. All I understand, which I believe is fundamental to all these new architectures, is how you and your team maintain a code base, not in terms of “Clean Code,” but how you figure out that these many functionalities should belong to this or that module or component. It is a great observation to make when you finally understand that scaling is not always the solution to every problem that runs on a server and communicates via the network.
It is not trivial to convince people in tech that you may not have to rewrite the whole system because it is not coping with the traffic or the input. Start looking for places where you are doing expensive computes, and the logic may need some refactoring this time to get the same results. I have seen this in many projects where some pieces of code work as duct tape and now when we bring the whole system to play in the field, the tape is starting to widen open sooner or later. And I get it that sometimes, because of time constraints, or you don’t understand the fundamentals of the language and are not interested in it, or it was your last day at the company, or you don’t understand outcomes from a feature that is expected, whatever it may be, you did what you did. Still, now that is going to serve the people you don’t even know.
Now coming back to it, the first approach everyone should take is to build the monolithic system more modular and define the boundaries for each module in such a way that you know when something is off where you should be looking. Second, understand the process of every module and compare their performance after doing some fixes and removing those nested loops or recursive calls and throwing some caching in it, try reducing multiple database calls by doing many more optimized queries, making high compute operations asynchronous, split the operations, and etc. After that, if you still have problems, go ahead and pick one module that is having performance issues and fewer dependencies and start building the microservice by just replicating it and using a message broker like Kafka to communicate with the dependencies of the old system for that service to produce and consume the message triggered by some event asynchronously and observe the new microservice if it is working as expected. By doing so, you are having the same service working in both systems; this gives you insight into how performant the microservice will be, and not break the existing system by bringing a foreign architecture with no knowledge of where and when it may start showing some grey areas.
Building software is always about numbers, assumptions, precedence, resources, and rewrites. A microservice for a startup company where the number of people working on the software is fewer than 50 is not a very good choice. If you are doing this, then it is a clear sign that you don’t understand what the goal of the software is and how to use the resources you have. You are either exploiting the resources you have just because you can or you read an article about how monoliths can bring you unforeseen troubles. In any case, you are always responsible for every duct tape to every exploit.
In my conclusion, I can only state, build everything as simply as possible and this comes with failing experiences and not by writing more code the same way every time. State the boundaries very carefully and adhere to those to keep the parts and pieces decoupled as much as possible while doing the job they are responsible for. Read and watch people building software still alive for more than 10 years, because they may share some opinions that can be hard to digest but they have experienced the worst you could ever imagine (a world without AWS or Cloudflare). I like the benefits of monoliths and microservices and I can use both if I have to that gives me more control over making future decisions which is always the case in building software where people lose control and may get sidetracked.
So in the end, it is all up to the understanding, the ego, and the satisfaction, since we are human in the end and we have feelings. Every wrong decision is a step towards upskilling.
Good luck!
