Are Containers the Future

Abstract: Each technology has two different voices, one supporting and one questioning. We cannot erase the right of others to question, but we can also stick to our own beliefs, prove ourselves, and speak with results.

Date: Oct 31, 2022

Related Tags：1. Alibaba Cloud Container Service for Kubernetes (ACK)
2. Elastic Container Instance

The author saw this tweet the other day, so to speak, and it prompted me to start thinking more about the subject of this article.

As I'll mention below, anything can't be said with absolutes, as it will offend other people.

I try very hard to avoid opening the comments section, however, every now and then I succumb to the temptation and I'll see people complaining that they're stripping containers from production for security, performance or other reasons. The reason is (there are only 10,000 reasons). However, every now and then I succumb to this temptation and I'll see people complaining about how they strip containers out of production for security or performance or other reasons (only 10,000 reasons).

What's interesting, however, is that when these views are expressed, recently, I've started seeing questions like "I'm really curious - are there any other options?"

For a while, I had absolutely no idea what the person asking the question was actually asking. What do you mean there are alternatives? You turn on a Linux machine and end your day at work.

Since then, I've realized that there's been an entire generation of software engineers who have grown up in this madness. Imagine if you were 22 or 23 in 2013 (just 7 years ago), but in a software world, that's pretty much a lifetime. That's long enough for you to graduate from college with your "senior engineer" title. You can just deploy containers in your 20s and don't even know any other way exists. For example, the term "ingress" is used in the k8s community as if it were some kind of product category, while load-see nginx is used as the main component. You'll see people asking questions like "what would you use to get in?" and they're asking how to configure nginx as a reverse proxy.

I don't know if there's a lack of education, or if marketing is blocking the sun, or what, but it's now clear that we're failing to teach this group of engineers certain skills.



Resume Driven Development



A very interesting paradox that happens is that many kubernetes users are learning to deploy kubernetes clusters through CV driven development, and the VP of engineering and other leaders allow them to do so so they can keep them, do an already Very difficult job - hiring engineers.

Directors, VPs and other leaders are actually giving them something to stay with their company - not necessarily for technical/cost benefit. Many managers privately admit this.

This "privilege" has started to significantly disrupt the software engineering ecosystem. This divestiture of Linux skills will hurt businesses a lot in the future if they don't do it right.

Simon presciently noticed that this happened two years ago.



I think we've started seeing this acceleration recently. Tribal divisions are real.

Is safety the death knell for containers?

Containers and kubernetes have a relatively average reputation for security. As demonstrated in a recent video on Advanced Persistent Threats in kubernetes at the RSA conference, it is clear that kubernetes is an unanticipated target for attackers. You own a host - even the most minor application, you can get it done. Your entire infrastructure is ready.

Video address: https://youtu.be/CH7S5rE3j8w

We've known for years that security will eventually destroy the container ecosystem. It's just broken by default and cannot be fixed by any tooling or architecture change.

In a recent FOSDEM video, Kris Nova goes into a kubernetes cluster to show how easy it is, and then shows how to audit the intrusion:

When you hear people on Twitter or Linkedin talking about "devsecops" and security, it's a total joke. Kubernetes and security don't belong in the same sentence at all.

As a side note, I think people should really appreciate the fact that Kris is a developer in the k8s community, and (at least) this is the second time she's called kubernetes "clusterfuck" in the title of her talk. Why bring this clusterfuck into your organization if their own developers will come to the conference and call the software "clusterfuck"?

Why on earth are you bringing this ClusterFuck into your organization?

The problem here is that the k8s architecture for containers and extensions is broken by default. No matter what any vendor says, there is no way to secure a kubernetes cluster. First, it was never designed to be secure. It was a house made of cards, with sand on its foundations, and full of carnival hawkers.

In fact, there have been many tweeted quotes on FOSDEM this year, such as in the last minutes of this talk: "The perception of the kernel devs to the docker community is that, in rare cases, they can actually get the problem right , and they usually don't understand the answer."

all games

Assuming you haven't read the previous paragraph. After years of tweaking their audiences in the "right" way to deliver and use kubernetes clusters, big G companies have made a splash by introducing new pricing changes.



Google improved the return on K8s cluster management fees by excluding the new SLA, Anthos, but customers were not satisfied. Here's a regression that no one wanted or asked for:

https://www.theregister.co.uk/2020/03/05/google_reintroduces_management_fee_for_kubernetes_clusters/

Predictably, this led to the complete downfall of companies already addicted to GKE drugs. I don't know why everyone was caught off guard by this - maybe because Google promised they would never do it.

friction

That's the problem, most containers and k8s folks are very averse to having anything else as part of the infrastructure paradigm. The thing is, these guys have spent at least 5 years or more building their personal brand around the k8s myth, telling everyone and their mothers that this is what alpha and omega are all about.



MicroVM and NanoVM



Both Google and AWS know and admit that containers and kubernetes are broken.

That's why they strive to improve their work through marketing. I mean "open source" like firecracker and gVisor. Of course, firecracker can only run on very expensive "bare metal" instances (not really bare metal) and gVisor. gVisor is another project where evangelists claim that Google has been running for years in production, where it most obviously replaces something similar that exists internally.



truth and lie

Apparently, we've been preaching this general design pattern of running a single program on a separate virtual machine for a while now, to the point where we thought it necessary to create our own kernel. There's a lot of talk of "simplifying the system," like bottlerocket, but there's more talk of stripping away system components that simply don't belong in the virtualized world of 2020. Who is the user? Who needs them? Are there multiple processes? Do you have only one purpose? Can you log in interactively?

Now to be completely clear, all of our engineers are happy and a large number of Linux users have been using it for quite some time. This kernel is not designed to replace Linux, because Linux is used for many things that many kernels never tried to solve.

For example, we would never configure Nanos directly on an actual computer. We also won't be adding ssh support to it (even if we could). We also won't be running it as a desktop. This year is not the beginning of the year. It exists for the sole purpose of deploying it in a server environment.

Are containers the future? Each technology has two different voices, one supporting and one questioning. We cannot erase the right of others to question, but we can also stick to our own beliefs, prove ourselves, and speak with results.