The Alpine Linux docker image is 7.8 MiB to Ubuntu's 76 MiB, so they get a savings of about 68 MiB in image size by using Alpine Linux over Ubuntu.
From the stats in TFA it looks like about 43 MiB of the file size is the Swift runtime itself, which would need to be installed in any OS. This leaves ~57 MiB extra in their static binary approach vs what they'd get out of dynamic linking.
68 MiB (saved by using alpine) - 57 MiB (lost to static linking) = 11 MiB (net gains from Alpine), so their Alpine Linux solution is actually about 10% smaller than the equivalent that uses an Ubuntu image.
Is that worth the extra work they put into it? It probably depends on the application.
Depending on how builds and deployments are done, there is a high likelihood that the lower userspace layers are much slower moving than the upper application layers. After your second build, dynamic linking wins and everything after that it pulls even further ahead.
Smart builds can make application deltas really small. I helped design a system where our several hundred MB monolith could be hot patches with a layer of a few thousand kilobytes and most builds were 10-20MB. Obviously this wouldn’t have worked for a statically linked app.
From the stats in TFA it looks like about 43 MiB of the file size is the Swift runtime itself, which would need to be installed in any OS. This leaves ~57 MiB extra in their static binary approach vs what they'd get out of dynamic linking.
68 MiB (saved by using alpine) - 57 MiB (lost to static linking) = 11 MiB (net gains from Alpine), so their Alpine Linux solution is actually about 10% smaller than the equivalent that uses an Ubuntu image.
Is that worth the extra work they put into it? It probably depends on the application.