Live data from Hacker News

Hetzner Introduces ARM64 Cloud Servers

hetzner.com

321–330 of 342 posts

Re: Hetzner Introduces ARM64 Cloud Servers

#321
post #315

Earlier quoted context omitted.

> This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add br…

While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.

> While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole (...)

Nonsense. Each team owns it's services, and they know best what works and doesn't work. It makes no sense to claim organizational inertia as a valid reason to prevent you from picking the best tool for the job.

To add to that, microservices allow you to gradually upgrade services without having to be blocked by the idea of having to go through major rewrites. You just peel off a concern, get it up and running, and direct traffic to it. Done.

Re: Hetzner Introduces ARM64 Cloud Servers

#322

Earlier quoted context omitted.

A simple single node is often more reliable than a complex fault-tolerant setup. Fewer moving parts mean fewer broken pieces. Similar with security. A simple monolith is more secure than isolated front- and backend.

> A simple single node is often more reliable than a complex fault-tolerant setup. ...except when your single piece breaks and you get your whole service down. Then what?

You get it back up and running quickly because it's so simple and easy to deploy a new server and load the backups on to it.

Re: Hetzner Introduces ARM64 Cloud Servers

#323

Earlier quoted context omitted.

> set hard boundaries on responsibilities and accountability while ensuring independent decision-making This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single mac…

> This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add br…

An even more important consideration is being able to release features (and even more importantly roll back) in isolation when the team is ready. The more teams contributing to a monolith, the harder this becomes. I am sure someone here has seen it done with a 10 million line monolith built by 100 geographically distributed teams, but I suspect that is exceedingly rare.

Microservices aren’t a silver bullet for this, of course. They can be part of a winning recipe though.

Re: Hetzner Introduces ARM64 Cloud Servers

#324

Earlier quoted context omitted.

German (and most other?) passports feature the name of the issuing authority and place of birth, no other location, and remain valid irregardless of your current registered address. Side note: It seems like many African ID cards list the profession and I've had to explain to several suspicious border guards why my passport doesn't. EDIT: I've always wondered about this and apparently the body that sets passport speci…

The German Passport has field for your Residence, which is mandatory and needs to be updated when you move. It is generally the general location you live in, usually your city. You can see the field in this official example passport (field 11): https://www.gesetze-im-internet.de/normengrafiken/bgbl1_2017...

Ah, you're right. I guess I never looked at page 2. Never updated it either.

Re: Hetzner Introduces ARM64 Cloud Servers

#325
post #98

More benchmarking. Some of the speedtests coming back >10gigs is a bit of a surprise given price point https://hastebin.com/share/biyejiriyi.bash https://hastebin.com/share/unocorikef.bash https://hastebin.com/share/ujixoxazit.bash https://hastebin.com/share/ofezuyodob.bash

For comparison, here's an AWS a1.large instance (2cpus, 4GB ram) YABS benchmark I just ran https://gist.githubusercontent.com/12932/8ba27254846072a43b0...

and an AWS c7g.large instance

https://gist.githubusercontent.com/12932/8b47af122ba79c79b82...

Re: Hetzner Introduces ARM64 Cloud Servers

#326
post #96
post #28

Earlier quoted context omitted.

The 1 that was mostly canned? See: https://www.anandtech.com/show/15631/intels-cooper-lake-plan... It's limited everywhere.

> The company is set to only make the hardware available for priority scale-out customers who have already designed quad-socket and eight-socket platforms around the hardware. I work at one of those customers; we use loads of them. Nevermind Ice Lake / Alder Lake (2021) / Raptor Lake (2022) -- Intel hasn't abandoned the "Lake" naming scheme yet.

> Nevermind Ice Lake / Alder Lake (2021) / Raptor Lake (2022)

i.e. Skylake+++++

Re: Hetzner Introduces ARM64 Cloud Servers

#327

I implemented a Virtual Private Cloud (VPC) on AWS with Elastic Container Service (ECS) using Terraform so that I could run Docker, and it ended up being about 2 orders of magnitude more expensive than Hetzner after all of the services were configured. For example, something as simple as AWS NAT Gateway costs $30 per month, and it can be challenging to get everything right if you don't use one. I haven't tried Heroku…

"I haven't tried Heroku, but expect similar prices and nearly as high of a configuration burden." Are you kidding me? Prices, sure, but comparing the configuration burden using AWS or GCP alphabet soup to a dead-simple Heroku setup is ridiculous. You set up something like hirefire.io for autoscaling, you connect your Github repo and that's it. You're done. Compared to weeks worth of headaches setting up Terraform Clo…

Ya I think you're right. I regret not trying Heroku first.

I'm glad to have learned AWS, although I don't know that I'll build another cloud server. I think the biggest problem I found is that services tend to require each other. So I ended up needing an IAM for everything, a security group for everything, a network setting for everything.. you get the idea. A la carte ends up being a fantasy. Because of that interdependency, I don't see how it would be possible to maintain a cloud server without Terraform. And if that's the case, then the services just becomes modules in a larger monolith. Which to me, looks like cloud servers are focusing on the wrong level of abstraction. Which is why preconfigured servers like Heroku exist, it sounds like.

An open source implementation of Heroku running on Terraform on AWS/GCP could be compelling. Also a server that emulates AWS/GCP services so that an existing Terraform setup could be ported straight to something like Hetzner or Linode with little modification. With a migration path to start dropping services, perhaps by running under a single identity with web server permissions (instead of superuser). And no security groups or network settings, just key-based authentication like how the web works. More like Tailscale, so remote services would appear local with little or no configuration.

Also this is a little off-topic, but I'd get rid of regions and have the hosting provider maintain edge servers internally using something like RAFT combined with an old-school cache like Varnish to emulate a CDN. The customer should be free from worrying about all static files, and only have to pay a little extra for ingress for the upload portion of HTTP requests for POST/PUT/PATCH and request headers and payloads.

Oh and the database should be self-scaling, as long as the customer uses deterministic columns, so no NOW() or RAND(), although it should still handle CURRENT_TIMESTAMP for created_at and updated_at columns so that Laravel/Rails work out of the box. So at least as good as rqlite, if we're dreaming!

Edit: I don't mean to be so hard on AWS here. I think the concept of sharing datacenter resources is absolutely brilliant. I just wish they offered a ~$30/mo server preconfigured with whatever's needed to run a basic WordPress site, for example.

Re: Hetzner Introduces ARM64 Cloud Servers

#328

Why? What is the advantage of running arm over x86 on servers?

What I want to know is why migrate to ARM when RISC-V is around the corner?

Eventually RISC-V will put them out of business but until that time comes, everyone is free to try to convince people otherwise.

Re: Hetzner Introduces ARM64 Cloud Servers

#329
post #287
post #220

Earlier quoted context omitted.

Cloud is about elasticity. At ${work} we spin up a ton of EC2 instances in anticipation of huge traffic spikes that happen predictably several times a day, in different regions, and spin them down afterwards. It's also about simplicity. Many services come pre-configured on.AWS, with clustering, failover, backups, etc already present. When you are small, you can sysadmin your server fine, and you don't yet need the cl…

I can’t help but think that a 10x user spike causing a 10x CPU spike is mostly caused by poorly performing web apps written in dynamic scripting languages and the ethos “Just add more servers, servers are cheaper than developers.” Turns out, developers are cheaper than DevOps engineers and AWS budgets. So if a linear spike in servers necessitates a superlinear cost in operational complexity, maybe working highly perf…

The cost is also never just the scaling of servers. Scaling introduces are different class of bugs / issues:

- database connection limits

- caches

- state changes

- handling graceful shutdown

- speed of provisioning new instances

... the list goes on ...

Re: Hetzner Introduces ARM64 Cloud Servers

#330

Earlier quoted context omitted.

Practically it works fine in many areas of the US as well—just, good areas that don’t want to put up hurdles for voters in the first place. But, give an extremism a means to disenfranchise anybody and they’ll go for it Morally, even if it works out OK, it ought to bug you if you don’t have a cost-free way to vote.

I don't disagree at all to be honest. I don't think voter fraud is an actual concern (if bare mininum measures are taken, like voter registration or even just "checking in" individuals with their adresses), but I think it's weird that it is considered to be such a huge issue in the US when it is actually the norm in most of the world. Especially since it's usually white people using POCs as almost "noble savages" who…

I agree and think that some of the “it is just impossible for minorities to get IDs” stuff is, like, uncomfortably low expectations. I think this is sort of condescending and not really helping our case. If you took the average person from a minority community, I happy to believe that they are equally able to get an ID as a person from a majority community.

But in every community there is a range of willingness to deal with bureaucratic annoyances to vote. Adding more hurdles bumps some people from the voter to non-voter bucket. The reason it is a big issue in the US is that we have a well documented history of adding those hurdles selectively in order to suppress votes from particular communities. This is part of a really dark chapter in our history so people have a visceral reaction to it. I mean, since you are Canadian—I guess people would be a little skeptical if someone tried to start a conversation like “Well lots of countries have boarding schools so here’s my plan for education in some underserved communities…,” right?

Post reply on HN