News for hackers. Stuff that matters.
Re:Docker operations slowing down on AWS by vacri on Wednesday July 26, 2017 @01:58AM (#14853934)
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.

Re:Docker operations slowing down on AWS by adanto6840 on Wednesday July 26, 2017 @02:06AM (#14853953)
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.

Re:Docker operations slowing down on AWS by matthewmacleod on Wednesday July 26, 2017 @02:12AM (#14853976)
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!
Re:Docker operations slowing down on AWS by vacri on Wednesday July 26, 2017 @03:20AM (#14854214)
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.
Re:Docker operations slowing down on AWS by manigandham on Wednesday July 26, 2017 @04:12AM (#14854401)
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.

Re:Docker operations slowing down on AWS by pbarnes_1 on Wednesday July 26, 2017 @05:40AM (#14854792)
CloudFront is one of the worst CDNs out there, so this isn't really a good point.

Any CDN can be stood up in front of a small fleet of dedicated hosts, and you'd still be saving 80%.

Re:Docker operations slowing down on AWS by vidarh on Wednesday July 26, 2017 @08:06AM (#14855446)
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.

Re:Docker operations slowing down on AWS by vacri on Wednesday July 26, 2017 @07:33AM (#14855283)
It was just a simple example that AWS is more than compute cores and disk space.
Re:Docker operations slowing down on AWS by bdcravens on Wednesday July 26, 2017 @02:13AM (#14853978)
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.
Re:Docker operations slowing down on AWS by not_kurt_godel on Wednesday July 26, 2017 @02:22AM (#14854010)
In other words, not really an appropriate (or at least not cost-efficient) use of EC2. EC2 != VPSes