What Even Are Microservices?

Post by dspillett » Tue, Jul 28, 2026, 2:10 PM UTC

Joel_Mckay wrote: post #34

dspillett wrote: post #13

Something people use to architect towards being the next Amazon, before they've even got their first 100 users. Also useful for CV padding. Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.

Or build core infrastructure right the first time, and not spend millions of dollars turd-polishing while your competition eats the market. Davids talk makes some good arguments, but does not fully acknowledge low-maintenance infrastructure at scale. =3 "10 tips for failing at microservices" (David Schmitz) https://www.youtube.com/watch?v=GWgRw5jiYy0

Post by [deleted] » Tue, Jul 28, 2026, 3:48 PM UTC

reactordev wrote: post #69

zero_shift wrote: post #58

Earlier quoted context omitted.

Observability and operability are just not the same thing as being able to reason about the software. You need both You can't capture the full range of behaviours and edge cases unless you are willing to ingest billions of events without lossiness Metrics have limitations of cardinality. Logs need to be reduced or else you are in archive rehydration hell There will be code paths that have never been triggered that yo…

>”There are code paths that have never been triggered” I don’t know where you learned engineering but where I work, we test our code. There are no “dark” paths. 98% code coverage over 50+ microservices.

Post by thomas_krosos » Tue, Jul 28, 2026, 3:58 PM UTC

Post by reactordev » Tue, Jul 28, 2026, 4:05 PM UTC

inigyou wrote: post #63

mrkeen wrote: post #55

Earlier quoted context omitted.

* My last monolith job had 4 hour release windows. * You can't change anything of substance. The more people touching the same codebase as you statistically puts you way lower in the pecking order. Changes become political, not technical. Sometimes the forces of stupidity cancel each other out. It was a 10+ year-old C# monolith, and the top dog wanted to switch to Python because "AI works better with it". I didn't ha…

Why would a single deployment unit have to be written in exactly one language?

Post by [deleted] » Tue, Jul 28, 2026, 11:54 PM UTC

regularfry wrote: post #51

roncesvalles wrote: post #28

Earlier quoted context omitted.

Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time. It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction. I don't agree that there are organizational causes even though that's…

One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.