This debate ebbs and flows. How do you feel about it right now?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Create scalable and fault-tolerant microservices architecture
Neer S -
My 30-Day Kubernetes Learning Plan
Nilesh Raut -
2025 look ahead: Top dev events & courses for Android, React Native, and GenAI
Chris Trag -
How the new concepts of JSSugar and JS0 are able to slow down websites
antonmak1 -
Top comments (14)
Start with a Monolith, break into services when it starts to hurt.
Staying with a Monolith when it's causing you pain is bad.
Starting with Microservices without a good idea of where your pain will be is also bad.
As is usually the case, nuance is what's most important here. Both are great, and bad. Picking the right great, and bad, is totally subjective.
In general, for scale, logically breaking things into small-ish pieces is a great idea. Keeping their data isolated is also a great idea. Communicating between services asynchronously is yet another great idea.
Note that none of the above are owned entirely by the Microservices umbrella. You can do a lot of it without breaking your monolith up at all.
For context, my current situation: We need to rewrite and rearchitect a very large, and old, monolith. Here we already know what hurts from years of development experience, so we start with a good idea of what needs to sit in isolation. We also know that we have really ambitious delivery goals, a very large team of technologists (100+), and need teams and services to be able to work and deploy with as few dependencies as possible.
This is the type of situation the concept of Microservices was created to enable. So, like a cat on the internet, if I fits, I sits.
Such applause.
Got nothing to add to the debate. This opinion is better written than mine and covers everything I'd write
Well architected monoliths will work well than poorly architected microservices. If the underlying architecture is not good microservices might add overhead to team which do not need continuous change.
I like a lot how Next.js handles it, you create everything in a single project, your routes rendering an UI and your routes working as an API, then when you build for production you could have both:
This way you code as a monolith, but you could deploy as microservices, because working in a monolith is usually easier, everything is in the same folder, everything run with a single command and you don't need to think that much about network communication between them. But then in production being able to run every route (either UI or API) as a different service will let you scale them as needed individually.
Microservice mindset even when within a monolith.
In Rails, I build heavily on service classes with a singular job so that if the number of those jobs going through the system necessitates fanning out (using something like AWS Lambda), I haven't "coded myself into a corner".
Each comes with it's own set of problems. Neither is the best choice.
I feel microservices-first violates YAGNI. But monolith-first can result in a difficult to break up architecture when you do not keep attention.
I am not sure it’s just a choice between those two anymore. I feel it’s getting more blurry, and you have to include managed services.
The thing I have come to realize about micro services, is that most companies don’t actually seem to do a true microservice.
As I understand it, the microservice is suppose to be completely encapsulated. So more often than not, shared elements like legacy service, databases, etc get used between them. Now what you have is scalable architecture that still relies on mission critical resources that are not.
If you hosted an endpoint in a AWS lambda, you could have that scale to the cap of 1000 lambda instances being hot. But if they all connect to the same MySQL instance, your not really getting the benefit or the point.
I think the future is really just moving to managed services that scale. Cosmos SB, EdgeDb, and Fauna DB are available globally and scale for example. So it makes sense to put a globally deployed lambda in front of them instead of a single instance of MySQL in east-1.
I think monolith fell out of favor for a hot minute because of the scaling issue and dev experience. But I run monolith apps that horizontally scale. And it’s hard to say Rails is that bad dev experience.
The monoliths I want to avoid are those enterprise solutions from Oracle, IBM, and Adobe. Or ones that can’t scale due to session control, Li motions on databases, mainframes.
I do think JAMStack is going to be a large part of the future. If anything, because it moves more code to the edge of the cloud, and offers a level of stability and scale.
The best place to start is to determine where your project is headed.
You're trading simplicity for complexity, and those both carry costs beyond just uptime and stability.
Microservices will have a higher efficacy ceiling. But if you're building a to-do list app, you're unlikely to ever reach thay ceiling and you start to pay for your choice.
I believe that the smaller the big bits are the smaller the small bits will be. More bits makes for maintainable bits. But I suppose you could go to far and over split, this becomes prone to overengineering traps.
If your organization has a solid culture around CI/CD and a team providing a platform (e.g. Kubernetes, Cloud Foundry, OpenShift, etc.) to multiple development teams I think you can really see some benefits from microservices. They allow for independently scalable units and let different teams choose the development stack that makes the most sense for their app. Plus with service meshes like Istio or Linkerd a lot of the pain of wiring them all up is lessened.
If you are a solo dev or part of a small dev team then I'd stick with the monolith. I think you're less likely to see the benefits and have the organizational/platform support to operate them effectively.
There is no harm in having microservice infrastructure in place and you can start with the microservices that makes sense at this point. Don't try to decompose too much to consider future scenarios. You can always break them down at later stage.