Google CDN Beta is already one of the fastest CDNs(blog.speedchecker.xyz)
blog.speedchecker.xyz
Google CDN Beta is already one of the fastest CDNs
http://blog.speedchecker.xyz/2016/04/18/google-cdn-beta-is-here-and-it-brings-more-than-meets-the-eye/
24 comments
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).
Disclaimer: I work on Compute Engine, not this (so I only sort of know what I'm talking about).
It would be nice if you guys supported external origins, but I understand the reasons for not doing so. :D
Edit: Any chance you could ask Cedexis to add GCDN to these reports: http://www.cedexis.com/reports/#?report=dsa&country=US&date=...
Edit: Any chance you could ask Cedexis to add GCDN to these reports: http://www.cedexis.com/reports/#?report=dsa&country=US&date=...
"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.
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.
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.
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.
Edit: retracted, after a closer look at your previous comments.
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!
Disclosure: I work on Compute Engine.
Disclosure: I work on Compute Engine.
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. :)
[0]: https://en.wikipedia.org/wiki/Illeism
[0]: https://en.wikipedia.org/wiki/Illeism
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!
At least mgnacl's nick is explicit in telling you to take his/her comment with a grain of salt.
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.
As others have pointed out, Google's CDN does not have as many users and content as other CDN services yet. So, of course it is faster than others.
Google Cloud is by far the best Cloud.
Any reference for this claim?
Any reference for this claim?
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!
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!
Last time I priced out AWS, Azure and GCE, Azure was by far the most expensive - by a long shot - at least for our usage.
I think Microsoft is looking to capture their F500 base that are highly Windows/AD-centric.
I think Microsoft is looking to capture their F500 base that are highly Windows/AD-centric.
Well, I guess, GCE has won the price war. I haven't checked pricing recently, but it looks vastly cheaper than Azure here: https://www.cloudorado.com/cloud_server_comparison.jsp
Am I missing something?
Am I missing something?
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.
Note that for YC, the number is $500k.
Note that for YC, the number is $500k.
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.
With Lambda, API Gateway, WAF, and ECS, DynamoDB or RDS, you pretty much can cover 95% of the usage scenarios.
Honest question: Have you actually used GCE for any length of time?
Having used both AWS and GCE, and I vastly prefer GCE. It is simply easier to use and offers better price/performance.
Having used both AWS and GCE, and I vastly prefer GCE. It is simply easier to use and offers better price/performance.
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.
You're in luck: https://cloudplatform.googleblog.com/2016/03/announcing-two-... (Oregon and Japan this year, more to come)
That's a great news. The article mentions that more will be added throughout 2017, this means GCE is slowly catching up with AWS.
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!
Disclosure: I work on Compute Engine.
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!
Disclosure: I work on Compute Engine.
Amazon just released two more EBS options today, which obviously cover more of the application spectrum: https://aws.amazon.com/blogs/aws/amazon-ebs-update-new-cold-...
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.
"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.
price isn't true, the cheapest setup in AWS is cheaper than the cheapest setup in GCE.
If your on low margin you probably never go to GCE.
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.
Good point. Isn't the Fastly VCL configuration proprietary? What if you need to move to another CDN?
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.
[0]: https://www.varnish-cache.org/docs/4.1/reference/vcl.html
[0]: https://www.varnish-cache.org/docs/4.1/reference/vcl.html
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.
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.
Cloudflare has interconnect with google:
https://www.cloudflare.com/google/
https://www.cloudflare.com/google/
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?
They need to show some benchmarks of load testing for this comparison to be fair.
Empty cache tables means lower hits so slower.
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.
So the cache table for a tested app is fuller because the cache table overall is emptier.
This comment is spot-on.
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.
PS: Akamai is not IP Anycast based
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.
PS: Akamai is not IP Anycast based
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.
[1] https://www.cloudflare.com/railgun/
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.
[1] https://www.cloudflare.com/railgun/
I just naturally assumed Akamai would use anycast for their CDN, but it is actually DNS based[1].
No mention of if their DNS is anycasted, one would presume so.
[1] https://blogs.akamai.com/2013/04/serving-at-the-edge-good-fo...
No mention of if their DNS is anycasted, one would presume so.
[1] https://blogs.akamai.com/2013/04/serving-at-the-edge-good-fo...
[deleted]
Seems ironic that the linked site doesn't load (at least for me)
I can make a fast CDN too, if it doesn't have any users yet!
I was going to say that :) When you are starting and have very few users, you should be fast.
It is very hard to keep it very fast when you have millions of free users, like CloudFlare does. That is impressive.
It is very hard to keep it very fast when you have millions of free users, like CloudFlare does. That is impressive.
I'd assume Google knows a thing or two about scaling content
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.
Does Gmail count as enough users? ;)
It's not about the number of users, it's about the amount of unique content.
What I'm saying is this software stack runs every single Google property at this very moment in time.
Every Gmail user had unique content - their mail
Gmail is all about unique content. That's why Gmail search is slower than web search.
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).
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.
Most CDN have a pile of patents that show how they do their cache hierarchy.
-Ex CDN worker
-Ex CDN worker
Why don't you compare Google's CDN to CloudFlare?
I'm not the OP, but I'm not sure why they included MaxCDN and Fastly but not (at least) CloudFlare's free service.
Disclosure: I work on Compute Engine (though I had nothing to do with this service).
Disclosure: I work on Compute Engine (though I had nothing to do with this service).
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.
Irony = their site is on CF.
$ whois speedchecker.xyz
Domain Name: SPEEDCHECKER.XYZ
Name Server: LEE.NS.CLOUDFLARE.COM
Name Server: PAM.NS.CLOUDFLARE.COMI think the OP just added CloudFlare when the site was overloaded earlier...
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 :)
[deleted]
Of course, if it's in beta, and the infrastructure has been built out but not yet heavily loaded, the performance may be unusually good.
(We see this every time the cellular industry rolls out a new band nobody is using yet, and the review sites talk about how great the bandwidth is.)
(We see this every time the cellular industry rolls out a new band nobody is using yet, and the review sites talk about how great the bandwidth is.)
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.
I guess I might be asking too much :)
I guess I might be asking too much :)
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.
I guess the difference between these countries could be noticeable.
Alternatively you could post it here. I'm mainly interested in the Swedish numbers.
I wonder if they're using Brotli. http://9to5google.com/2016/01/20/chrome-brotli-compression-l...
If anyone wants to poke this, I've set up 2 micro instances in each GCP zone and put the GCDN in front here:
http://httpbin-gcdn.xyz/
It's quite smart and pushes traffic to the right zone:
https://pulse.turbobytes.com/results/5716f2f3ecbe400cf7000ca...
Very cool stuff.
http://httpbin-gcdn.xyz/
It's quite smart and pushes traffic to the right zone:
https://pulse.turbobytes.com/results/5716f2f3ecbe400cf7000ca...
Very cool stuff.
Something that is unclear to me here, can I origin pull from anywhere? or is this purely for compute engine now?
Regarding free SSL are we talking SNI here or is this free non SNI HTTPS hosting?
Regarding free SSL are we talking SNI here or is this free non SNI HTTPS hosting?
Right now it's just compute engine (Source: cloud.google.com/cdn). I'm not sure on the SNI part, but like you I assume that's the case.
Edit: Nope! A little birdie pointed out to me that since "each HTTP(S) LB gets its own Anycast VIP, so there's no need for SNI."
Edit: Nope! A little birdie pointed out to me that since "each HTTP(S) LB gets its own Anycast VIP, so there's no need for SNI."
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).
[deleted]
[deleted]
Don't use it if you have customers in China. They won't be able to access it.
are you sure? everyone has customers in China.
I'm not sure you understand his comment.
then explain it. what point is in a cdn that will do nothing for your chinese customers? or it will still work but be slower?
What s/he's saying is that because GCP runs on a Google network, it's blocked by the GFWoC.
[deleted]
[deleted]
[deleted]
[deleted]
Anyone want to start a pool on how long until Google shuts it down when it doesn't end up as #1 in the market?
I'll take the opposite side of this. What are the terms?
You can't have a convincing cloud story without CDN. I'm an Azure guy but Google's investment here is clear. I'll take that bet.
So just radical changes to pricing then? And cutting of features of course.
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...")
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.
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.
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.
Good. Now when will Google shut down this service?
Never. As always. DVMB.
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.
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?