undefined | Better HN

0 pointsy4mi6y ago0 comments

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.

0 comments

eweise6y ago

Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

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?

asdfman1236y ago

> Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

Can we just create a Visual Studio extension that allows you to pretend the various components of your software are "microservices"?

"Sorry, you're trying to stuff too much functionality into your XYZ class. You'll need to break it off into another class if you want the Pseudo-Microservice plugin not to complain."

1 more reply

j / k navigate · click thread line to collapse