This Week in Programming: Kubernetes’ Future in Virtual Machines
Last month at Amazon’s annual AWS re:Invent conference, the company unveiled a new technology that appeared, on its face, to be the perfect fodder for humor: micro virtual machines. The humor in the scenario, of course, comes from the fact that virtual machines have been around in one form or another since, ohhhhh, the 1960s.
https://twitter.com/wattersjames/status/1067309229541744640
James Watters, senior vice president of products for Pivotal, summed it up perfectly with his tweet — here we have the technology that’s all the rage these days, and the technology that’s here to upend it is the one we’ve been using for decades. The tweet may seem tongue in cheek, but it would seem that perhaps it is anything but, as a flurry of conversation has erupted this week around the idea that the true way forward for containers and Kubernetes is, in fact… virtual machines. Funny enough, this idea, much like the technology of which it speaks, is not brand new either. (Note the 2015 timestamp on the following tweet.)
the future of containers is virtual machines
— benjamin black (@b6n) April 15, 2015
Paul Czarkowski, a container devotee since Docker’s early days and fellow Pivotal employee, penned an article this week that has been making the rounds, boldly declaring that the future of Kubernetes is Virtual Machines — and people are not guffawing in response, but rather agreeing, and rather vehemently, at that.
“I am a big fan of containers and I’m not going to try to suggest that containers are dead. What Docker brought us in 2013 was a wrapper around Linux Containers. They showed us an amazing new way to build, package, share, and deploy applications,” writes Czarkowski. “There’s one sticky problem that’s left to solve, and this I believe will prove to be the downfall of the container … multi-tenancy. Linux containers were not built to be secure isolated sandboxes (like Solaris Zones or FreeBSD Jails). Instead, they’re built upon a shared kernel model that utilizes kernel features to provide basic process isolation.”
Now, if you were hesitant to agree with the idea that virtual machines were the way forward, maybe just give a read to the Twitter thread by GitHub engineer, ex-Docker core maintainer, and self-dubbed “Keyser Söze of containers” Jessie Frazelle, who writes that “Kubernetes was not made with security in mind. It was an afterthought and as such you will continually be a hamster in a wheel sweating your ass off unless you build your own with hard multitenancy in the design.”
https://twitter.com/jessfraz/status/1078057723231641600
Frazelle dove deeper into this very topic last May, with her blog post discussing hard multitenancy in Kubernetes. The basic idea behind this idea of hard multitenancy — and the feature Czarkowski and others see lacking with Kubernetes — is that “tenants do not trust each other and are assumed to be actively malicious and untrustworthy. Hard multitenancy means multiple tenants in the same cluster should not have access to anything from other tenants. In this model, the goal is to have the security boundary be the Kubernetes namespace object.” And this is a problem yet to be solved, which brings us back to the current suggestion — that virtual machines, or some form thereof, may actually be the way forward… despite the fact that they’ve been here the whole time.
You mean one config gone wrong or one missed patch and you're "cluster fucked"?
— Aaron Patterson (@tenderlove) December 26, 2018
Of course, if you’re interested in all of the gory technological details, make sure to give both of these blog posts a full read. Suffice it to say, Czarkowski says, that much of this is nothing new.
“The cloud providers are already working towards this future. You can see this forming by watching what is happening in the Open Source Communities. (Arguably Amazon is already doing this opaquely with Fargate),” concludes Czarkowski. “Tied together with the correct improvements to the Kubernetes hard tenancy model and you’ll arrive at the holy grail of Kubernetes. Full isolation of Kubernetes workloads and a pure per Pod consumption cost model to run workloads on Kubernetes.”
So, as a developer watching the world go ga-ga over Kubernetes and declaring 2018 “the year of Kubernetes,” you may have been thinking to yourself, “in 2019, I’m going to figure out this whole Kubernetes thing.” Or maybe you’ve just thought to yourself, as it seems many have, “Kubernetes is just too damn complicated.” Either way, you may be in luck — you may just get to stick with virtual machines in the end anyway!
And for the rest of you, simply looking at taking on web development in the year ahead, here’s a nice little video that offers a quick-ish guide to what you need to do:
As far as news goes this week, well, as you might imagine, there really isn’t any. But, there are a few links we thought worthy of sharing, nonetheless. So here we go.
This Week in Programming
- GitLab ChatOps Goes Open Source: The team behind GitLab says that it’s going to be making GitLab ChatOps available to everyone in GitLab 11.8. If you’re unfamiliar, GitLab ChatOps lets you run commands from chat in a channel to allow everyone to be on the same page about what happened. Unfortunately, it seems, ChatOps never really took off as some had hoped, but GitLab is open sourcing the feature now with the “hope that open-sourcing the functionality will encourage more use of ChatOps and more contributions to it.”
- The APIs of 2018: This week, ProgrammableWeb rounds up its most clicked, shared and talked about APIs in a series of blog posts. Although 2018 “wasn’t exactly a smooth year for API providers or developers […] API Design continues to evolve, which is a good sign for the API Economy.” Despite any issues in the year past, they write, the numbers tell the story. “If the amount of APIs, SDKs, and Sample Source Code profiles added to ProgrammableWeb directories is any indication of the health of the API Economy, we have nothing to worry about. The totals for 2018 include 1,776 APIs, 3,381 SDKs, and 3,028 Sample Source Code profiles that were added to our directories this year.” If you’re interested in what particular categories lead the pack, make sure to click through.
- The Continuing Evolution of Open Source: Last week, we took a look at a somewhat heated discussion around the evolution of open source licenses. If the topic caught your fancy, then make sure to give Redmonk founder Stephen O’Grady’s Cyclical Theory of Open Source a read. O’Grady looks at the problem of hybrid licenses, writing that instead of disappearing, as previously predicted, they seem to be doubling down. “Open source as a development model will undoubtedly endure, if only because it’s the least bad model out of all of the others that have been tried and because the phenomenon of developer empowerment is unlikely to be reversed,” writes O’Grady. “But in a world in which appetites for open source software commercially are under threat from — among other areas — proprietary cloud-based offerings, it is certainly possible that industry appetites and support for open source could be slowed if public models give way to private alternatives.”
My New Year’s resolution is to only use artisanal software lovingly crafted off the grid with recycled code by pairs of fully organic humans using non-GMO ones and zeros and with assurances that no bugs were harmed during testing. https://t.co/SXb7K1TcSx
— Grady Booch (@Grady_Booch) December 26, 2018
Pivotal is a sponsor of The New Stack.
