←back to thread

1087 points smartmic | 1 comments | | HN request time: 0.205s | source
Show context
anthomtb ◴[] No.44303941[source]
So many gems in here but this one about microservices is my favorite:

grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

replies(8): >>44304390 #>>44304916 #>>44305299 #>>44305300 #>>44306811 #>>44306862 #>>44306886 #>>44309515 #
jiggawatts ◴[] No.44304390[source]
I keep trying to explain this to tiny dev teams (1-2 people) that will cheerfully take a trivial web app with maybe five forms and split it up into “microservices” that share a database, an API Management layer, a queue for batch jobs to process “huge” volumes (megabytes) of data, an email notification system, an observablity platform (bespoke!) and then… and then… turn the trivial web forms into a SPA app because “that’s easier”.

Now I understand that “architecture” and “patterns” is a jobs program for useless developers. It’s this, or they’d be on the streets holding a sign saying “will write JavaScript for a sandwich”.

replies(4): >>44304502 #>>44304522 #>>44304575 #>>44305470 #
frollogaston ◴[] No.44305470[source]
The only useful definition of a "service" I've ever heard is that it's a database. Doesn't matter what the jobs and network calls are. One job with two DBs is two services, one DB shared by two jobs is one service. We once had 10 teams sharing one DB, and for all intents and purposes, that was one huge service (a disaster too).
replies(3): >>44308902 #>>44310025 #>>44323078 #
1. jihadjihad ◴[] No.44310025[source]
Great point. I've only worked at a couple places that architected the system in this manner, where the data layer defines the service boundary. It really helps keep the management of separate services sane IMO, vs. different "services" that all share the same database.