←back to thread

The Grug Brained Developer (2022)

(grugbrain.dev)
1087 points smartmic | 6 comments | 17 Jun 25 20:24 UTC | HN request time: 0.655s | source | bottom
Show context
anthomtb ◴[17 Jun 25 21:05 UTC] 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 ◴[17 Jun 25 21:56 UTC] 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 #
1. frollogaston ◴[18 Jun 25 00:26 UTC] 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 #
2. glurgl ◴[18 Jun 25 11:27 UTC] No.44308902[source]▶
Yes! My viewpoint also. I've been very alone in that view over the last few decades. Nice to know there's someone else out there.
replies(1): >>44312246 #
3. jihadjihad ◴[18 Jun 25 14:06 UTC] 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.
4. frollogaston ◴[18 Jun 25 18:33 UTC] No.44312246[source]▶
At least it's widely considered bad practice for two services to share a database. But that's different from orienting your entire view of services around databases. The case of one job with two DBs matters too, mostly because there's no strong consistency between them.
5. jiggawatts ◴[19 Jun 25 22:23 UTC] No.44323078[source]▶
A more precise view is that there are boundaries inside of which certain operations are atomic. To make this more precise: the difference between a “dedicated schema” and a “database” is that the latter is the boundary for transactions and disaster recovery rollbacks.

If you mix in two services into a single database - no matter how good the logical and security isolation is — they will roll back their transactions together if the DBA presses the restore button.

Similarly they have the option (but not the obligation!) to participate in truly atomic transactions instead of distributed transactions. If this is externally observable then this tight coupling means they can no longer be treated as separate apps.

Many architects will just draw directed arrows on diagrams, not realising that any time two icons point at the same icon it often joins them into a single system where none of the parts are functional without all of the others.

replies(1): >>44329869 #
6. frollogaston ◴[20 Jun 25 17:21 UTC] No.44329869[source]▶
The atomicity is the main reason, but it's also about API boundaries. Sometimes someone makes a "service" that's more like a database exposing a full suite of transactions and CRUD operations, then other teams call themselves "stateless" interacting with it. But really they're sharing a DB, and thus building one giant service, because the API they're using is so broad that it creates an inseparable coupling.