Hacker News new | ask | show | jobs
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.

1 comments

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?

> 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."

Too much functionality in your XYZ class is not generally the problem. Its the dependencies between the classes and the way the frameworks (looking at you spring and hibernate) can make it too easy to couple your code via transactions, ORM graphs, etc.
All modern ides analyse dependencies. Spagheti is usually built when there are too many people working on one project. Microservices is to scale people, no need for microservices when your company has very few employees.