Thread - Nostr Hypermedia

Microservices is an anti-pattern. Adding network hops, routing, and potential for cascading failure between every backend function call seriously hamstrings a company in the long term, all so lazy developers can sling out new services without caring about the greater codebase or long term production salience. While idependent backend services do allow backend teams to work based upon a well defined interface, deploy and scale separately, they come at the extreme cost of a network hop and all the complexity it entails (fault tolerance, instrumentation, latency, etc, etc), and so they should be used very cautiously. Big companies go further by leaning into a monorepo architure to maximize in-process code reuse (functions) while still organizing code (folders) and deploying using a shared procedure with a single, unified process architecture. The network is not free. The network is the most expensive thing. Reduce the amount of disparate, chatty backend services and increase the amount of same language, same process, unified code. View quoted note →

↑ Parent

Replies (9)

Laser laser@primal.net 7 months ago

The term 'microservices ' implies going ham with little networked backends while pretending like distributing logic in this way has no costs. Independently developed and deployed backends have a time and place, but it certainly is a costly pattern that should be used as a last resort. I have yet to see a case at any scale where backend code should not be developed together in a monolithic codebase, even when it is deployed in a distributed architecture for various needs (job processing vs request/reply backends).

2 replies ↓

Brunswick Brunswick@stacker.news 7 months ago

The notion of microservices is a lazy event pipelining architecture. It's better to just use a RTC microkernel framework inside your application and break out scalable pieces with proxy placeholders or a pub-sub rally point like over zmq or redis.

Anon anon@anon.dev 7 months ago

Great post. Although I retired a couple years back, one of the things I absolutely *loved* about running my one-man software development shop was that I wasn't forced to deal with silly tech trends like microservices. It always amazes me how eagerly software devs embrace needless complexity. It's like you say, you can organize stuff by folders. If you identify a piece that needs to start/stop independently of the rest of the system, or spawn additional instances of itself across machines, fine, make it into it's own self-contained process. But this obsession with taking a single function and wrapping it in a service never made any sense to me. All I know is, while my competitors were fiddling about with microservices and elaborate containerization strategies, I just focused on delivering software that worked, and I seemed to do ok.

Pixel Survivor 7 months ago

seen.

1 replies ↓

G Force G 7 months ago

Micro services seems to be just another instance of Conway's Law.

Conway's law - Wikipedia

Some organizations are composed of many many single responsibility teams and so they evangelize that the way to do things is their way.

Laser laser@primal.net 7 months ago

Exactly. Evented production typologies can be achieved without losing the code reuse of developing everything together in the same repo. You can have thousands of engineers sharing code via functions while also deploying the entire codebase in a myriad of different production modes to execute procedures differently for different purposes. Just because Kafka consumers need their own persistent process that's seperate from request/response architecture, does t mean those functions need their own source repository and deployment systems, etc. Reuse everything.

Laser laser@primal.net 7 months ago

I think a lot of what happened is that Google and the like never sufficiently open sourced their monorepo secret sauce, and that led to (dumb) engineers adopting familiar structures, like GitHub orgs with many different repos that they could easily deploy in a 1:1 fashion with cloud tooling. Fast forward a decade, and the "microservices" monstrosity has become normalized.

1 replies ↓

aljaz aljaz@nostr.si 7 months ago

i think also the huge VC driven hyperscaling moment in software development and creating all these huge companies who were hiring 100s of engineers per month who ran fast and broke things meant that it was easier to make new hires productive is every new team essentially had a green field project vs onboarding to monorepo and getting familiar with everything

Bitcoin Mises 7 months ago

yes.