I'm excited about arm in more places but my experience with arm and docker isn't as easy as i expected
Is it just me? When I've started using arm more, I've noticed that docker images are often incomplete or behind the x86 release cycle.
I love the ease of wiring docker images together for all my services (corollary: never having to understand the myriad packaging issues with whatever language the service is written in, python, nodejs, etc).
But when I'm using an arm image, often it is not the same version as the latest on x86, or even worse, is packaged by someone random on the internet. If I were to install the JavaScript service myself, I could audit it (not that I ever do!) by looking into the package.json file, or reviewing the source code, or whatever. There is a clear path to reviewing it. But with a docker image from the Internet, I'm not sure how I would assert it is a well behaved service. Docker itself gives me some guarantees, but it still feels less straightforward.
I've packaged things for an arm container myself and it isn't always exactly the same as for x86.
I felt this a year or two back, but today I've had as good of an experience on Docker w/ arm64 as I do w/ x86_64. I use arm64 Docker a lot since I work on a M1 MacBook.
I usually stick to the common base images, e.g. ubuntu, alpine, nodejs, golang, etc. and install based off of that. Also, I rarely write Dockerfiles these days and instead use Earthly [0], which is a tool that really shines as a CI/make alternative, but it incidentally also has a nicer syntax which makes it easier to write multi-platform Docker images.
What images or other problems have you ran into on arm64?
For example gitlab. The latest arm image, as far as I could tell, isn't the same as the most recent x86. And, iirc, it was from some other person, not gitlab. It's often hard to tell what you are getting when you run an image, because docker pull can pull an image that isn't a multi platform build. I've had issues where the SSL certificates don't work, and I'm assuming it is because the stack could listen on 443, but the full ssl when running on arm didn't work. I'm not sure if that was because it is emulating using Rosetta or whether the software inside the container built correctly but isn't actually running on the arm platform correctly or what. It just feels like the wild west with arm images right now. I'm sure it will get better but it is still a minority platform and that comes with those issues.
And, this might just be exposing my ignorance. Until recently I hadn't needed to use arm but now with macos it's gotten more interesting and more complicated.
Yes, my memory is a bit foggy, but it was difficult to get any of the images to work, so I started playing with other contributors. But, you are right.
> The latest arm image, as far as I could tell, isn't the same as the most recent x86. And, iirc, it was from some other person, not gitlab.
Ah, that's fair. If you're running software packaged by others, that might be less well-covered because you'll have to wait until all of the vendors you care about add in that supprort.
If you're developing software in arm64 Docker, I think that case is pretty good today.
You can inspect the layers of a Docker image. Tools like dive[0] provide a quick and easy way to navigate through the different components your image of choice is made up of.
In terms of functionality once the container is running, you'll have to put some amount of trust into the project maintainers, no more or less than the trust you need om amd64. For containers repackaged by third parties that's quite a pain, but in most cases you can get by just fine with the official container.
If your container of choice has been made by someone real fancy, you may be able to get reproducible builds for all the files inside the container. That would verify that the source and the binary match (though container metadata may not, so a direct image compare would be challenging).
This sounds about right to me. At work, we make a rather complex stack that uses quite a few third-party containers. When we wanted to do arm64 support a couple years ago, most of these dependencies did not support arm64, so we had to build and publish the containers ourselves. (We already sort of had to do this anyway, because customers ran into Docker rate limiting issues, and images from our account aren't rate limited because we pay them not to. But when we only supported amd64, we just re-tagged and pushed.)
I’m not excited that much yet, because except for dumb single board computers, i still can’t get a proper arm system to run at home.
My home server (a repurposed fujitsu esprimo q920) is still intel based and it doesn’t seem to be anything available with comparable performance and connectivity. And I’m not even considering the price point.
Basically: arm cpus don’t play any significant role in my everyday computing life.
At work, I’ve been migrating all of our infra to graviton and we realised substantial savings… but then again, I don’t pay the cloud bills and my salary is still the same, so meh.
I don’t have too many gaps but also don’t use that many different base containers for security and reliability reasons. As you mentioned, I feel like in a decade the current experience of running random code from strangers all over the internet with no more protection than Docker Desktop provides is gong to sound similar to 1970s swingers’ accounts of unprotected orgies sound to all of us who grew up after HIV, etc. where people will kind of accept that it happened but be amazed that everyone was so reckless.
You're not wrong...but it will get there and get better. I believe asahi will be a driving force behind it, and arm in general being more widely used for non mobile device stuff....however (despite using fedora on arm64 as a daily driver) I firmly believe we're going to be 6-12 months absolute minimum until arm docker is "alright" (I'm also broadly including fully user transparent x86 emulation into this sweeping statement with no basis lol)
The friction with using Docker across arm and x86 was one of the big reasons that I ended up learning NixOS. Now, all the services on my personal remote box and all my one-man-SaaS services run on NixOS + systemd services and my life is so much easier and less stressful.
Sounds like a docker issue, not an ARM issue. My full desktop NixOS config builds for x86_64-linux and aarch64-linux. It even about 90% cross compiles, possibly just one "external" package that isn't setup right for it. And actually that might even be fixed, I just saw a cross-compilation fix go in today.
One thing that made arm on docker much easier was by using the kubernetes builder for docker. Spin up an arm nodes in kubernetes, create the docker builder pod, and it'll build/push your docker image easy as can be.
I face similar problems running a docker-based NAS on a Raspberry Pi. But I end up just building the official images myself on the Pi (or on my dev machine with qemu) from the open source Dockerfile of the official image.
TFA describes the E3-1230 as an 8 core server when it is actually a 4 core server with 8 threads. That means the ARM vs x86 per-core performance comparisons are off by a factor of 2. I stopped reading when I noticed that. For cheap sustained compute, it's hard to beat a Hetzner auction dedi.
We're using Hetzners new ARM servers ourselves, to convert images to WebP (Yes, your company name is really confusing!) and they perform almost as good as the Hetzner AMD instances.
But since they're so much cheaper, we can easily fire up many of them and use a load-balancer in front, saving a ton of money compared to dedicated servers.
LOL, we're not a company, we are just a small team of three individuals(Nova Kwok,Benny Think and Tuki Deng).
[convert images to WebP]
May I ask your use case on this?
(As we've recently launched a product called WebP Cloud might fit this need. (And we're actively seeking seed users.))
Alright, they way it was mentioned in the article made it sound like a business, sorry about that.
Your service looks great, but we long since concluded that using an API for image conversion would be many times more expensive than using our own setup. And we also have mixed in fetches from external sources, storage in S3, Cloudflare workers and generative AI mixed in the bag - no single service supports all that yet (hint).
> they way it was mentioned in the article made it sound like a business, sorry about that
It is a business. They're selling a service. I don't know why they're protesting at the notion of being a company, they're de facto a business (selling service behind a brand, which they're openly promoting to sell more services).
Hmmm, maybe calling this a start-up/business might be more appropriate?
(WebP Cloud Services starts by providing a free service of Gravatar/GitHub Avatar reverse proxy with WebP optimization at first, and now it's our first attempt to make a paid services of private proxy as more of our users want this to be a more generally available service.
(And we are currently not a company indeed) ´･ᴗ･`
No intentional protesting at the notion of being a company, just unsure if "company," "business," and "startup" have the same meaning in certain contexts.
If you're planning to build a business together, forming the company ASAP is a good plan. Recently talked to some founders who split up before they incorporated, and it was a mess.
[If you're planning to build a business together, forming the company ASAP is a good plan.]
Do you have any advice in this regard? We do have a preliminary plan to register a European company in Estonia (through e-Estonia) after achieving good revenue to continue our operations.
You absolutely must do this BEFORE any sort of revenue. It should be the first thing you do.
You need a company to own things, such as the IP (code, trademarks, website, customer lists), as well as being the thing to which revenue is paid. You'll also find you can't do most things without it (such as get a credit card, office lease, cloud discounts, etc).
Most importantly, suppose you have a cofounder break up when you have just started getting "good revenue" but haven't yet got a company. Who's is that revenue? Who owns the code you wrote? A complete mess.
I don't know anything about e-Estonia, but if they allow you to sign up today, no reason not to do that. In the US (or abroad if you want a US company), Stripe Atlas is a good option. That might work for you too.
It's a bad Idea. Stripe and other Banks want proof that you live there at some point, what I heard. And Tax Authorities usually see that as Tax evasion if you don't have "substance" in this country of cooperation.
The moment you started providing a paid service you became a business. The legal status, as in company, independant, or whatever, depends on your local laws.
We created a company that does something similar[^1]. The tech was great and the company is profitable, but the market is really, really tough, with incumbents (read: existent CDNs) playing all sort of "standard business practices"[^2] to keep customers in their more expensive business. And yes, in this line of business you really want the cheapest hardware.
[^1]: Support for transcoding images to WebP, AVIF, JpegXL, and selecting on the flight the best format for serving individual images in a website. Company (ShimmerCat AB, a Swedish registered company) is currently for sale; contact the CEO if you want a bargain[^3], last time I heard ask price was X0 000 USD, with X less than 9. I'm not part of the company in any capacity any longer.
[^2]: Read: standard dirty tricks to suppress the competition.
[^3]: Who is the CEO is public in the Swedish registry of companies.
Since moving to Apple Silicon, I've been wanting more ARM options in the cloud. Although it is possible to host x86_64 VMs, having fewer differences is obviously better.
I've been using Oracle's free tier for a while, and it's been OK. Performance-wise, my Objective-S and libµhttpd based web-server appears to be doing around 1800 requests per second, and held up fine to a HN hug of death.
Hetzner was far, far easier to set up, both from their console and via the API. Performance was comparable.
I’ve been migrating workloads away from x86 and towards ARM on AWS and GCP since they’ve been available. This review does a great job of kinda giving you an idea of what you are gonna get as a platform, but if you are interested I strongly recommend the experience on any cloud provider.
While there was some work to benchmark and validate, the cost savings have been non-trivial. Plus this change happened as we were all switching to the M series Macs so ironically now our entire chain end to end is off x86.
For us it was driven in the other direction. With the introduction of the M1s we knew that we’d be on arm locally soon enough. There was a bit of work in the transition but things have improved since then. Definitely happy running on all arm now though.
Alas all my stuff is in Azure, and I'm still waiting for them to offer smaller VM sizes comparable to their existing B line. I currently use a B1s (1 CPU 1GiB) that comes to ~$5/mo while the cheapest ARM VM would be ~$25/mo (2 CPU 4GiB).
I was keen on migrating to ARM, but there seems to be no benefits from doing so on GCP; I'm open to be wrong here.
From what I understand they're using Ampere Altra, which have single thread performance similar to Skylake; but the cost is equivelant or worse than the x86 e2 series.
e2-standard-4: USD 97.84/mo
t2a-standard-4: USD 112.42/mo
(sustained use discounts apply to neither).
EDIT: I see you're in Denmark and are operations focused. I am too operations focused and just across the bridge in Malmö, maybe we could hang out.
Yeah sorry I should have been more clear. Currently the ARM instances in GCP when you use them as spot basically never get interrupted. We’re big into GKE so use them as a preferred node group for interruptible pods. I assume due to the pricing you mentioned usage is very low.
So basically any background jobs or big batch processing jobs that required a lot of CPU time. We have multi-arch container builds so if we can’t scale out the ARM node group not a problem, go back to x86. But it was worth the optimizing to get effectively always available spot instances.
Yeah always open to meet up with folks. I’m on mastodon at matdevdug@c.im.
I like the article, but I wish there had been an "Abstract" or "Executive Summary" at the top so that I'd be spared having to read the entire article to find out the results. I'd like to have seen something along the lines of the following:
"We found Hetzner's ARM64 offering, specifically the CAX21 with 4 cores, 8GB at $8.40/month, to be a performant and cost-effective alternative to x86_64-based solutions."
According to Oracle's documentation their Arm servers are not virtualized cores but instead actual on-core tenancy, referred to as OCPU instead of conventional vCPU.
Interesting read. I'd like to know more about alpine problems (even just to confirm my bias against it, unless space savings are the most important thing).
For me, Hetzner is mostly baremetal provider. They have dedicated RX line, and if you have base load, a couple of those could run it all (use hetzner cloud instances for scalling and failover)
Sure, and we're planning to share another post later on the whole procedure of our migration from AMD64 to ARM64, and in that post we'll include more details about Clickhouse's problem if we can definitively establish that the problem was caused by alpine.
(After this incident I personally have bias against alpine images too
Comparing alpine and non-alpine images on DockerHub:
This is a great article and it’s nice to see we’ve lots of alternatives to run ARM servers.
I ran the now defunct Scaleway ARM server mentioned in the article for several years. For €2,99 it was a surprisingly useful machine. I ran several projects (.net core) on it and it was quite good for those simple workloads. I looked for alternatives for a while but nothing turned up until Apple restarted the ARM revolution with M1.
I've been using a cax41 (16 cores) instance for numerical computations recently. Geekbench scores are 774/10221, costs $0.04 hourly ($27 monthly). Perfectly stable. No throttling (probably not that popular yet hehe). For my specific program it's 10% slower than my laptop's 11980HK processor (8 threads, 16 hyperthreads).
Amazon/Google has fallbacks across regions, several layers of data storage redundancy, high-speed. highly configurable software based networking and so much more.
Hetzner/OVH has machines with almost no failover, with no extra availability zones, with no backup guarantees, very little in the way of custom networking, and doesn't integrate with dev tools quite as much.
They're different products. For most people, going Amazon/Google makes no sense. However, if you absolutely MUST keep your data available after or during a fire [0] and keep your systems running during datacenter downtime, you're better off with AWS/GCP/Azure. SLAs with many nines can't afford cheap servers, and that's where the big cloud providers make a lot of money.
Up until recently I saw a lot of people and companies move back from the cloud to self-managed dedicated hardware in data centers. All most companies need is half a rack in two places and a competent sysadmin team, but externalizing the risks is often attractive because disasters and bad failovers do happen sometimes.
Another thing about AWS/GCP, they are also good at locking you in. For example you want to shift some workloads to Hetzner while leaving others in AWS, you will get a bill for egress out of AWS.
I wouldn't say Ampere Altras are cheaper or worse servers than AWS's Gravitons.
And many nines is a fiction anyway. For example, Google Maps had two prolonged downtimes in 2022.
Wow, this is timely. I just bought their cheapest one last night (about $4/mo) to play with and performance test it for ASP.Net Core, vs. their x86 boxes.
I tried to be ultra cheap and not buy a v4 IP but it appears Microsoft doesn't have v6 IPs on all their download servers which is causing me pain.
I have been developing on ARM servers for a while. I use Raspberry Pis and Tinkerboards as dev and staging servers and push releases to an x86-64 server on digital ocean. With docker it has been pretty easy, docker-compose usually finds the right packages for the CPU and it works quite well. I am curious about maybe trying on of the ARM servers on Hertzner and see how it compares.
I've been trying their Arm servers for a while and I've noticed some differences in the colors in htop for Debian 12, as if there were a slight difference between the x86_64 and the aarch64 image. Other than that everything's going fine and I'm planning to use Arm for every server in the Falkenstein datacenter (the only one with Arm dedicated and cloud servers for now)
Nice, how’s the performance? The cheapest digitalocean x86 single core cpu is a lot faster than a quad core pi or tinkerbord. I know it’s not the same as an arm server cpu but how much difference is there?
The score on Geekbench is Single-Core: 838,Multi-Core: 842.
While in our tests the cheapest ARM64 plan on Hetzner is CAX11 2Core, 4G RAM, about 5USD/mo, the Geekbench result is Single-Core: 1072,Multi-Core: 1921, so assuming it about 20% faster than DigitalOcean.
That's 6 cores, so not quite fair, but w1350 also has a much higher boost frequency, bigger caches, more bandwidth to ram, and it's built on smaller lithography and several generations of core designs later. It's hard to find a comparison between rocket lake and haswell, but between all the differences in lowend xeon parts, you're probably seeing a significant increase in throughput if your load isn't bottlenecked on something else, but even then, 20 pci-e 4.0 lanes vs 16 pci-e 3.0 lanes is more than double the i/o capacity.
As someone who had a chance to see the difference by it's own eyes: yes, it's faster, especially when the memory is the bottleneck. But it's not times faster in everyday tasks. Aside from the synthetic tests you are usually see more performance improvement from the overall system being faster (ie SATA to NVMe, more faster RAM) than just by CPU alone.
There are some apps that are CPU bound (GHz first, RAM BW second) which gladly run way faster on these E3-16xx CPUs, than contemporary E5 multisocket monsters with tons of RAM... but waaay less GHz. These apps would be better on W1350, no questions.
I'm surprised how bad xeon scales to 8 cores. But isn't the xeon instance the only one not running bare metal?? Maybe he is paying for 8 cores but gets only 2-4 physical cores?
That "Xeon" is a very old (10-year old) quadruple-core (8-thread, i.e. 8 "virtual CPUs") desktop Haswell CPU rebranded as "Xeon". A current Intel NUC Pro with a Core i3 CPU would be a much faster (67% faster ST, 43% faster MT) dedicated server than this one and it would cost to own less than $500 with DRAM and SSD, so about $8 per month for a 5-year lifetime (so the performance per $ would be at least 5 to 6 times higher than that of the compared Intel server).
That "Xeon" is a good comparison point only because it was available for them in the same price range, not because it would be representative for the performance of any modern x86 CPUs. Also the "Epyc" is probably a very old model.
Somebody who wants to spend their money for cloud services as efficiently as possible should better ensure that it is possible to migrate back and forth their applications between x86 and ARM instances, because which one is cheaper for a certain performance at a given time depends a lot on non-technical reasons, so it is unpredictable which will be cheaper a few months later.
@kramerger
No, Xeon Server is a dedicated server(a.k.a Bare metal), I've looked at it's console and found it's Dell PowerEdge R220(Motherboard Dell Inc. 081N4V).
I'm quite confused about it's performance as well.
CPU Info
Name Intel Xeon E3-1230 v3
Topology 1 Processor, 4 Cores, 8 Threads
Your link is wrong, it points to an E3-1230 (v1) from 2011 (Sandy Bridge), while the tested CPU was E3-1230 v3 from 2013 (Haswell).
Decoding the Intel product names requires experience, because one or two letters or digits added or deleted can change very much the characteristics of the product. Two such products differing in one letter might have a five times difference in performance.
Not that it matters much, because even an only 10-year old CPU is still ancient.
That's interesting. I feel like I see benchmarks almost always showing ARM outperforming for all kinds of specific workloads. This is the first one I can recall showing it's not as good performance-wise, however when you add the power efficiency, cost savings, it winds up being better overall.
I've sent my passport image to them to get my account verified.(When the second time I register Hetzner)
(My first attempt on registration got my account closed even I've provided by passport.(maybe it's because I've used VPN for registration as it's website is too slow to open in China(might caused by china GFW)
Is it just me? When I've started using arm more, I've noticed that docker images are often incomplete or behind the x86 release cycle.
I love the ease of wiring docker images together for all my services (corollary: never having to understand the myriad packaging issues with whatever language the service is written in, python, nodejs, etc).
But when I'm using an arm image, often it is not the same version as the latest on x86, or even worse, is packaged by someone random on the internet. If I were to install the JavaScript service myself, I could audit it (not that I ever do!) by looking into the package.json file, or reviewing the source code, or whatever. There is a clear path to reviewing it. But with a docker image from the Internet, I'm not sure how I would assert it is a well behaved service. Docker itself gives me some guarantees, but it still feels less straightforward.
I've packaged things for an arm container myself and it isn't always exactly the same as for x86.
Is this just me? Am I doing it wrong on arm?