> Cloud CDN is Google’s own CDN solution for sites running in VMs inside Compute Engine. It is designed and implemented a bit differently from other CDNs, since it is meant to cache not only static content, but practically a whole site in more than 50 edge caches globally.
I'm not seeing what's so special here. Other CDNs can do whole-site acceleration and caching (Akamai Sureroute, EdgeCast ADN).
> It is a whole new take in the concept of CDNs, going way further than simply caching files, since it is directly integrated into their Load Balancing system and it literally means that a copy of your site will be running and serving from the closest location to your customers, with a single public IP address thanks to Anycast.
This makes it sound like Google is magically making your GCE instances run in each of their POPs. What if those instances need to share state? What happens when a page does 10 SQL queries to a server halfway around the world?
That's definitely a misunderstanding on the author's part. I think our own landing page (https://cloud.google.com/cdn/) actually makes this clear: there are caches at the edge, but we (currently) deeply understand your origin (our compute engine VMs) and don't require any funny modification to your setup (just click a button) or look any different than your existing anycast IP for L7 Load Balancing.
Disclaimer: I work on Compute Engine, not this (so I only sort of know what I'm talking about).
"We deeply understand" - the worst thing I want to hear from a CDN. I want full control like Fastly allows me to use my own VCLs. "Deep understanding" is not something that I find as a plus as I read it as "we assume a lot of things (wrongly)". "Full control", "cache tags", "wildcard/tag purging", "sub-minute purges", etc. - these are the things I want from a CDN. I don't want another CloudFront!
The "deep understanding" is from a networking POV...
They're not trying to do those niche features (yet?). They're just trying to improve site perf for anyone using HTTP LB's on GCP already. You check a single box and your content is magically served from (or terminated on) a crazy number of POPs with zero configuration.
What "deep understanding" when it works with VMs within GCE only?! This is a marketing description, not a technical one. The features I mentioned are not "niche", they are basic among CDNs and both Google and AWS seem to offer the worse and totally impractical CDNs. Honestly, if Google Cloud offers a CDN comparable with Fastly, I may consider a move, but for a CloudFront copycat (well, a copycat of Gen. 1) - thanks, but no thanks! In general, this once again proves that Google Cloud is not a viable alternative, it's only been playing a catch-up game, it doesn't deliver pleasant surprises, and that AWS is the way to go. Okay, true, HTTP/2 is the only missing feature, but I'm sure Amazon is gonna deliver this anytime.
I have used both GCE and AWS. Current I have website that is hosted on GCE, but I am using Cloudways managed platform because I am not good with server configuration thing. GCE is definitely better in performance and cheaper in pricing than AWS. Their block storage is more than AWS and they have native load-balancing technology which AWS does not have have. The only downside I have felt with GCE is that they are present in less regions than AWS. Google should also work on expanding their presence to more regions.
Well, there's spot instance pricing and reserved instances with AWS that nobody can touch. What "native load balancing" are you referring to that has no equivalent with AWS? There are many options for EBS - including magnetic storage. I doubt you can beat the speed of EBS with provisioned IO! Maybe you weren't using the right type for your need!
We have our own spare capacity product called preemptible VMs (cloud.google.com/preemptible-vms) with a similar discount and no need for bidding (Disclaimer: I worked on it). Also, we don't have reserved instances because our sustained use discounts, per-minute billing and continued year-on-year price drops make more sense than any of the RI combos (1 yr is worse than our pricing with sustained use, 3 years locks you out of price drops).
As to load balancing, I assume the poster is referring to the need to "pre-warm" ELB if you actually want to scale while our Maglev based load balancing goes from 0 to 1M qps within a minute.
Finally, EBS with provisioned IOPS is a good product! But so is PD-SSD, and you don't need to be a storage expert to get the best performance.
As others have pointed out, we've made a lot of progress in the last couple of years. Give us a closer look!
From AWS article on Best Practices in Evaluating Elastic Load Balancing, section Pre-Warming the Load Balancer:
"In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing."
Edit: This means ELB could not deal with sudden spikes of traffic.
Although we've used to call support and request a higher capacity ELBs (you can't get this automatically), recently we stopped doing it recently and handle spikes from 1,000 to 100,000 concurrent users within a couple of minutes without a sweat. By the way, many people are unaware, but CloudFront distributions also need to be upgrade to handle spikes similarly to ELBs.
Easier to use? If you understand "cloud computing" as "VMs in the cloud" than Digital Ocean is much cheaper and easiest to use. To me, "a cloud" is a few steps beyond just the rudimentary VM hosting - I get a lot of services from AWS that I need to implement and maintain myself with GCE or other cloud vendors. Okay, I agree, Google is catching up, but AWS is still years ahead with things like CloudFormation, OpsWorks, ElastiCache, RDS, Elastic Transcoder, WAS, SQS, and the likes.
Google Cloud is by far the best Cloud. Beats Aws and other cloud providers by miles margin. Also keeping in mind that a service that just entered beta is the fastest by itself is impressive. I would say, let's wait a while before commenting on features.
Aww, he's just excited! He really does work for Monsanto, not Google and if you go back far enough you'll see he's used AWS, GCP, and Open Stack (and seems to enjoy meditation). So he's not some sort of shill, just a happy customer!
I'm not sure if it's related to his work at Monsanto and the exposure to GMOs and herbicides, but based on his info, he is an obvious case of illeism [0]. I'm joking, of course. :)
I did PhD in Cloud and Big Data (Created a Cloud and Big Data platform for crunching large scale images on satellite clusters). I spent about 10 years of my life working on nothing but Cloud and Big Data. And I rarely do comment on anything outside my area of expertise. If you find any of my comments incorrect or interesting, I will be more than happy to engage in a conversation with you. This is also third or fourth time an account has been created to reply to my comments. I find it very interesting!
rajeevk, I can not reply to your comment, so posting here. Just take a look at my comments on hn. I compared Aws and Google cloud in terms of ease of use, pricing, open source friendliness, scalability, security, performance etc .. You can find a detail answer as to why I came to this conclusion.
I'd chose Azure before Google Cloud if I look for AWS alternative. I see more fruitful imagination in Microsoft than in Google! I am highly disappointed by Google - they've missed so many opportunities when it comes to Cloud Computing! They started the negative trend with the ridiculous and pricey AppEngine! And now they continue to lag severely behind Amazon!
Also, if people mostly cared about "the fastest", you'd see only Akamai in the past, but, no, people wanted freedom! I was stuck with Akamai and their $600/hr professional services for too long to know this first-hand! And "the fastest" is when the service is not heavily utilized like the rest and it has very limited functionality. Plus, other vendors constantly improve as well. The fastest service today is not the fastest of the tomorrow, but the one that starts with a minuscule subset of the baseline and what the others is doomed!
Well Microsoft also started giving $120k (first 12 months) in free credit to startups that went through most accelerators, whereas equivalent AWS credit has been exhausted by most of us.
I've heard about this as well - a friend's startup has a vast free infrastructure on Azure using the same program, but I think though you'll be in troubles having to migrate to AWS/GCE when you run out of the free credits and your startup survives one year and migration is the last thing you wanna deal with at that time. :)
Google's innovation is what they are doing with Kubernetes. Amazon's ECS is meh when you compare it to Kubernetes. I don't think Azure has done anything yet in this area.
True, but you don't need GCE to run Kubernetes. Also, given GCE is more rudimentary, you need Kubernetest with GCE more than you need it with AWS. For example, if you want to run Elasticsearch or a video transcoding service, you need something like Kubernetes on GCE, but you already get a managed service from AWS that does this well.
With Lambda, API Gateway, WAF, and ECS, DynamoDB or RDS, you pretty much can cover 95% of the usage scenarios.
CloudFront and what Google has shipped here are completely different things. I don't really understand your anger here TBH. Might be worth playing with GCP again if you haven't in a while. It's much better than AWS and Azure.
Sorry, I had to clarify: VCL [0] stands for "Varnish Configuration Language", i.e. you can move to another CDN that supports VCL (although I'm not aware of any other) or move to your own Varnish servers.
OP Here> The setup was as follows: VM instance in each of the 4 cloud regions around the world:
Council Bluffs, IA (us-central1)
Berkeley County, SC (us-east1)
St. Ghislain, Belgium (europe-west1)
Changhua County, Taiwan (asia-east1)
So on any cache miss at one of the 50+ edge POPs, the cloud HTTP(S) load balancer will direct the request to the nearest cloud region. The resulting cache fill happens over Google's global network, which is fast. Once that cache fill happens, that edge cache can serve the content directly to clients, which is even faster.
Google Cloud CDN is 'just' a dynamic site accelerator (with nice GCP integration), like all other CDNs.
I think the author of this blog post is trying to simplify the explanation (or just doesn't understand). No 'copy' of your site is running on the closest location. GCE is not available in all POPs.
These results would look very different if EC ADN was included. And not including CloudFlare is a bit strange.
Both EC and CF run Anycast CDNs. This is still a really cool thing for Google to release because it's nice to have more competition in the space.
I've run some prelim tests on pure route latency from 90+ worldwide locations and GC-CDN (? :) is pretty evenly matched with CF/EC.
The real test would be end to end HTTP request latency and this is where GC-CDN would probably beat out CF (since you're on the Google net from POP to GCE DC, which is nice and fast, whereas CF talks to your origin over the public Internet). EC ADN is symmetric (POP to POP is on-net) so probably more comparable.
You would need someone with access to CloudFlare POPs to run a traceroute from say, their Sydney POP to a GCE us-central instance to be able to tell whether this is really of much value apart from reducing costs at specific IX/peering points (which is actually of significant value, but I don't think this improves performance as much as you would expect -- the Interconnect is for reducing bandwidth costs for Google).
"it's already one of the fastest" ... wouldn't we expect a new service, with lots of empty cache tables and available free ram, to be faster than the established players?
I think the parent meant the cache tables of each node are empty (not many users yet), so the tested apps will be able to have relatively large cache tables on those nodes, since they aren't getting LRU'd out by other users.
So the cache table for a tested app is fuller because the cache table overall is emptier.
Google CDN looks very similar to what Cloudflare Free Plan offers. A no-Frills, fully automated setup with little or no control on how your content is being delivered. Main difference with Cloudflare being that Google forces you to use GCP as Origin and you have to pay for the CDN service (Bandwidth, purge, requests...) which Cloudflare offers for free and you can use any Origin server.
Not sure why someone would use Google CDN when you can get the same for free with Cloudflare. Moreover, Cloudflare provides Security up to L7 with WAF whereas Google Cloud has no Security features. Anybody know how DDoS (L3/4) mitigation works on Google CDN?
Now if you want control and the ability to set up your own policies (Cache Control Headers, redirect, complex cache key manipulation, etc...), Google Cloud is not going to be what you need, at least for the time being and you would be better of with EdgeCast or Akamai. Faslty is an interesting option too but their network is very small compare to EdgeCast or Akamai. Fastly is about 1Tbps of capacity whereas Akamai or EdgeCast are > 20Tbps.
I don't know if Google does this, but because they control both endpoints (cache server and load balancer) of the longest section of the path they could accelerate it by replace HTTP(S) there with something like CloudFlare's Railgun. [1]
Since Railgun is only available at CloudFlare plans starting at $200/month, this could make the Google offering attractive for certain customers.
In any case, it is hard to beat free for most sites with moderate needs.
I don't doubt that and I'm excited to see some benchmarks once the service is in full operation mode. But until then, this makes it sounds like they magically beat out everyone else when the fact of the matter is that there is no load to measure.
Question: How do cdns serve/shard data ? Meaning, in a pop, there are say 100 nodes, and all of them cache some data, say by hashing the path /ayb.jpg.
Does the loadbalancer (say, haproxy) know which node should-have the file cached ? Or there is random loadbalancing and each node get's the data from the other nodes (using the same hash)? Just like openstack-swift (there are proxy that serve http-requests, and data nodes that have files).
Probably each CDN does it differently... but the one I know about does the second.... so it goes LB, first webserver on random node, and that first webserver knows where to grab the content from the second webserver on the proper node that has the content.
OP here: You are right, CloudFlare would have been nice and in retrospect we should have added it. I think it would have fared quite nicely as during all the tests we do on regular basis its doing really well.
yes. That is true. We did not expected the post will get that popular. Unfortunately, it was all done too late. What helped us the most was that blog is hosted on DigitalOcean VPS. We scaled up to the most powerful instance and instantly the blog was back. Kudos to DigitalOcean, it saved our bacon big time today :)
Would love to see CloudFlare added to the mix. In fact, I would love to see Incapsula, Sucuri and KeyCDN compared as well, to get all top players compared.
OP Here> yes, omission on our part. CloudFlare is very popular and even more so on HackerNews. We should have added it. There are simply too many CDNs to put into one post/chart and still make the article interesting. You can sign up to our blog to get more information which does not necessarily becomes trending on HN or elsewhere.
Would be cool if you could add an image of the table with average measured times by country for the selection of european countries. (Marked with double asterisk in the post)
I guess the difference between these countries could be noticeable.
Alternatively you could post it here. I'm mainly interested in the Swedish numbers.
That's right, since it is based on the global load balancing tech, you get a single IP for all edge locations which means you can use your own custom SSL (without the need for SNI) at no extra cost (which would cost you $500/month on AWS CloudFront).
Kudos to you good sir for calling someone out and putting your wallet on the line. I hope the other guy comes through and you get a friendly wager going.
Sure it makes business sense for Google to do this, but you've gotta admit to having that same reservation for every new Google service.
Would you build a business model that relies on a brand new Google service?
Hell no - give it a few years, and wait to see if the "customer support" consists of hundreds of other suckers who've gone all-in complaining to each other on the public forums, with not even the original 20% time Gooogler bothering to read or respond to anything...
It's just happened too often. (And I know Nest and Revolv aren't "Google" as such, but they're definitely run by "Googlers" and are under the same adult supervision, so it's not even like you can say "sure, they _used_ to be like that...")
I felt like this about Google services for a long time now. However, we decided to go with GCE for some of our recent / less critical work and to be honest, I've been really happy.
We had decent support and even our requests through non official channels like slack communities or direct emails got responded / followed up. Services seem as stable as AWS. And most of the tooling is better.
I think they are doing a great work recently on Google Cloud. Granted, we built everything with "moving to AWS should be easy / possible in case Google fucks something up really bad" in mind, which proves your point. But locking in does not scare me more than it does about locking in to AWS at this stage.
Based on your slack channel comment, I assume you're using Kubernetes. That's a great choice for new development, and I'm glad you've had your questions answered! I can't tell though, did you also use one of our paid support tiers? (https://cloud.google.com/support).
I got burned by App Engine so I get the vibe but frankly a bot could post this same argument on every Google thread and it wouldn't move the needle one way or the other.
Would I put containers on Google Cloud in return for free upload bandwidth to YouTube and use their CDN because it was easy? You bet your ass I would. If you can't tell the difference between a novelty thermostat and a major, long-term, strategic corporate investment then you've got bigger problems than switching DNS entries for a CDN.
This is not green field, but as the neighbor's lawn next to mine, it may or may not be greener. Time and fertilizer will tell. Smell the dirt Spartans.
I'm not seeing what's so special here. Other CDNs can do whole-site acceleration and caching (Akamai Sureroute, EdgeCast ADN).
> It is a whole new take in the concept of CDNs, going way further than simply caching files, since it is directly integrated into their Load Balancing system and it literally means that a copy of your site will be running and serving from the closest location to your customers, with a single public IP address thanks to Anycast.
This makes it sound like Google is magically making your GCE instances run in each of their POPs. What if those instances need to share state? What happens when a page does 10 SQL queries to a server halfway around the world?