4 ms·

It is good to have healthy skepticism for new things. But I don't think k8s is just the "cool thing to do". Here's some reasons why running an enterprise on it

It is good to have healthy skepticism for new things. But I don't think k8s is just the "cool thing to do". Here's some reasons why running an enterprise on it is better than on bare VM metal: 1. Containers are a better application level abstraction than VMs. Why as someone deploying an app should I care about machine details. I want my application to be deployed n replicas with x resources and to be discoverable. 2. Containers make your application self documenting on its dependencies. Yes it is some work to get your stuff containerized but we haven't come across anything yet that was all that difficult. 3. Running a container on its own on bare Docker does not give you discovery, multiple nodes, restart policies or many other things k8s does. 4. Much of dev ops roll your own that is going on is solving problems that nearly everyone has and why not do it in a proven environment that does nearly all of the work for you. I don't think at all that putting apps in containers, shipping them with a resource request/service descriptor, and then exposing them via service discovery is going anywhere at all. Whether it is k8s and Docker or something else, once you are using it, it is clear that this is really the abstraction deployments should be at. I'd say the odds are that you do need k8s stuff for any enterprise/business deployment of services. I'd be surprised if within a few years people are doing it any way else.

cookiecaper 9y ago
1. This is called "shared hosting". I sympathize with that desire. k8s is a way to roll your own shared host. Disinterested application developers who resent having to look at a command line do really like k8s because they treat it like a shared host platform, but they fail to appreciate the middle layer of complication that it entails, or the stickier elements of its architecture. A lot of ignorant app developers don't realize that you don't really get most of k8s's promises unless your application is already specifically designed to handle a transient, disappear-at-a-moment's-notice lifecycle, and most existing software is not built around these assumptions. It can't all be shoehorned in at the infrastructure level. Database servers are a fine example of an application architecture that is antithetical to this. 2. This is called "static linking". I also sympathize with static linking, but again this comes with implications that are not well understood by many of its advocates. In 4 years, I expect that some fad will emerge to repopularize dynamic linking under some new name, like "securable containerized orchestrated hypothalmized applicationators". Everyone will say "Dude, I can't imagine nobody using securable containerized orchestrated hypothamlmized applicatorness in 4 years". Rinse and repeat. 3. Yes, Docker sucks. We agree. 4. Sure, but you don't need to roll your own. Much of trendy devops is a reinvention of old things that we've already had and tried over the last several decades. For the most part, these come with the same old problems, and there are reasons they fell out of favor. There are definitely times when the tradeoffs will fall such that Kubernetes makes sense. Those times are much rarer than most people who are running k8s want to admit. That's because they're subconsciously running k8s as a status symbol, and lying to themselves about its necessity and value in their use case. I'm not saying the way we were doing things before k8s came around was exactly right. For example, going back to shared hosting is probably not a bad idea for the vast majority of things, and stuff like logging into your FTP server and copying your files have been gussied up as "cloud object storage" (and costs a lot more money now). So it's really just a general oscillation of trends, I guess.

cookiecaper 9y ago

1. This is called "shared hosting". I sympathize with that desire. k8s is a way to roll your own shared host. Disinterested application developers who resent having to look at a command line do really like k8s because they treat it like a shared host platform, but they fail to appreciate the middle layer of complication that it entails, or the stickier elements of its architecture. A lot of ignorant app developers don't realize that you don't really get most of k8s's promises unless your application is already specifically designed to handle a transient, disappear-at-a-moment's-notice lifecycle, and most existing software is not built around these assumptions. It can't all be shoehorned in at the infrastructure level. Database servers are a fine example of an application architecture that is antithetical to this. 2. This is called "static linking". I also sympathize with static linking, but again this comes with implications that are not well understood by many of its advocates. In 4 years, I expect that some fad will emerge to repopularize dynamic linking under some new name, like "securable containerized orchestrated hypothalmized applicationators". Everyone will say "Dude, I can't imagine nobody using securable containerized orchestrated hypothamlmized applicatorness in 4 years". Rinse and repeat. 3. Yes, Docker sucks. We agree. 4. Sure, but you don't need to roll your own. Much of trendy devops is a reinvention of old things that we've already had and tried over the last several decades. For the most part, these come with the same old problems, and there are reasons they fell out of favor. There are definitely times when the tradeoffs will fall such that Kubernetes makes sense. Those times are much rarer than most people who are running k8s want to admit. That's because they're subconsciously running k8s as a status symbol, and lying to themselves about its necessity and value in their use case. I'm not saying the way we were doing things before k8s came around was exactly right. For example, going back to shared hosting is probably not a bad idea for the vast majority of things, and stuff like logging into your FTP server and copying your files have been gussied up as "cloud object storage" (and costs a lot more money now). So it's really just a general oscillation of trends, I guess.