Live data from Hacker News

Microservices are a tax your startup probably can't afford

nexo.sh

271–272 of 272 posts

Re: Microservices are a tax your startup probably can't afford

#271

Earlier quoted context omitted.

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-…

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 is…

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.

Re: Microservices are a tax your startup probably can't afford

#272
post #213

Earlier quoted context omitted.

> Or, do you simply wait until after the program is written to [observe] its [behavior]? How is that even possible?

Write the program, run the program, observe. Or, write the program, write the tests, run the program, observe for breakages. Neither are TDD, the practice of writing tests first before any actual implementation is written, which I agree with the parent is dogma, impractical, and unrealistic.

> Write the program

Sounds hard!

Jokes (?) aside, the scientific method is a loop, so it probably doesn't matter long at which phase you enter.

Post reply on HN