Hey @p I have a question.
Why are microservices still pushed so hard?

I know that g*ogle is pushing microservices hard internally, trains their own employees and when they leave that's all they know how to do. Add to that those aspiring to work at g*ogle and those aping g*ogle.
Still, github is filled with new projects about terraform, k8s, and many stand alone microservices (most of them close copies of one another) even after all these years that this trend has been going on.

1. As more people use the internet, the number of large websites increases, making certain niches that were deployed as part of a bigger system viable on their own. This is not true however for websites that will remain small-medium in size where microservices are too big of a hustle.
2. I've noticed the same people pushing for microservices, push for "immutable" OS type standarization.
3. Pretty sure gRPC is also a component of whatever is their end game.

I'm trying to figure out what's their end goal here, because all this seems planned and I don't think it's for the good of the open internet however much they say it is.
I thought you might know more since you've been observing the trend far longer than I have.
@laurel

> Why are microservices still pushed so hard?

It appeals to engineers because they can, in theory, make small tools that do one thing (although too few of them think about fitting it together and they end up with a rats' nest). It appeals to managers because of provisioning: GCE, AWS Lambda, etc., fine-grained access control of repositories, the promise of automatic compliance with various absurd regulatory boundaries (the same ones that made everyone start requiring 2FA for everything).

> 2. I've noticed the same people pushing for microservices, push for "immutable" OS type standarization.

Yeah, you know, all of the commercially available bananas are clones, they're all genetically identical. We get an aggressive enough fungus, that's it for bananas for a few decades.

And, you know, ASLR and stack canaries and whatnot, but I think it's better to locally source your binaries rather than having purely identical ones. It is way easier to write an exploit for a process that is executing a binary that you have, you know where everything's gonna be, you know how paranoid the compiler settings were.

> gRPC

It's like job queues and graph databases were, it's a buzzword for something almost no one needs but GOOGLE SCALE. See the following old-ass article about exactly the same thing: http://widgetsandshit.com/teddziuba/2009/06/startups-keep-it-in-your-pants.html .
Follow

@p @laurel
> gRPC
> but GOOGLE SCALE
My only personal interaction with gRPC was figuring out why Proton Bridge and ProtonVPN didn't work on my Windows box. Turned out that gRPC, unlike everything in Go standard library, doesn't make localhost a special case, so when you have HTTP(S)_PROXY env var set, GUI suddenly can't connect to a service running on the same machine. Now I think I have an idea why: who cares about such puny shit as proxies and localhost when you're on GOOGLE SCALE 😂

@m0xee @laurel gRPC is TOO ADVANCED to use regular HTTP/2. Forget everything you know about connecting to localhost!
Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml