|
|
|
|
|
by y4mi
2438 days ago
|
|
Microservices are for scaling development teams. They're not inherently better to maintain. You just can't reliably work on one artifact with dozens of people without creating a lot of complexity, this is why microservice architectures can be better in some cases. If you're not going to increase the development team beyond a single smallish group of people, you'll be much more productive and your service will be way faster as a monolith. I'm pretty sure most SaaS companies want to scale their development teams, so it's basically a given that most want to use microservices as well. |
|
Sounds like you are arguing that for small teams a monolith is better. No one would argue that they are not. If you read my post, I talked about business that become a SUCCESS meaning that they grow beyond that initial small team. Once your team becomes large, if you started with a monolith, you will eventually need to either break it apart into microservices or try to manage the monolith across many teams.
IF microservices could be as easy to develop from day 1 as a monolith, why would you start with a monolith? Isn't that what technologies like Dapr are trying to do? Make developing microservices easier?