
Google has quietly launched a CDN - prostoalex
http://venturebeat.com/2015/12/09/google-cloud-cdn/
======
buro9
This is not an Akamai competitor.

You'll know an Akamai competitor when you see it as it will handle video and
large files.

This Google offering is limited to files below 4MB, which precludes most
video.

Really this is a CloudFront competitor, but even then... it is only offering a
very basic set of features to do with the caching, rather than anything else
CloudFront is doing.

Further, the logic of what is cached is very basic:
[https://cloud.google.com/compute/docs/load-
balancing/http/cd...](https://cloud.google.com/compute/docs/load-
balancing/http/cdn#whichcontentiscached)

This all serves one goal: Reduce your Google bill by caching more and
preventing it reach the server. How it does this is extremely basic, and it
has limitations (check the cache invalidation gotchas).

The best way to reduce your Google, Amazon S3, and other bills remains to use
a CDN in front of it that is cheaper than the storage behind it. The basic
features of that you should care about is how easy is it get stuff into cache,
serve it over [https://](https://) and invalidate it at will. Advanced
features should look at DDoS costs (are you paying when you get attacked?),
whether there are PoPs/edges where your market is, and then anything specific
to your product, though you've usually made a selection before you get this
far.

------
cagenut
Not to rag on the offering, but the headline is just not right. This is a
CloudFront competitor not an Akamai competitor. Its a very rigid barebones
product at a low margin via self-serv tooling.

~~~
mkj
Google's reach of "Edge Caches" seems closer to Akamai's than CloudFront's
though - lots of indivdual ISPs have them.

~~~
jdub
I have pretty strong doubts that the Google Cloud Platform team would have
convinced the broader organisation to host customer stuff on their mission
critical caches.

As I understand it, there's not a lot of dogfooding (let alone cooperation!)
between GCP and Google.

~~~
brazzledazzle
A small counterpoint: I saw a talk recently that discussed charging other
Google teams for using GCP resources to discourage wastefulness.

~~~
jdub
My understanding is the accounting for services process happened prior to GCP,
and isn't about GCP resources.

~~~
brazzledazzle
The talk specifically discussed GCP being free for internal use and one of
it's costlier services being used without any thought being put toward
optimization. Once they started charging they optimized and used dramatically
less.

------
boundlessdreamz
Limited only to service hosted in GCE unlike cloudfront which is a huge
limitation. My guess is that there are more non-aws cloudfront customers than
aws ones

------
nikolay
Articles like these tell a lot about the level of competence of the common
journos. There are many CDNs and there's Akamai. Huge difference! This is not
even a Fastly competitor!

~~~
joshmn
Wanna hear about the journalist who said that WordPress wasn't capable of
handling 50k requests? And that proper caching is useless? And that static
site generators were the way to go because it couldn't? And that caching
doesn't make things static? And that jekyll is designed to be used on windows,
but not the "500 gems" it installs?

I digress.

------
bajsejohannes
s/Akamai competitor/CDN

~~~
dang
Done.

------
lopatin
I'm sure it's a great service. I found it a little funny that this is a CDN
that is "not [yet] recommended for production use".

~~~
illumen
It's also kind of funny that it's available in limited regions.

Alpha, is what the Article says. Which means not ready, and changing in
development quite a lot.

------
tszming
The issue with Google launching these services is you don't know when they
was/will be blocked in China. Not really a global competitor to
CloudFront/Azure IMHO.

~~~
wernerb
Cloudfront is not available in China. We had to implement a small CDN for a
large ecommerce website. What we did was use geo-ip route 53 and route chinese
ips to load balanced nginx instances caching the cloudfront cdn.

What compounds the problem with China is that the chinese are very much used
to requesting an english language variant of the webstore as its often
cheaper. This circumvents the CDN however as all stateful requests are routed
to foreign servers making their experience really slow.

Also there's the chinese web license process that you have to go through to
even host a website in china.

~~~
tszming
I've a few instances in aliyun (alibaba cloud) to monitor the traffic from
time to time, Cloudfront works for me now, while googleapis.com is blocked.

I cannot convince myself not to use a politically neutral company (or China
friendly) like AWS, Azure.. when I am considering the CDN service.

~~~
wernerb
Oh yeah its accessable from China. But I meant that there is no cloudfront
edge region in China so chinese customers must cross the firewall and it is
really really slow for them.

------
akurilin
I couldn't quite find this, but what domain are these files going to be served
from?

~~~
dorfsmay
Usually you created CNAMEs from your domain to your CDN's.

~~~
hayksaakian
Is it best practice to use a separate domain for CDN because of cookies?

Eg: examplecdn.com instead of cdn.example.com

~~~
dorfsmay
If you trust your CDN, then no, you have less issues if you use the same
domain as the one you use for your APIs.

~~~
valverde
It's not about the security of the cookies, it's about the bandwidth you save
by having a separate domain for static content, because the client does not
have to transmit the cookies for each request.

~~~
dogma1138
If you issue cookies to www.example.com your browser will not send them to
cdn.example.com unless it's very poorly written.

Each cookie has a path set to it and browsers will obey it, this includes
inter-domain paths and restrictions. If you want you can go even further and
assign a cookie to a specific URI path so the cookie will only be issues to
pages that fall under www.example.com/private/ for example if that's what the
path is set too.

~~~
valverde
There are many high profile websites that use the cookieless domain approach:
Google, Facebook, and Reddit off the top of my head. I wouldn't say they are
poorly written - it's more of a design decision to have cookies in the top-
level domain.

~~~
dogma1138
I didn't say the sites would be poorly written, the browsers would be if they
do not obey the cookie set domain and set path restrictions.

And the fact that big sites use it doesn't mean that they were "well written",
Google mostly issues only tracking cookies for wildcard domains like
.google.com as far as private cookies go they usually would be issued for each
domain individually (play.google.com etc.). Issuing authentication cookies to
wildcard domains and root paths isn't advisable even if some big sites do it
doesn't mean you should take it as an example :)

P.S. I really hate "Google and Facebook are doing it" as an example, even if
they are you most likely aren't either of them, not even close they have quite
different considerations than you. Even when they do things which aren't best
practice or common sense it doesn't mean that you should decide to take the
same path, both Google and Facebook have plethora of ways to ensure account
security including quite decent activity heuristics, they have many ways of
detecting attacks such as XSS, and they have most likely a much better process
of ensuring that vulnerable pages do not go live or do so quite rarely. Unless
you can say the same then do not use them as an excuse, you do not need to
issue cookies to wildcard domains and you can restrict them to certain paths,
and you better do so because you do not have many other mitigating controls in
place as the big players do.

~~~
valverde
Ah, sorry, I misread your comment. Indeed, a browser that doesn't respect
cross-domain restrictions is a poorly written browser.

My point still stands, though: the point of cookieless domains is not
security, but bandwidth. And there are legitimate reasons to have top-level
domain cookies - sharing authentication state between subdomains is a common
example - which would prevent a subdomain from being used as a CDN, without
receiving cookies.

------
SimeVidas
Is this the CDN used for AMP pages?

