16 ms·
One major thing this doesn't consider is the technical limitations which are latency & bandwidth. (1) You save a ton of money on bandwidth when you move data
by parhamn 7y ago
One major thing this doesn't consider is the technical limitations which are latency & bandwidth.
(1) You save a ton of money on bandwidth when you move data from AWS to AWS
(2) Your stack, in most cases, needs to be near each other to minimize latency. Databases get wrecked by this.
This is why, cloud database providers have to often transparently show you which cloud you're launching on [1] which effectively means AWS is going to get a good share of it anyway. My uninformed guess is that EC2&S3 are by far their biggest money maker which is going to be what unbundlers target.
I'm all for the unbundling and will probably take part in some of it, but I don't think it will be that easy.
[1] https://www.cockroachlabs.com/product/cockroachcloud https://www.cockroachlabs.com/product/cockroachcloud
- jnwatson 7y agoBandwidth/latency was my first thought too. Still, for higher-level services, it is entirely possible to compete with AWS running on lower-level AWS infrastructure, rendering the network issues moot.
- whoevercares 7y agoWell any other AWS service almost exclusively built on top of EC2/S3, so it’s safe to say it drives all of AWS revenue either directly or indirectly. Probably some service’s use EC2 instance hours as its revenue measure
- zwkrt 7y agoI think the real moneymaker is that AWS keeps making their servers more efficient but doesn’t lower their costs
- stornetn 7y agoIsn’t AWS fairly widely reputed for having lowered its prices dozens of times since first launching? https://aws.amazon.com/blogs/apn/new-research-from-tso-logic-shows-aws-costs-get-lower-every-year/ https://aws.amazon.com/blogs/apn/new-research-from-tso-logic...
- adrianmonk 7y agoI thought the article was talking about avoiding cloud vendor lock-in by using software that keeps you portable between clouds. (Instead of software that dictates that you buy from a certain cloud provider.) Couldn't you build your software stack in a cloud-portable way but, at any given time, still have 100% of it on whatever your current cloud provider is? And then switch to another cloud provider from time to time if/when the costs make it worthwhile.
- coredog64 7y agoYes you can, but it’s very difficult and not worth the effort IMO. The first problem is that you wind up using the least common denominator. You’re paying public cloud providers a premium, so this essentially equates to throwing away money. The second is that there are some cases where what seems like the same thing isn’t, or best practice is wildly different between providers. Get in a room with an AWS expert and an Azure expert and talk about what an account is.
- adrianmonk 7y agoYou raise a good point. Upon re-reading, portability to a different cloud is probably not the point. It's more likely about being on the cloud you're already one but having the choice to take only parts of the platform, instead of taking Amazon everything at every layer of the stack. So you're still on Amazon or whoever's cloud, but you may not use (for example) their database if you like some other database. In other words, it's not about moving your entire stack off Amazon's cloud, it's about moving parts of your stack off Amazon's software even if all of it may still run inside Amazon's cloud.
- marcinzm 7y ago>avoiding cloud vendor lock-in You're simply moving from being locked in by AWS to being locked in by a bunch of much smaller cloud vendors.
- ndm000 7y agoThird parties like Snowflake get around this by having you pick where their service is hosted so that bandwidth and latency aren’t a concern. Further, Snowflake is a good example of an unbundled service that has more capabilities than AWS Redshift (for instance, zero copy clones). They use AWS for infrastructure - the entire warehouse is stored on S3 - and value add on top of it.
- petra 7y agoIf a company needs an almost commodity software, like most companies, it's clear that over the long term, AWS will win on reliability and probably price over an AWS startup. So why choose differently ?
- jjoonathan 7y agoBecause AWS knows that many of their customers think like this and pursues ever more minimal Minimum Viable Products accordingly. Their quality is dismal and it stays that way over the long term. AWS's killer feature has nothing to do with tech, it's the smooth billing process (techies choose, management pays and supervises). If you can put together a smooth process for paying for 3rd party software in your organization, you can unlock massive improvements in quality for a pittance.
- BurritoAlPastor 7y agoThere is nothing smooth about AWS's billing; it's notoriously byzantine, and so difficult to interpret that there are multiple third-party services whose entire offering is based on ingesting and parsing your AWS bill.
- solidasparagus 7y agoThe value of AWS billing isn't that it's easy, it's that the spending decisions are in the hands of the right people so software development moves faster.
- buboard 7y agoArent there many providers with unmetered bandwidth, in nearby datacenters?
- ec109685 7y agoAWS always charges for outgoing bandwidth. Unfortunately, they aren’t part of this: https://www.cloudflare.com/bandwidth-alliance/ https://www.cloudflare.com/bandwidth-alliance/
- toast0 7y agoAll of the unmetered bandwidth offers I've seen come with low link speeds like 100Mbps or sometimes even 10Mbps. Paying for use isn't awful, as long as you're not paying AWS list prices which are rather high.
- buboard 7y agoall hetzner servers are guaranteed 1Gbit
- privateSFacct 7y agoYes - hetzner supposedly pushes 324TB/month for something like $30/month INCLUDING the server itself. So let's say $15/month for the bandwidth. AWS is lets say .08 per GB or $30K/month for same bandwidth? And if you beleive you can run your business on their $15/month network then they would own the market - but oddly they peer with basically NO ONE of any quality - because THEY don't actually pay for the bandwidth either and just totally oversaturate their peering links. https://forum.wurmonline.com/index.php?/topic/150107-network-lag-in-germany/&tab=comments#comment-1537724 https://forum.wurmonline.com/index.php?/topic/150107-network... for some of the common whining at least in the past.
- dx034 7y agoMy experience is a bit different. Peering works pretty well to many providers, especially with Cloudflare. The big disadvantage of Hetzner is that they're located in Germany and Finland only, so not great if your customers sit in the US. But OVH Canada provides reasonable options for that.
- gz5 7y agoGood points. Would add that edge compute, running cloud paradigms (code instead of config; automation; management abstractions), partially addresses these limitations for many use cases. Costly to move the data off, but longer-term ROI for those orgs that are willing to make long-term decisions. Meanwhile, as edge matures, greenfield apps should be edge-centric, rather than cloud-centric (doesn't mean they won't have cloud components...they will do the processing and storage where it best makes sense).
- driverdan 7y ago> You save a ton of money on bandwidth when you move data from AWS to AWS This is only because AWS grossly overcharges for bandwidth. If you move all services that have high bandwidth requirements to providers with reasonable prices you'll save a significant amount of money.
- phamilton 7y agoWithin a single AZ. Inter AZ is charged. It's also frustrating that AWS infra doesn't optimize for same AZ (and only fall back to another AZ if an AZ is impaired). For example, a client in us-east-1a can hit the Aurora reader endpoint and be directed to an instance in 1b even though there's a healthy instance in 1a.
- papito 7y agoA consultant on Twitter recently posted how a client got a bill for more than $100,000 because they unwittingly had a multi-AZ Kubernetes setup and moved a ton of data that way.
- deleted 7y ago[deleted]
- rhizome 7y ago1) Doesn't Amazon charge for ingress and egress transit, and isn't this unusual, and isn't it more expensive that way? I could have swore I recently calculated AWS transit to be something like 20x the cost of that in a normal colo datacenter. Maybe there's something in AWS billing where this only comes into play when you cross certain technical boundaries, I don't know enough to say, but I'm thinking it would have to be something like that in order to "save a ton of money." 2) Contemporary site/app development renders the latency of individual requests irrelevant. The whole page is going to boop and bounce around for 20 seconds anyway, why make a big deal about it? The web is a measurably worse experience now than it was 10 years ago (maybe even 5), so it's ironic that Goodhart's Law has led so many astray toward measuring smaller and smaller trees within a growing forest. "Well but we have to get the request for number of friends below 10ms" while the other 400 requests on the page are dilly-dallying and experiencing their own latencies. Then the CSS gets applied.
- kikoreis 7y agoAmazon consistently charges for egress only. Ingress is free.
- asheldon 7y agoThis is not true for inter-az bandwidth. https://www.lastweekinaws.com/blog/aws-cross-az-data-transfer-costs-more-than-aws-says/ https://www.lastweekinaws.com/blog/aws-cross-az-data-transfe...
- kikoreis 7y agoLive and learn, that seems to be the exception. That sounds like it might be an accident though?
- slovenlyrobot 7y agoTheir inter-AZ pricing is certainly no accident. I'm betting for a large chunk of custs it nets them something on a par with egress