[siliconc0w]

The biggest wins for microservices aren't really technical, they're organizational. They force you to break a problem down and allow each team to own a piece of it, including end to end delivery. This allows specialization of labor which is a key driver of productivity - including an ability to experiment and innovate. Every change is incremental by default, and well-documented external APIs are the only way to talk to other domains- no shared databases, filesystems, or internal APIs. It's not free and definitely takes some discipline and tooling to enforce shared standards (every service should have metrics, logging, tracing, discovery, testing, CI/CD, etc) but you'd need to build that muscle with a monolith as well.

[utmb748]

Could kept infra as a code, logging, auth and so on in packages, gRPC or message queues for communication, telemetry, monitoring/alerts and more stuff as a code too... got to the point creating new service was just new repo, name, port a resource utilization.

Agree with organizational win, also smaller merge requests in the team were superb.

Around 5-10 devs, monolith, we ran into conflicts more often, deployment, bigger merge requests, releasing by feature was problematic, microservices made team more productive, but rules about tests/docs/endpoints/code were important.

[frollogaston]

The DB part can also get technical as performance comes into play. Most startups are probably not encountering this problem, but they could.

[no_wizard]

This may explain some of the popularity resurgence of SQLite (including distributed SQLite)

It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.

[frollogaston]

Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.

[mdaniel]

It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance

Compare:

  psql --host=team1.example -d team1
  # versus
  psql --host=the-db.example -d team1

Sometimes one can get away with schema level split, which can allow cross schema references in a read only setup, but carries coupling concerns

  psql --host=the-db.example -d my_db -U team1 "select * from team1.orders o inner join team2.products p ..."

I don't mean to troubleshoot over HN comments, as the problem space is filled with nuance and trade-offs, but intended it as "for your consideration"

[frollogaston]

Thanks, but it's something else. When I say people shove their data into other teams' DBs, I really mean into other teams' schemas... and they don't even have direct SQL access to their data anymore, rather the teams set up some CRUD API which they have to painfully maintain.

We aren't using Postgres but a more specialized DBMS. Everyone basically does the first thing in your example, sharing one cluster. The real issue is it's a big corp with red tape around stuff, people don't want responsibilities like compliance, and people are rightfully scared of keeping things performant on a fancy DBMS. Our team isn't scared, we did it, but it wasn't easy either.

[frollogaston]

To clarify, team A has some data in a DB, team B comes along asking to store their own data in there too, team A sets up CRUD API through which team B writes their stuff into team A's DB then gets it back.

[utmb748]

Was in startup which quit before hitting 1000 users in app at the same time, but performance was top priority so data layer stack was quiet big.