GCP's max instance count is helpful to a certain extent, but this doesn't completely protect you unless from DDOS attacks. If you have 3 nodes that can all handle 1000 requests per second, and those requests are doing something expensive the max instance limit doesn't help you.

Although I guess if you have 3 nodes that can only handle 100 requests each the damage of a DDOS would be much more limited.

True, it doesn’t protect you from DDOS. But how is it different from having 3 regular hosts?

Yeah GCP is the friendliest cloud provider for sure.

Still a big, complex platform with tons of features and things to spend money on, but much more friendly than some others (looking at you, AWS)

And a billing limit. plus you get a generous amount in the free tier

Uh, it's not? Please don't spread misinformation.

> I don't want to be unreasonable, but Google used to at least generally support the idea of the open web.

This is a Machine Learning product, I don't think anyone at Google, at least as part of this team, is trying to "get you" or destroy the open web or something. This isn't even a case of Google using something non-standard -- WebComponents is part of the standard, you can even see it in Mozilla's MDN [0]. Firefox, Safari, Edge, et al simply haven't implemented it yet (or landed in stable). Is that somehow also Chrome's fault?

Filing a bug report is good, but ranting on HN about how this is a sign of Google trying to steal the open Internet is at best unnecessary, and absolutely unreasonable.

Coincidently, I'm working on an application that uses complicated SVG with CSS animations, and I've spent a ton of time optimizing it. I've never tested it outside of Chrome before today. To my surprise, while everything works fast in Chrome, in Safari it's bearable, but in FF it's simply too laggy to use. Now, I probably won't ever get to fix the performance issues in FF and Safari, simply because I don't have the time. Am I also out there trying to destroy the open web? Maybe I'm just bad, not evil.

[0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components

No, I don’t agree with you.

This is a basic audio playback widget on the web. The web is nominally an open platform. Whichever team built this decided to build it in a way that it would only support Google’s own web browser. It’s not unreasonable to expect a massive web company to build cross-browser support for their user-facing demos, especially in cases where there is obviously no reason that it needs to be incompatible.

Like I said, I appreciate that building cross-browser is not always possible. The difference between you and Google is that you aren’t one of the largest companies in the world, and you don’t publish your own browser.

True, but clearly the marketing page of a feature service for a major cloud vendor should be accessible to as many as possible. There's no real reason something as simple as an audio player to play samples doesn't work well on all browsers.

As usual, this is a baseless conspiracy theory that doesn't even make sense.

It would be baseless if ROMs aren't allowed to have them. But they do, hence my conspiracy theory isn't asinine.

Also, I bet this will do nothing to the Chinese tablets side-loading Google's Apps.

"If we let them have what they want and do not intervene, they will just stop." -- England and France, a few years before WWII.

If you look at the list of homes listed, I wouldn't say they are above hotel price at all.

I mean, embedding data into html looks bad, but is it really worse than loading a script separately? This is basically the "bundling" on the HTML layer, i.e., what HTTP/2 should offer.

For a website like Airbnb, 1.9M for total asset size doesn't seem bad...

I got 8MB for the entire site (homepage, from empty cache). I don't think it's that bad either. The webapp does also 'feel' bloated to me, but it might not be due to total transferred bytes, but rather just the JS heavy frontend.

> First AMP and now QUIC.

Um, pretty sure QUIC was in the pipeline a few years longer than AMP. Besides, it's literally a protocol in the network stack -- would you say IPv6 is an enemy of the web and underlying internet?

Please stop the needless fear mongering.

It is one layer above IPv6, but what difference does that make? It's an improvement over an existing protocol to solve real problems.

I don't think anyone can really know the OSI model. I know I frequently use HTTP as a Transport Layer protocol myself, so you got me there. ¯\_(ツ)_/¯

I pasted that initial quote ("Google has the largest QUIC deployment...") to point out that Google has a significant advantage in owning the most popular web browser and also most of the top-tier web properties in Google search, Gmail, and YouTube. Because they control the whole chain from browser to content, they can release things that make those experiences better for Chrome users (using QUIC) at the expense of non-Chrome users (who get worse TCP performance until everyone else completely adopts QUIC). Then, toss up some banner ads for non-Chrome users who visit YouTube saying, "YouTube too slow? Switch to Chrome!"

>would you say IPv6 is an enemy of the web and underlying internet?

If IPv6 made IPv4 performance worse and was pushed by one company who controls both the browser and the most popular web content, yes, I would.

Everything you say is true, yet... the Google approach works and the others don't. If our choice is free and mostly-open protocols from Google or using HTTP/1.1 + TLS 1.1 + TCP w/ CUBIC + IPv4 w/ NAT forever, Google doesn't sound too bad.

This is related to the AV1 vs. MPEG discussion from the other day where people pointed out that we basically have a a choice between free codecs developed by Google/Netflix or codecs that suck you dry from legal fees.

>a centralized server connected to the internet does all your application, storage and processing

You can have more than one server in your AWS account.

>someone who believes in things I don't agree on is either working on some hysterical dime or delusional