Ah, that nasty AWS vendor lockin. Guess I'll just run my own CDN then, shouldn't be hard (can't use other vendors, because lock-in). L'il ol me running edge nodes all over the five continents where we have clients. I'll have it done by closing time today.
AWS is more than just compute cores, and you're hand-waving away what it offers.
To be fair though, even with a setup like this you can still use Cloudfront, or any number of other 3rd party CDNs. Most of these providers including Cloudfront offer 'remote origin' features/configurations.
I agree that AWS offers much more than hosting, but when talking about hosting specifically the numbers are clearly better with 'bare metal' (rented or otherwise) -- it's just substantially more power per dollar. You'll need to do a cost-benefit for your own situation so YMMV of course, just as it would with any other provider or any other service your business may choose to subcontract.
I think it’s clear what was intended. Nobody disputes that targeted uses of third party infrastructure services can be appropriate. After all, it’s relatively easy to migrate a service to a new CDN - but it’s a lot harder to migrate from AWS when it’s a core part of your application architecture!
I'm just tired of seeing Yet Another AWS Debunking on HN that is solely concerned with hardware specifications and ignores the myriad of other reasons someone might go for AWS. Particularly someone who doesn't have access to 10+ year veteran neckbeard skills.
The CDN offering is one of the most commodity and portable services available. Plenty of different CDNs on the market that all support any origin.
If you're talking about actually running a global application then that would be a scenario where a network like Google's or Softlayer's does help by having 1 giant VLAN.
In fact, if you are using AWS you really ought to put a proper caching CDN in front, given the crazy high bandwidth prices at AWS.
The bandwidth prices are high enough that I at one point mulled over setting up an "S3 compatible" storage service using S3 as the backend for durability, but storing a single local copy to most-of-the-time avoid hitting S3.
S3 bandwidth prices are high enough that there are huge cost savings to be had if objects are retrieved reasonably regularly.
I think the comment does ring true in many cases however, where a minimal infrastructure is more than sufficient. We recently received notice that an EC2 instance was being retired and we needed to relaunch. It had no load balancing; it was just an m1.medium with a standard Java app on Ubuntu, with a static IP address, and it ran for like 5 years. No elasticity etc. Essentially 1:1 for a standard "old school" setup.
AWS is more than just compute cores, and you're hand-waving away what it offers.