June 29, 2020

Apple! the world is not ready for ARM


Last week Apple announced its transition to ARM, err, Apple silicon.

My first thought was: poor developers who work with Docker! They will now develop and test on an architecture that is - at most - exotic in the datacenters of the mainstream cloud-providers.

Don’t get me wrong, I am not an Apple-hater: my day-job work-horse is a 2015 Macbook Pro, and I like it better than my work Windows laptop, also because it has an I7 Intel CPU that has aged well. I am mostly into containers these days, so this post is an attempt to explain what my daily work and private projects would look like, if I were to use am ARM device to work on different Kubernetes-hosted projects.


Yes, I know, we have CI/CD so why should I care? Well, have you heard of the inner loop? I want to be productive so I need a local environment allowing me to run as much as possible locally, without compromises, to avoid the “it works on my machine” syndrome. So let’s go through the pretty simple tooling I need:

  1. kubectl
  2. Minikube, or - even better - k3d
  3. Helm


Let’s start with the obvious: the documentation. Well, guess what? It is for amd64!

You can go download the source code and try to build it from source, but seriously!

But wait! There are other sources! Check!!!


The documentation does not mention anything about ARM: replacing amd64 with arm64 (curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-arm64) gave me a binary but I doubt it will run with anything except vm-driver=none as of today, since [Virtual Box does not run on ARM](orts a vm-driver=podman).


Good news: k3d runs on ARM


Good news as well, helm runs on ARM


I would be ready to take the challenge to move my inner-loop to ARM! Because I like challenges, am not under high pressure to produce code, and do not have a problem with cognitive-load since I do not have to produce code in my day-job. If I had to use the same stack, and working mainly as a dev, I would certainly not want to switch stacks just because Apple decided that it’s best for me.

Docker images

Now, imagine I took all the whoops and have an up-and-running ARM inner-loop. Now what? I certainly do not write Dockerfiles FROM scratch so I need sone base images.

Let’s look into two scenarios:

  1. My private stack
  2. The popular list from Docker Hub

How to check your stack?

You can check if your favorite base image goes here is supported on ARM:

docker manifest inspect nginx:1.15-alpine | grep architecture

This will either return nothing, or a subset from:

"architecture": "amd64",
"architecture": "arm",
"architecture": "arm64",
"architecture": "386",
"architecture": "ppc64le",
"architecture": "s390x"

My private stack

Agreed, this is subjective! And I must admit, since I run my apps both on an amd64 and an arm (mixed v7 and 64 bits) Kubnertes cluster I make my choices based on what is available.

Docker image Runs on ARM?
gitlab-runner YES
Azure CLI NO
Grafana YES
Grafana Image Renderer NO
Prometheus NO
Loki YES
Postgres YES
Traefik YES
Ubuntu YES
Alpine YES

Except the Azure CLI and the Grafana Image Renderer I must admit that I am pretty happy about what I am able to run on ARM (my Cluster, not my inner-loop). For the two mentioned “NO” I was able to build them for ARM, because I like challenges and because I am a nerd. But again, in my day-job I am under no pressure to deliver, so I am ready to invest plenty of time to reach my goals.

Whether it’s my cup of tea or not does not matter: these are the most popular Docker images from Dockerhub:

Docker image Runs on ARM?
Oracle Database Enterprise Edition NO
Oracle Weblogic Server NO
MySQL Server Enterprise NO
Couchbase NO
Postgres YES
Ubuntu YES
Redis YES
Traefik YES
Node YES
Busybox YES
Alpine YES

The caveat


Dear Apple, you are trying to sell me a solution that may fix your problem (not being dependent on Intel), but with such a transition you are making your problem to my problem: I say NO!

Content licensed under CC BY 4.0