Infrastructure Languages and Kubernetes

A recurring point of annoyance I have is that people love to talk about Kubernetes in a derisive way, usually painting with a very broad brush, because they do not like the system and resent it. However, they also have to deal with it, due to that just being the deployment environment at work. The case against Kubernetes is usually around how overkill Kubernetes is, that you do not need a distributed, fault-tolerant cluster to serve a static HTML website, how it props on an entire layer of infrastructure and systems and leaky abstractions on something that was already capable of doing the same things as the VMs underneath. I think that these people aren’t in any way really wrong, but are kind of missing the point as to why people choose Kubernetes for technical problems whose solutions in no way require anything as capable as Kubernetes. The points they are missing are (as they so often are) the social components in the socio-technical system that is building modern software. Let’s talk about the reasons why you would choose an ill-fitting techncial solution to an ostensibly just-technical problem.

What are Infrastructure Languages?

In the beginning of the fantastic Sorting Things Out, Bowker & Star¹ talk about information infrastructure in the context of the ICD-10². The main point of the ICD, they argue, is to create a common reference and classification of disease, defined as a recognised taxonomy and nomenclature that can be used to communicate and think about diseases in a standardised and consistent way. A reference to the ICD code of (for example) pneumonia will describe pneumonia in a consistent manner wherever the ICD is used. Therefore, a doctor trying to communicate that a patient is definitely suffering from pneumonia will use the ICD code to describe what’s going on in written documents as shorthand for the symptom profile of pneunomia. The entire point of the book and the case studies examined within is that this is not a neutral act, and the creation, use, and dissemination of names and taxonomy opens various cans of complex, socio-technical issues. The unavoidable conclusion is that the classifications we use shape our actions and thoughts.³

Concretely, the language constructed from such information infrastructure is oriented around handling the objects of the domain, while (hopefully) also solving the problems of and in the domain. The ICD is designed as a classification rather than a nomenclature, where related diseases are grouped closely together. Bowker & Star distinguish classifications from nomenclatures in that nomenclatures make no claim to anything other than providing common names for things, whereas classifications take causation and relatedness on board: A disease with numerical code J18.9 (pneumonia) is related in some way to numerically close codes. In this case, J09-J18 refer to influenza and pneumonia diseases, J00-J99 as a whole refer to respiratory diseases. A doctor trying to figure out which respiratory disease is afflicting their patient only needs to look through a narrow sub-tree of the ICD.

The problems start arriving once you look at the sacrifices required to make a classification useful in practice: Statistically irrelevant diseases have to be omitted,⁴ and similar-but-distinct rare diseases are grouped. If this is not done, the ICD becomes too “heavy” to use and communicate with. Some information must always necessarily be dropped to make a map of the land.⁵ The perspective from which the information infrastructure is built matters, because it informs what dimensions are first to the chopping block when an abstraction is created.

The ICD came about as a mortuary rate table, so the central organizing question was “how many distinct deaths can be attributed to this code?”. As a result, niche diseases with few statistical cases were dropped or grouped, whereas things like “respiratory illness”, accounting for a great chunk of cases, were split up further. Of note is that relatively little of that is based on treatment options, or severity, only on the mortality statistics.

Yet, despite its origins as a mortuary statistical device, it found adoption in hospitals and with doctors needing to communicate, in brief, what someone was afflicted with. The ICD simply worked well enough to use directly without significant modification in this environment. The information dropped almost certainly caused and causes a bunch of pain for practitioners, but it was still, by far, the best choice for the job.

A consistent theme in Susan Leigh Star’s work on infrastructure is that it tends to vanish from sight: We use it, but we’re not aware of the effort that goes into constructing and maintaining such infrastructure.⁶ This also goes for tech and software, which are no different but slightly more amusing in how blatant the irony is: nobody wants to think about the effort that goes into maintaining and creating things like the Linux kernel, CPUs, cURL, USB drivers, and so on, yet they are still used every day to provide… more infrastructure to people who don’t want to think about the effort it takes to provide them with a convenient way to order pants from the internet.

Kubernetes as ill-fitting solution to everything.

The ICD is a bit like Kubernetes, in the sense that it may have had a more narrow, intended use case once, but it has since spread into other domains due to usefulness. It was designed to distribute containers of usually-stateless services over machines. However, it also worked just well enough for other things (like running databases, ETL pipelines, et cetera), so practitioners that were already using it for running stateless services over many computers started using it for those secondary targets, as it was easier to bodge the task into Kubernetes than it was to stand up an entire secondary piece of infrastructure that would allow you to run ETL pipelines in not-Kubernetes. Some things very much did not stand the test of time and were quietly put aside.⁷

So the practitioners started creating supplemental infrastructure that would ease the pains in using Kubernetes for the thing that was previously hacked in. Deployment services that were run in CI that ended up just calling kubectl apply -f became ArgoCD watching repositories. People realised that re-using bits of YAML was useful, and we ended up saddled with Helm.⁸

We’re at a point where Kubernetes does most things a SaaS company needs well enough in some capacity. Given a hosted Kubernetes cluster, I could easily find a way to run all of the information infrastructure that company would need. It would be a bad-to-mediocre-to-fine choice for many of them, but I would not have to try very hard.⁹ With this, Kubernetes has become the topmost layer of infrastructure for a great deal of people, the thing they look at, the thing they interact with, the thing they need to debug when things break. Not AWS, not a VM, not a rack server, but kubectl.

Infrastructure vanishes from sight when it works. Kubernetes may be run atop AWS, and AWS may break separately from Kubernetes and may have many more features and services than Kubernetes can offer, but unless AWS breaks, that is not something ever contended with by the average all-in-Kubernetes practitioner. Kubernetes forms its own infrastructure language, with its own answers to common problems, with its own practitioner community that uses those answers.

With this, Kubernetes stops being a purely technical or technological choice, and instead also becomes a social choice. Running your infrastructure on Kubernetes first and foremost is now also about primarily choosing your hiring pool. What skills do you want engineers you hire to have? Do you think you’ll get a better average candidate by choosing to run AWS-first or Kubernetes-first? What about hiring pool size, compensation, especially versus the cost of the infrastructure?

This is why I think that “oh you don’t need Kubernetes for this, it’s overkill” or “you should not choose Kubernetes for running your 10-requests-per-day proof-of-concept for your startup” miss the point, these days. That may have been a sufficient and complete critique when Kubernetes started out, but it is no longer, and has not been for a while now. It’s not just about running your tiny proof-of-concept, but also about choosing your infrastructure language, and your community of practitioners.

Looking down on people for ‘only knowing Kubernetes’ may have been somewhat justified (personally I don’t want to look down on anyone) when Kubernetes only solved a narrow slice of infrastructure problems, but those times have indeed also passed us by for years now. People who only know infrastructure through the lens of Kubernetes can still solve all the business problems an average shop may face, they just do it through the lens of Kubernetes.

The options may be worse than non-Kubernetes alternatives in some facet or another, but that is the same issue faced when AWS first became its own infrastructure language, and people talked about the things that should never be run on AWS and only ever be in a data centre. If the solution is acceptable, it will not be optimised, it vanishes from sight because it works. What is considered ‘acceptable’ may shift and prompt re-engineering, especially under cost pressure.¹⁰

Very frequently, when “inefficient” or “bad” solutions or “terrible hacks” start becoming common industry practice, it’s not that people all of a sudden lost their collective minds about how to solve infrastructure problems, it’s that non-technical reasons have won out over technical concerns. Social pressures include things like the need to be seen as ‘cool’ and ‘current’, and I think we have all seen an executive forcing a technically-stupid decision for marketing reasons a million times. The same social pressures happen inside of communities of practitioners as well, just less drastically, and less visibly. A shift like that is a sign that a piece of infrastructure that used to be a solution in a broader domain has become an infrastructure language unto itself.¹¹