5 ms·
This is painful, I was building for fly.io because of their dynamic request routing but I'm thinking I'm just going to go with hetzner. The cost difference is s
by brigadier132 2y ago
This is painful, I was building for fly.io because of their dynamic request routing but I'm thinking I'm just going to go with hetzner. The cost difference is so substantial. If I want high availability I can just get 5 servers and have that much more compute available and I'd still end up paying less.
- danpalmer 2y agoThis same argument applies to most cloud hosting, non-cloud (or less cloudy, Hetzner is a little cloudy) will always be cheaper because the service is more basic in a number of ways. Fly’s pitch is not just on demand scalable compute, but also that compute being close to the edge, and with “ops-less” deployments. All of those are factors you pay for. You could pay a little less with a big cloud provider’s serverless platform, a bit less again with regular cloud VMs, a lot less with colo hardware, and a ton less running your own DC (at scale). Obviously not all of these work for all businesses, but saying Hetzner is cheaper than Fly misses the point of those two services on the spectrum of service levels.
- deleted 2y ago[deleted]
- brigadier132 2y agoI'm not missing the point of the service, I'm against the idea of infrastructure being an 84% margin business. But I guess this is what the VCs demand and some are willing to pay it.
- candiddevmike 2y agoFor a lot of people (most...?), Hetzner gives them exactly what they're looking for at an excellent price point. As an ecosystem, we never really moved past VMs, we just went up the stack more.
- jstummbillig 2y ago> will always be cheaper This has me so confused. Should the cloud abstractions not clearly make the service more optimizable at scale and thus cheaper to offer? Sandboxing things, limiting options, not having to deal with users wanting to provision VMs and do all kinds of unexpected stuff? The marginal cost of the beautiful software to make all of that happen smoothly, and all the dx it affords, that will just go towards 0, no? I understand that people ask for what they can get away with. But does the market fail or am I missing a piece of the cost/price puzzle?
- arccy 2y agoThe tooling for managing the "lower" layers is progressively worse / slower / harder the closer to the metal you get, so you usually are paying a heavy premium for convenience / DX. Only very specific serverless products where the provider can bin-pack you with other tenants allow them to possibly offer lower prices.
- filleokus 2y agoInteresting take. At one side, the big cloud providers have their very fair profit margins. But I've always assumed that comes mostly from that they can, and do, charge extra for the beautiful software (not seldomly through ridiculous egress bandwidth pricing). I'm skeptical of how much flexibility and optimisation the big cloud providers really get compared to a very large VPS provider? All the compute products (different form of container hosting, serverless) are essentially still priced at CPU+RAM + a premium. Some additional abstraction for nouveau databases ("capacity" or "billing" units). Many of the highly abstracted offerings also have the scale-to-zero concept, while the provider still have to have physical capacity ready (to some extent). Sure, you can probably crank out some percentage more utilisation, but that doesn't really matter for the 100+% price-add on the market bears. But I of course have no data to back up my claims, just speculation.
- cle 2y agoNo it won't reach 0, for many reasons. - Things change and break. You are paying for people to fix that for you at 2 AM, and to keep up with industry developments and best practices and make those decisions for you. - Legal risk and compliance requirements change. You are paying for them to keep up with those for you. - Overhead imposed by multi-tenancy. Security boundaries, control planes, etc. These are fixed operational costs caused by the abstraction. You're not paying for just an abstraction, you're paying for the things the abstraction enables. It's also not always what you need. But it often makes good business sense.
- tptacek 2y agoThe sandboxing (by way of example) is a hardware affordance, not a software feature. In order to hardware virtualize every instance running on Fly.io, we have to provision hardware globally; we can't run customer jobs in namespaced userland containers under a shared kernel on cloud-provisioned hosts.
- hipadev23 2y agoDon’t host anything important on Hetzner, as they’re cheap they get a lot of questionable users, and their systems are tuned to null route anything that looks remotely suspicious or high-volume to their hair-trigger network monitoring and DDoS protection. And then you’re at the mercy of whatever support agent decides to look at your ticket and that can take days. Use literally anyone but Hetzner is my advice.
- matdehaast 2y agoI've been using it for years with high bursty loads from users. Never had an issue with network stuff between my user and hetzner....
- throwAGIway 2y agoI disagree, the support is very responsive. Try to let them know in advance about your plans and you will be fine.
- js4ever 2y agoI disagree, at my company (elest.io) we have several thousands VMs with Hetzner and reliability is very comparable to AWS from our internal stats. In case of DDOS attack we get notified and can discuss with their team. Also support is competent and quick. We usually get an answer in few hours most of the time.
- hipadev23 2y agoI’m glad you’ve had a positive experience, maybe it’s the usage level that grants you that treatment. As a one-time new client I had the worst possible experience with them: null routed my game server on launch day, very slow to respond support team, and effectively held my server hostage for 3 days. I guess I needed to inform them I was intending to use the server I paid for? Took my data and never returned.
- itake 2y agothere is no way Hetzner is worse than fly for uptime. Fly has deleted my db, taken servers offline for hours, and expired tls certs for hours without telling me.
- whalesalad 2y ago> If I want high availability I can just get 5 servers and have that much more compute available and I'd still end up paying less. Please give us an update here when you are done building your hetzner beowulf cluster and let us know how it fares. I think you are grossly underestimating the system you describe.
- brigadier132 2y agoI don't want a cluster, I just want a load balancer that can connect users to the machine I want.
- iampims 2y agoIf the LB is for HTTP traffic, check out Cloudflare’s offering.
- zamadatix 2y agoWhether this is completely out of the box or a multi-year engineering project to get equivalent levels of utility in the long term is completely up to how one specifically uses Fly.io. E.g. a load balancer in front of some relatively stateless http microservices is really not going to tie you to Fly.io because of complexity. A globally distributed edge compute environment with database, RPC, varying scaling patterns, and environment certifications is probably not going to have the value prop impacted by this kind of minor pricing change though.
- whalesalad 2y agoTrue, but managing 5 servers requires overhead. Where does the load balancer sit? What happens when it goes down? What if the entire datacenter loses comms? That is why cloud providers have AZ's that are physically separated from one another at different sites. When your boxes are spread across different physical networks, how do you connect them securely? For true HA you need a system that can self heal. Just throwing servers at the problem does not make things better. Reminds me of the expression 9 women can't make a baby in 1 month. None of this is impossible, but when you are a small startup it makes sense to offload this to someone else and not waste time reinventing the wheel.
- tptacek 2y agoWe're sorry. I hope we're clearly expressing what's happening here: either we do flat pricing globally, so that people deploying in cheaper regions subsidize those deploying in more expensive ones, or we reflect our cost basis in our prices and let our customers (and prospective customers, like you) make their own choices. In your specific situation: it really just is the case that Brazil soaks us on import fees. Getting machines in racks in Brazil is just crazy expensive. We're going to keep doing it! Brazil has too many good sandwiches. But the idea behind building a new public cloud on our own hardware is for us to be around for the long haul, and flat low global pricing is not a "long haul" decision. (It wasn't a long haul decision last year, either, but building a billing system capable of expressing this stuff is a nightmare from which we have not yet fully awoken. It turned out to be a shockingly hard problem.) There are going to be cases where places like Hetzner make a lot sense compared to us. We hope you get your thing launched and find success wherever you end up. Some of our stuff, like LiteFS, you can take with you! :)
- athoscouto 2y agoI think the change makes sense, even though I have workloads running on the regions that got the steepest price changes. I'd rather have more granular pricing than a blanket increase. The why now also makes sense - there was a technical limitation that doesn't exist anymore. I was expecting a larger grace period from announcement to price change though. You got it right when you started charging for stopped volumes - you overcommunicated and gave users estimates for a few months before you started charging. Smoothing the increase over the next 4 months was nice. A couple of nits as well: - AFAIK prices increased in all but two regions. The announcement could be clearer or more direct regarding this. - The pricing page could have a clearer from/to. I have to click on the example toggle to know how much machines cost before the change.