I appreciate the even-handedness and insight here, but my personal instinct (as a non-expert who’s had to work with k8s) is that it’s too generous. I mean, they named something “a mutating admission controller.” I’m sorry, but this is just a dick move. If you care at all about being understood and making things accessible to an audience, you don’t use those sorts of name, and k8s is laden with such enterprisey jargon. It’s part of the culture, it’s unnecessary, and whatever the reasons are, I don’t buy that they’re valid.
What would admission controllers be called in analogous systems? What is the generic term?
I have no idea and I wasn’t trying to critique it on that on level. It just came to mind as an egregious example of the jargon that amasses around all thing kubernetes. Regardless of what they are, it is impossible that this was a good name, and I feel totally comfortable making that claim with no further context. I’ll let the opening paragraph on the page you linked make my case for me:
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. The controllers consist of the list below, are compiled into the kube-apiserver binary, and may only be configured by the cluster administrator. In that list, there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the mutating and validating (respectively) admission control webhooks which are configured in the API.
I agree that reading postmodern philosophy would be preferable to trying to decipher this. However, I view it as an object-oriented usage of the Decorator Pattern; admission controllers decorate requests to create new objects, but don’t have to worry about whether the request is authorized. A poor name for a useful concept.
I’m dealing with the “control loop” reason at the moment and it definitely takes some getting used to. For codgers like me who have been using RDBMSs for a while, it’s scary to allow the system to accept data with referential integrity errors in the hope that they’ll be resolved later, but “cross-resource validations” are strongly frowned upon in k8s-land.
I highly recommend “Feedback Control for Computer Systems” by Philipp Janert. This is all stuff other engineering disciplines have been doing for quite some time.
I have a pet theory that all you need to do to create something revolutionary in software engineering is to look at either a paper from 50 years ago or what other engineers have been doing for about a century back, and apply it to software.
I love the concrete reasons you’ve given here as to why Kubernetes is a kind of OS. I wrote a little bit about the idea of Kubernetes as an OS last year and I’ve been increasingly finding myself thinking that analogy is more and more apt. Your average Ubuntu or Windows install is very complex – but for much of the complexity, it needs to be that way. The same thing applies to Kubernetes.
I think there’s two sides that get mixed up a lot.
Kubernetes is complex to some people means that there’s a learning curve involved.
To others it means it’s overly complex system, compared to let’s say Nomad, no orchestrator, implementing the parts you need yourself, …
The latter means that it comes with all the problems that complex systems bring. Things like needing experts, knowledge silos in teams, more surface for bugs in both the system and things that you build on top of it, that tracing down problems can be harder because you need to go through more layers to figure out and fix the root cause, etc.
Kubernetes is also known for breaking changes, deprecating things, which is good in terms of it involving, after all it’s new compared to many other things and it changing so much it means that it stays new. However from a business perspective that means you need to invest time and money to what could be just keeping status quo. It’s probably worthwhile in a particular situation, but it might not bring you much on others
So I think in many situations it’s worthwhile of really analyzing the need for it and not just run it cause you or others know it. And Google using it, or someone using it isn’t a good analysis. Google also runs a data center, implemented their own databases, programming languages and even produces power on their own. So maybe that’s the next thing to focus on.
It’s sometimes a bit shocking how frequently such pretty big decisions are made based on a whim, marketing, someone having read an article, etc.
On the other hand I don’t know of a company that lived or died purely based on a technical decision.
I appreciate the even-handedness and insight here, but my personal instinct (as a non-expert who’s had to work with k8s) is that it’s too generous. I mean, they named something “a mutating admission controller.” I’m sorry, but this is just a dick move. If you care at all about being understood and making things accessible to an audience, you don’t use those sorts of name, and k8s is laden with such enterprisey jargon. It’s part of the culture, it’s unnecessary, and whatever the reasons are, I don’t buy that they’re valid.
The documentation for admission controllers suggests that you don’t need to worry much about them:
What would admission controllers be called in analogous systems? What is the generic term?
I have no idea and I wasn’t trying to critique it on that on level. It just came to mind as an egregious example of the jargon that amasses around all thing kubernetes. Regardless of what they are, it is impossible that this was a good name, and I feel totally comfortable making that claim with no further context. I’ll let the opening paragraph on the page you linked make my case for me:
My god, I’d rather read Lacan.
I agree that reading postmodern philosophy would be preferable to trying to decipher this. However, I view it as an object-oriented usage of the Decorator Pattern; admission controllers decorate requests to create new objects, but don’t have to worry about whether the request is authorized. A poor name for a useful concept.
I’m dealing with the “control loop” reason at the moment and it definitely takes some getting used to. For codgers like me who have been using RDBMSs for a while, it’s scary to allow the system to accept data with referential integrity errors in the hope that they’ll be resolved later, but “cross-resource validations” are strongly frowned upon in k8s-land.
I highly recommend “Feedback Control for Computer Systems” by Philipp Janert. This is all stuff other engineering disciplines have been doing for quite some time.
I have a pet theory that all you need to do to create something revolutionary in software engineering is to look at either a paper from 50 years ago or what other engineers have been doing for about a century back, and apply it to software.
I love the concrete reasons you’ve given here as to why Kubernetes is a kind of OS. I wrote a little bit about the idea of Kubernetes as an OS last year and I’ve been increasingly finding myself thinking that analogy is more and more apt. Your average Ubuntu or Windows install is very complex – but for much of the complexity, it needs to be that way. The same thing applies to Kubernetes.
I think there’s two sides that get mixed up a lot.
Kubernetes is complex to some people means that there’s a learning curve involved.
To others it means it’s overly complex system, compared to let’s say Nomad, no orchestrator, implementing the parts you need yourself, …
The latter means that it comes with all the problems that complex systems bring. Things like needing experts, knowledge silos in teams, more surface for bugs in both the system and things that you build on top of it, that tracing down problems can be harder because you need to go through more layers to figure out and fix the root cause, etc.
Kubernetes is also known for breaking changes, deprecating things, which is good in terms of it involving, after all it’s new compared to many other things and it changing so much it means that it stays new. However from a business perspective that means you need to invest time and money to what could be just keeping status quo. It’s probably worthwhile in a particular situation, but it might not bring you much on others
So I think in many situations it’s worthwhile of really analyzing the need for it and not just run it cause you or others know it. And Google using it, or someone using it isn’t a good analysis. Google also runs a data center, implemented their own databases, programming languages and even produces power on their own. So maybe that’s the next thing to focus on.
It’s sometimes a bit shocking how frequently such pretty big decisions are made based on a whim, marketing, someone having read an article, etc.
On the other hand I don’t know of a company that lived or died purely based on a technical decision.