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
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
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 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.
These days using Cloud services (from AWS, Azure, Google) gives you such a broad toolset to create applications very quickly in the micro services approach with scalability out of the box. A monolithic approach in that situation doesn't make much sense.
The question really depends on the context of what you're building and its constraints on deployments.
Generally anything that is app and web related, monolithic approach is wasteful of your time and usually money for the reasons I mentioned in the first paragraph.
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.
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.