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.
We'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! :)
I 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.
This 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.
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?
- 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.
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.
On a systems engineering level, keeping a system in a state of low entropy for a prolonged period of time will always be harder than a state of higher entropy. In practice, this comes down to more complexity in the software involved, and the people required to make the machine go boop will inevitably higher, since you need to maintain the servers and the complicated stack on them.
The 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.
The 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.
IMO it’s rather sad that virtualization with native-like performance isn’t available on ordinary cloud instances. Getting nested virt or some kind of hypervisor-assisted partitioning working is hard but far from insurmountable.
For 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.
I'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.
Don’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.
I 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.
I’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?
there 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.
Absolutely not defending fly.io. OP is migrating off fly and in my personal experience, Hetzner is not a good option. Maybe OVH, AWS, GCP, Azure, Render, Digital Ocean, or linode.
How is it you can have a good experience, and yet my negative experience somehow doesn't qualify and you're insinuating the issue is with me, and not Hetzner?
This happens with every provider. One thing you're seeing is just that people with 5- and 1- star reviews have a lot of motivation to post reviews. People tend not to be motivated by "meh it's fine" feels.
> 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.
Whether 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.
True, 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.
For the record, hetzner cloud also has multiple data centers (at least in Europe, haven't checked for US) with sharedand load balancers . What you don't get is managed services like k8s, databases, sqs, lambda/faas. These are generally easy to setup via preconfigured Terraform or ansible scripts, but if something goes wrong, you'll have to look at the logs yourself - that's true. (But that's ignoring that such a small team as you're proposing would likely be better served with a more mundane setup, avoiding all of these extra points of failure you'll have to manage... Making a simple bare metal setup once again the less involved and better performing alternative)
Im pretty sure you're vastly underestimating the amount of performance you get from today's hardware.
You won't be a small team by the time you're at a scale to need horizontal scaling. Only the biggest consumer facing/social media sites get value from that.
If you cannot tolerate downtime you need a redundant load balancer and you need nodes in different datacenters. Scale really doesn't matter in this equation. Now maybe you don't need five-nine's so then the risk is worth keeping it simple.
I read it. Historically Hetzner has been popular in the dedicated server space. I cannot speak to their IAAS/cloud offerings, I have never used them. I will take them for a spin, though, seeing as it is really the only way to use their services in the US with good latency.
Hi, professional sysadmin here. I've run production deployments across hundreds of machines in Hetzner; it scales fine. The only real problem is that Hetzner is so much cheaper than anything else that it's easy to get a little bit stuck. (Honestly, that was a fun job in a lot of ways. Oh well.)
Never said it couldn't be done. I forgot that they have ventured into the iaas space and are doing more than just dedicated boxes now. For a small startup with a simple app, managing five dedicated nodes and building your own orchestration on top of deployments, load balancing, networking etc feels like the juice ain't worth the squeeze. For their cloud offering, it is more compelling.
