This is exaggerated to the point that I consider it fiction. BTW Google doesn't substantially use gRPC within their datacenters.

The industry has always been this way. Back in the day there was many many processor ISAs that are now consolidated. There was been many networking standards that consolidated (IPX/SPX anyone?) New things often diverge because of new requirements not out of spite. There is a push and pull between standardization and innovation. Doesn't make it particularly unhealthy unless you can point to specific metrics and compare trends throughout the long arc of time.

> This is exaggerated to the point that I consider it fiction. BTW Google doesn't substantially use gRPC within their datacenters.

For explicitness Google uses stubby which shares a lot of interface level commonality with gRPC but there's differences at a runtime level. Nobody is slinging json or soap around Google data centers.

And gRPC is basically HTTP/2. Difficult to get more standards-friendly than that.

I suppose when some people advocate for "standards" they just mean the shitty systems prevalent in the industry they happen to have been used to.

> For explicitness Google uses

Japanese Bullet Train technology

I agree — the corporates have stop building and making `for` their users. They make their services so the users have no option but to get more and more comfortable in their ecosystem, and never get out.

Very soon, we will have providers/companies/champions/fighters that keep building the middleware transports to connect their behemoths.

Btw, someone somewhere popped up a better term — AGAMEMNON (Apple, Google, Amazon, Microsoft, Ebay, Meta, Nvidia, OpenAI, Netflix)

OpenAi is Microsoft, so that term not really works.

> Another random example is HTTP/3, which is basically the "What's best for Google" protocol.

HTTP/2 is that. The version 3 is... quite great, and not really originary from there.

And gRPC is some self-contained thing that doesn't bother anybody.

I do really agree with your point. But those examples are bad, and yet another non-standard cloud service isn't also a good example.

For example, HTTP/3 uses QPACK, which has a static predefined list of HTTP header strings included in the standard.

What strings you ask?

The top hits Google captured from their data centre egress.

E.g.: https://www.ietf.org/archive/id/draft-ietf-quic-qpack-20.htm...

Notice that "content-encoding" includes br (Brotli), a Google compression algorithm that essentially only they were using at the time.

I don't understand what the objection is to the methodology. Are you claiming there is another party that has a better sample (even subjectively so) and was pushing it and didn't succeed? If anything, standards committees are often overly annoying and biased the other way just because some other company representative wants to justify their presence. That is also cherry picked. For example standardizing ALPN over NPN which is largely a downgrade for the average user done in the standard process. The examples you use simply indicate a certain company is ahead of the game in solving problems others also have.

It’s not from there? HTTP/3 is QUIC, right?

Oh you are right, QUIC is from there. I misremembered it.

And QUIC/HTTP3 was invented by Google to deliver more ads, faster. Yay.

This is like saying planes were invented to deliver you to more businesses, faster.

At least I enjoy taking the plane and I decide when to take it. Planes serve a purpose. Adtech is just parasitic. An Internet without ads wouldn't need QUIC.

>The IT ecosystem has fragmented into mutually incompatible cliques. You are either in the Google ecosystem, the Amazon ecosystem, or some other one, but there are no more truly open and industry-wide standards.

This is one excellent example of the reason that increased/renewed anti-trust actions by the FTC are necessary.

This criticism is a little weird. This is an internal protocol in Google’s datacenters. Why should it have to be compatible with anything?

Because the whole point of the linked article is that they're making it part of the Open Compute Project, whose entire existence is devoted to making sure things are compatible with other things.

Not sure why Netflix would be in your list. AFAIK, they run their cloudy stuff on AWS, which isn't too unusual; chaos monkey is neat though? Their CDN boxes are exotic because they run a lot of sessions at relatively pedestrian bandwidths and a lot times 5-20Mbps adds up to a huge number. There's real work there and it's impressive, but it doesn't need exotic network protocols. Bulk encryption offloading NICs are super handy for their use case, which is certainly somewhat exotic.

They haven't said much lately about sending content updates to their CDN nodes, but I think the throughput requirements on that isn't as high.