DO NOT USE HETZNER
they actively seem to hate their customers and will delete all your data at some junior interns whim
Migrating from AWS to Hetzner
621–630 of 643 posts
Re: Migrating from AWS to Hetzner
#622I cannot overstate the performance improvement of deploying onto bare metal. We typically see a doubling of performance, as well as extremely predictable baseline performance. This is down to several things: - Latency - having your own local network, rather than sharing some larger datacenter network fabric, gives around of order of magnitude reduced latency - Caches – right-sizing a deployment for the underlying har…
> We typically see a doubling of performance The AWS documents clarify this. When you get 1 vCPU in a Lambda you're only going to get up to 50% of the cycles. It improves as you move up the RAM:CPU tree but it's never the case that you get 100% of the vCPU cycles.
Sort of. 1 vcpu on x86 = 1 hyperthead not 1 core so yes you can't do uninterrupted work without some CPU "stolen".
However that's not due to aws overhead or oversubscription but x86 architecture. For production workloads 2 vcpu should be minimum recommendation.
On ARM where 1 vcpu = 1 core it is more straightforward.
Re: Migrating from AWS to Hetzner
#623Earlier quoted context omitted.
Downside with that is having DNS, managed databases, cloud storage (s3) outside K8s - When deployments are also managed with tf, it's easy to connect a deployment in K8s to resources outside K8s (via tf state).
You can still do that by reading the values you need directly from the state file. I suggest that you define outputs and access them through the state file from other projects, otherwise the external dependency will be hidden.
And splice into deployment definitions via something like kustomize?
Re: Migrating from AWS to Hetzner
#624Earlier quoted context omitted.
> What is old is new again. Over the years I tried occasionally to look into cloud, but it never made sense. A lot of complexity and significantly higher cost, for very low performance and a promise of "scalability". You virtually never need scalability so fast that you don't have time to add another server - and at baremetal costs, you're usually about a year ahead of the curve anyways.
If you’re just running some CRUD web service, then you could certainly find significantly cheaper hosting in a data center or similar, but also if that’s the case your hosting bill is probably a very small cost either way (relative to other business expenses). > You virtually never need scalability so fast that you don't have time to add another server What do you mean by “time to add another server?” Are you thinkin…
Weeks. I'm talking about multiple business weeks to spin up a new server. Sure, in a pinch I can do it in a weekend, but adding up all the stakeholders, talking it over and doing things right it takes weeks. It's a normal timespan for a significant chunk of extra power - a modern day server from Hetzner comes with over 1Tb of RAM and around 100 cores. This is also where all the reserve capacity comes from - you actually do have this kind of time to prepare.
Sure, there are scenarios where you need capacity faster and it's not your fault. Can't think of any offhand, but I imagine there are. It's perfectly fine for them to use cloud.
Re: Migrating from AWS to Hetzner
#625Earlier quoted context omitted.
You can still do that by reading the values you need directly from the state file. I suggest that you define outputs and access them through the state file from other projects, otherwise the external dependency will be hidden.
And splice into deployment definitions via something like kustomize?
It depends on your use case what the best option would be. You can put variables into kustomize templates and replace them via envsubst. For helm charts you can just supply the values for the variables during the install / upgrade.
Another possibility would be to create a ConfigMap with the values you read from the state file.
Re: Migrating from AWS to Hetzner
#626Earlier quoted context omitted.
No, cloud adoption was driven by teams having to wait 2 years for capex for their hardware purchase and then getting a quarter of what they asked for. You couldn't get things, people hoarded servers they pretended to be using because when they did need something they couldn't get it. Management just wouldn't approve budgets so you were stuck using too little hardware. On the cloud it takes five seconds to get a new m…
This. Instant availability of compute and storage, purchasable with a corporate credit card, was the cloud killer app.
I can't have instant ressources, azure Switzerland is overbooked and can't create much ressources, at two different clients.
And I read something similar for AWS.
And in most "large" companies, you still need to go to different teams and processes to have those cloud ressources.
Oh and if your company made the mistake to outsource their IT, odds that you'll have a 4 digit bills to change a teraform.
Welcome to Western Europe.
Re: Migrating from AWS to Hetzner
#627Earlier quoted context omitted.
Because that is a casual word in the English language to describe an object with substantial power? If you would suggest a word that would make a better substitute in this case, that could move the conversation forward, and perhaps you could improve the aesthetic quality of posts about leaving the cloud.
Well, I wouldn't say I have a beefy car or a beefy sword: there's some historical bit of linguistic connection that seems to have caused people to describe a server with the adjective "beefy", rather than "powerful", "hefty", "stacked", or... "chonky" ;P. Coming up with some options, I think my favorite might be "cranked"?
[dead]
Re: Migrating from AWS to Hetzner
#628Earlier quoted context omitted.
People are usually the biggest cost in any organisation. If you can run all your systems without the sysadmins & netadmins required to keep it all upright (especially at expensive times like weekends or run up to Black Friday/Xmas), you can save yourself a lot more than the extra it'll cost to get a cloud provider to do it all for you.
Exactly, for the narrowly defined condition of running k8s on digital ocean with a managed control plane compared to Hetzner bare metal: AWS and DigitalOcean = $559.36 monthly or Hetzner = $132.96 The cost of an engineer to set up and maintain a bare metal k8s cluster is going to far exceed the roughly $400 monthly savings. If you run things yourself and can invest sweat equity, this makes some sense. But for any com…
That argument is compelling only at a first glance IMO. If you take a look at it another way then:
1. The self-hosting sweat and nerves are spent only once, 80% of them anyway (you still have to maintain every now and then e.g. upgrade).
2. The cloud setup will require babysitting as well and as such the argument that you only pay someone salary when self-hosting does not hold water.
Ultimately it's a tradeoff between (a) the short- or long-term thinking of leadership, (b) in-house expertise and (c) how much money are you willing to throw at the problem for the promised shorter timelines -- and that one is assuming you'll find high-quality cloud hosting engineers which, believe me, is far from a given.
Re: Migrating from AWS to Hetzner
#629Earlier quoted context omitted.
Yeah I always just kinda laugh at these comparisons, because it's usually coming from tech people who don't appreciate how much more valuable people's time is than raw opex. It's like saying, you know it's really dumb that we spend $4000 on Macbooks for everyone, we could just make everyone use Linux desktops and save a ton of money.
> It's like saying, you know it's really dumb that we spend $4000 on Macbooks for everyone, we could just make everyone use Linux desktops and save a ton of money. Ohh idk if this is the best comparison, due to just how much nuance bubbles up. If you have to manage those devices, Windows and Active Directory and especially Group Policy works well. If you just have to use the devices, then it depends on what you do -…
Sorry for off-topic but IMO MacBooks started losing value hard since the release of macOS Tahoe.
They were super fast, now part of them are sluggish.
As much as people hate to hear it, Apple is finished. They peaked and have nowhere to go. AI bubble is not going to last more than 1-3 years still, and Apple's inability to make a stable OS upgrade that doesn't ruin people's machines performance puts them in a corner.
Combine this with the fact that MS announced end of support for Windows 10 and both these corporations ironically start to make a strong case for Linux.
Is Linux desktop quite there? Maybe not fully but it's IMO pushing beyond 80% and people who don't like Windows and macOS anymore are starting to weigh their options.
Re: Migrating from AWS to Hetzner
#630Earlier quoted context omitted.
Seems like a few negotiation skills would be of better use than doing extreme amounts of work so somebody can take months on approving new hardware. Well guess what, the people that did slow down hardware procurement are now slowing down deployment of cloud resources as well because the fundamental problem wasn't addressed and that's organizational misalignment and disfunction.
Even if you can get instant approval, Dell or HP won't Fedex you 50 servers next day like they will 50 laptops. And once you're a customer you get to deal with sales channels full of quotes and useless meetings and specialists. You can't just order from the website.
You can get servers elsewhere as well and they can be more agile than Dell/ HPE/ SuperMicro/ Lenovo. Asus, Asrock, Gigabyte and some other brands can ship servers rather quickly. Perhaps not the next day but the prices are much lower out of the door especially if you are a smaller customer. Most companies know well in advance how much compute/ storage they will need. So if something takes a month or two it isn't a big issue.