Docker Desktop has been released for Apple Silicon, but it doesn't offer full support for all x86/64 images.
Image: Docker
One of the great things about containers is that you can create them and deploy them to any platform. If I develop a container on Linux, I can deploy it to Docker or Kubernetes running on macOS or Windows. If I develop a container on Windows, I can migrate it over to Linux or macOS. If I develop on macOS, I can deploy to Linux or Windows.
Unless you knew that was coming.
Recently, Docker released their official Docker Desktop application for Apple M1 hardware. It's important to remember here that this is a Docker release, not one from Apple. That bit is only slightly adjacent to the actual point here, but it's still something to consider.
Upon releasing the new Docker Desktop for M1 hardware, it was discovered that the release wasn't a full-blown M1-flavored application. Some of the binaries associated with Docker Desktop on M1 hardware are still Darwin/AMD64 and require Rosetta 2. Even better, not all container images are available for ARM64. Case in point: MySQL. If you depend on using MySQL for your container database, on M1 hardware you're out of luck. The workaround would be to use a supported database, such as MariaDB.
SEE: The best programming languages to learn--and the worst (TechRepublic Premium)
Another issue is some Intel-based containers will crash, due to QEMU failing to run the container. To that end, Docker came out with this statement:
"...we recommend that you run ARM64 containers on Apple Silicon machines." A Docker representative indicated this shouldn't be a problem in the future, "as more and more images are rebuilt supporting multiple architectures."
That last statement is the crux here.
One of the biggest selling points of containers is that they are portable. With the addition of M1 hardware into the mix, the waters are all of a sudden muddied. Even though it's only a matter of time before this issue is ironed out, it does prove just how tricky and vulnerable the world of containers is.
One bad container image can spoil the whole cart and new hardware can spread confusion and chaos.
Don't get me wrong, I'm not cutting Apple to the core. I own an M1 MacBook Pro and find it to be an astounding piece of hardware. Once again, Apple has raised the bar to levels so many other manufacturers simply cannot reach, and Apple knows it's treading very precious ground at the moment. The path the company is walking will lead them to great success.
But at what cost? This is the real issue.
When Apple (or any company) releases hardware that causes systemic breakage across numerous sectors, they cannot lay the burden on everyone else to fix all of the problems created by their new darling. Apple should be expected to assist the efforts in getting third-party software to function properly—especially one as important as containers. The domino effect this could kick off might be far-reaching.
Of course, it's not really. The number of developers migrating to M1 hardware probably isn't as widespread as we think. In fact, according to Statista, the most widely-used developer platform is Linux (at 55%). As far as macOS? It's not nearly as highly ranked as you might think. All of those Linux container developers can rest assured their work will deploy everywhere—except maybe not Apple M1 hardware.
What about M2?
I have every confidence this issue will be ironed out, and soon containers and M1 hardware will play well together. What happens when the M2 chip arrives? Will we find ourselves back in the same situation? Or will M2 be backward compatible with M1?
See how tricky this can be?
Containers are supposed to be deployable to any supporting platform, but when supporting platforms come with an asterisk, you simply can no longer lay claim to that "run anywhere" ideology.
I realize this issue splits a lot of hairs. You can certainly use Docker Desktop on Apple M1 hardware and, for the most part, it'll work just fine. It's only when you come across an unsupported image (such as the aforementioned MySQL) that you'll have problems. There will also be issues when some x86/64 images run considerably slower on M1 hardware because of the need to emulate a lightweight Linux instance along with the running application. Since Docker Desktop is already a bit of a memory hog, this issue will rise up more often than you might think.
Even with the issues, this is an important step forward for Apple Silicon. Although Docker Desktop on Apple Silicon might put a dent in the whole "run anywhere" ideology, it's only a matter of time before this issue is ironed out and Docker Desktop makes it easy for developers to work with Docker, no matter the image required.
This should be considered a step forward, with maybe a cautious half-step back. Even so, it's still progress.
Subscribe to TechRepublic's How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.
Developer Essentials Newsletter
From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know. Weekly
Sign up todayAlso see
April 21, 2021 at 11:18PM
https://www.techrepublic.com/article/apple-throws-a-wrench-into-the-wheel-of-the-run-anywhere-aspect-of-containers/
Apple throws a wrench into the wheel of the "run anywhere" aspect of containers - TechRepublic
https://news.google.com/search?q=Wheel&hl=en-US&gl=US&ceid=US:en
No comments:
Post a Comment