Hacker News Reader

Comment by strken | Hacker News Reader

Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team.

It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit to doing so, however. The technical founder and the one engineer are hardly going to block each other.

View on HN

"Big companies mostly seem to use the microservice(s) per team model. "

I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.

I've seen a startup with 10 devs + 60+ microservices and growing.

The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.

Been there before - I worked at a company where some geniuses thought that microservices would solve all of our scaling issues. We ended up with four microservices just to send an email (one to template, one to send, one to persist to database and one other which I can't remember now).

That sounds like like they could just have used AWS Lambda instead of microservices.

This was all on-prem stuff. But it was taken to ridiculous extremes. I've worked on something that was a knot of message queues but there was one email service.

Multiple services using the same database will typically end poorly. When schemas or indexes change, how will that affect all of the different services? How do their read/write patterns differ? When one service needs to scale, will the additional connections starve the other services? And worse, if a service ends up moving to a different team or department, who controls the database?

I prefer a service that fronts the database. Swap the database, scale it, whatever, and clients keep going.

"When schemas or indexes change, how will that affect all of the different services? "

It's absolutely horrible. Now all the services are tightly coupled without the devs really realizing this. And the side effects of database changes can be super subtle and hard to predict.

Microservices are a solution to business/team organizational issues. Never technical ones.

I think the example I gave is a good counterpoint:

- you have a monolith, and it handles normal API traffic patterns

- you have a workload that involves different hardware needs e.g. extremely high throughput relative to the rest of the system (video streaming would be an example), GPUs, high memory requirements with low CPU or vice versa, etc.

Solution is to deploy a service that only handles the specific workload. Whether or not this is a microservice probably depends on your point of view but I'd argue it's at least close.

Reply on news.ycombinator.com