4 ms·
It's unfortunate that the solution to cloud pricing complexity that all providers are adopting is – add even more complexity on top. The number you see on your
by paxys 2y ago
It's unfortunate that the solution to cloud pricing complexity that all providers are adopting is – add even more complexity on top.
The number you see on your bill is increasingly calculated by running some black box algorithm on top of the billing events your resources generate. Was it accidental or not? What is a "weird" deployment vs a normal deployment? By what factor should the spikes on your billing graph be smoothened? None of this can be deterministically calculated from the pricing page. And there's no way for you to do these checks yourself before deployment because you have no idea what this logic even is. So you are entirely at the mercy of the provider for "forgiveness".
Who wants to bet that some provider is going to launch "AI cloud billing" within the next year?
- bdcravens 2y agoIt's far from perfect, but the large providers do give you tools for categorizing your charges (tagging, etc). There's some fuzziness, especially around data transfer, but for the most part developers can look at an application and know what the cost of each resource is. The biggest risk seems to be out-of-control auto scaling turned on without doing reasonable analysis first.
- candiddevmike 2y agoYou'll pay exactly the amount they think you can afford to pay and not a penny less.
- tptacek 2y agoThat would be what you would pay in the absence of competition. This is an incredibly competitive space.
- paxys 2y agoCompetition only matters for new contracts. Once you have picked a provider and made a big enough infrastructure investment, there's no realistic path to switch to someone else.
- toast0 2y agoIt really depends on what your application is and how much critical functionality relies on hard to replace proprietary services. If you store a lot of data, transfering it is a big deal too, of course. But really, computers are computers. It's easy to move software between them. It just takes motivation, effort, and time.
- paxys 2y ago> It just takes motivation, effort, and time In business terms, you just said "cost, cost and cost".
- javcasas 2y agoThey laugh at me for constructing as much as I can from the infra as plain kubernetes objects. Keep laughing, I can switch clouds in less time than you take for figuring out cloud costs.
- commercialnix 2y agoKeeping everything, including mission critical databases, "inside" Kubernetes is smart. The smart people keep everything "in" Kubernetes. Everyone else can pay up.
- filleokus 2y agoLike everything else it's a tradeoff. If you are running _everything_ inside Kubernetes you can easily move away, but I think you're loosing much of the benefit of being in the $big_cloud to begin with. If you have the staffing to provide your own db's, block storages, caches, IAM, logging/monitoring, container registries etc in a reliable way "as a service", the jump to some much cheaper bare metal hosting is not that far. For me the sweet spot is to have all compute in Kubernetes and stick to open source or "standard" (e.g S3) services for your auxiliary needs, but outsource it to the cloud provider. Fairly easy to move somewhere else, while still keeping the operational burden down. But agree that having e.g all your databases in a proprietary solution from the cloud vendor seems sketchy.
- immibis 2y agoThen how do AWS, Azure and GCP charge 100 times the amount for bandwidth as other hosting providers and the IP transit quote sitting in my email inbox?
- toast0 2y agoIMHO, there's a couple parts to this. Part 1 is bandwidth prices vary tremendously by location, but clouds would like to have customers in expensive regions too, and if US overcharges at 100x, and Brazil overcharges at 25x, the customer will only have to pay 2x for bandwidth in Brazil. Not a lot of cheap hosting in Brazil, from what I've seen, but there are a lot of users in Brazil, attracting cloud customers justifies putting more cloud hardware there which benefits the cloud. The other part is that bandwidth is easy to measure and broadly correlates with general usage. On a shared system, you can't really meter watt hours, but you can meter bandwidth. Bandwidth charges are how the difficult accounting is reconciled so that the cloud can charge enough to hit their desired margins. If bandwidth was just a cost plus, other things would cost more; if everything had to be cost plus, accounting would be much more difficult for everyone (and it's already pretty non transparent)
- tptacek 2y agoWhy isn't one of those providers roflstomping the other 3 (add OCI to the mix) with better pricing?
- jeremyjh 2y agoI've often wondered about this. I'm guessing large customers can all negotiate extremely deep discounts on bandwidth from all three providers. Smaller customers may not be paying that much in bandwidth that it would be decisive. I think also that if say GCP cut its bandwidth charges by 10x they might attract customers they really don't want.
- pclmulqdq 2y agoBecause they land your data in their systems by offering you a sweetheart deal in year 1-2 and then they jack the price back to the extortionate level once you're stuck. Compute is portable between providers, but data is not.
- kibwen 2y agoIf the cost calculation is complex and opaque, that successfully prevents anyone from evaluating what their costs would be on a competing service. And vendor lock-in makes it expensive and nontrivial to simply try it out.
- thenewnewguy 2y agoI'd recommend thinking of this (and other accident forgiveness schemes from competitors) as a gesture of goodwill that rarely happens rather than an official part of the billing policy. If you actually look at your contract, no cloud provider is going to contractually obligate themselves to forgive your bill, and you shouldn't be planning or predicting your bill based on it.
- monooso 2y agoIsn't the entire point of the article that Fly.io is making this an official policy?
- ToucanLoucan 2y agoAnyone else remember we had widely available and completely understandable options to rent everything from baseline web-hosting all the way up to private rack services for actual years before AWS came along and apparently all of that was forgotten, Warhammer 40K style? I've rented a VPS from a vendor for going on 20 years now (Holy fuck I'm old) and I've never once been surprised at the bill.
- LAC-Tech 2y agoRemember? Your own comment tells us this is not a distant memory! It is still available! And a lot of people use it.
- maliker 2y agoYou know that book "JavaScript: The Good Parts"? There needs to be a similar one "AWS: just the good parts". It would probably talk about EC2 (VPS), S3 (cheap bulk storage), SES (emails), and that's about it. When folks get into the elastic-super-beanstalk-container-swarm-v0.3 products, that's when they really kill themselves on the bills. That said, yes, just using a VPS vendor is the easy way to stick to the good parts.
- Aeolun 2y agoI’ll argue that while wonky sometimes, ECS is pretty decent. Especially once you use fargate.
- ec109685 2y agoAWS the Good Parts (a bit dated now): https://dvassallo.gumroad.com/l/aws-good-parts https://dvassallo.gumroad.com/l/aws-good-parts
- otteromkram 2y ago> "AWS: just the good parts" I can't imagine a zero-page book selling well...
- StimDeck 2y agoObviously subjective, but Lambda seems more cost efficient than EC2. And really gives cloud vibes.
- rob 2y agoSpeaking of complexity, Fly.io recently introduced region-specific pricing as well: https://community.fly.io/t/region-specific-machines-pricing/20690 https://community.fly.io/t/region-specific-machines-pricing/... https://news.ycombinator.com/item?id=40873001 https://news.ycombinator.com/item?id=40873001