4 ms·

Kubernetes is the new tech your are looking for. It's not simpler, because it _needs_ to be complex in order to provide portable, heterogeneous, application dep

by Fiahil 5y ago

Kubernetes is the new tech your are looking for. It's not simpler, because it _needs_ to be complex in order to provide portable, heterogeneous, application deployments. How was it before ? A bunch of unstandardized shell scripts and ansible playbooks that you could not reliably automate, let alone port to a different topology ? How could we possibly use that ?

zozbot234 5y ago
> It's not simpler, because it _needs_ to be complex in order to provide portable, heterogeneous, application deployments. No, the complexity of Kybernetes is mostly in its auto-tuning and auto-scaling features. That's the stuff that needs to be re-engineered from the ground up in an elegant way. If history is any guide, we'll probably end up with some variant of it in systemd sooner rather than later.
- p_l 5y ago
  Autoscaling is honestly a minor thing (I have yet to use Autoscaling other than cluster autoscaling since 2016) and autotuning... what autotuning are you talking about? The binpacking support? Also, I do wonder what "elegant way" would be, considering that k8s is a very elegant system (once you notice that YAML is just one of the serialization formats to make it easier for raw API access by humans).
tannhaeuser 5y ago
> bunch of unstandardized shell scripts Eh, nothing unstandardized about POSIX shell scripts, as opposed to a bunch of ever-changing YAML files with questionable semantics. I think this generation of "cloud natives" have drunk too much of the cool aid served by "cloud providers" and their clever faux grassroots marketing/blogs. As compared to the Linux and BSD "movement" (no such thing), which was about liberating ourselves from having to run apps on commercial OS's, based on a well-understood OS baseline (POSIX, a term coined by RMS).
reacharavindh 5y ago
Eh. I like and use Kubernetes as a tool. But, this over simplification at best. Kubernetes is not a defecto and always better replacement of Ansible and shell scripts. In most small scale deployments, the value brought by Kubernetes is trumped by the costs of complexity. Bunch of scripts you say? Now you have bunch of yaml files laying around. Atleast before, you could find and fix problems manually quickly. Now, first find someone who has been in the weanies if kubernetes and it’s ecosystem to fix your problem. In large scale infrastructure, kubernetes may bring the standardisation that is needed. Being able to hire people who knows kubernetes would be easier than hiring people who know how you wired your infra with ansible playbooks and scripts. Portability you say? How easy do you think it is to move your infra(not just the apps, but - users, security rules, storage etc) to another kubernetes provider? EKS to AKS? Do you think AWS IAM and whatever equivalent Azure uses would be straight portable? Your S3 buckets and it’s policies to Azure block storage? Selling K8s with infra portability is a lie. Applications - yes, but that is achievable by other means as well.
- Fiahil 5y ago
  Portability is _THE_ killer feature of kubernetes. You may argue that it is not straightforward to move from EKS to AKS, but consider that any replacement solution will suffer from the same shortcomings. However, moving from 1 cluster in one region to another within another, is very simple. And that did not exists before kubernetes.
otabdeveloper4 5y ago
No. Kubernetes solves imaginary problems, not real ones. The reason k8s took off is because it provides the fief that devops engineers so desperately need to be motivated to stay on the job. (And that's mostly a good thing. Look at software testing to see what happens when you don't give developers career incentives.)
- Fiahil 5y ago
  > Kubernetes solves imaginary problems, not real ones. Portability between cloud providers is not imaginary. Same for portability of network configuration.

by Fiahil 5y ago

zozbot234 5y ago

> It's not simpler, because it _needs_ to be complex in order to provide portable, heterogeneous, application deployments. No, the complexity of Kybernetes is mostly in its auto-tuning and auto-scaling features. That's the stuff that needs to be re-engineered from the ground up in an elegant way. If history is any guide, we'll probably end up with some variant of it in systemd sooner rather than later.

p_l 5y ago
Autoscaling is honestly a minor thing (I have yet to use Autoscaling other than cluster autoscaling since 2016) and autotuning... what autotuning are you talking about? The binpacking support? Also, I do wonder what "elegant way" would be, considering that k8s is a very elegant system (once you notice that YAML is just one of the serialization formats to make it easier for raw API access by humans).

tannhaeuser 5y ago

> bunch of unstandardized shell scripts Eh, nothing unstandardized about POSIX shell scripts, as opposed to a bunch of ever-changing YAML files with questionable semantics. I think this generation of "cloud natives" have drunk too much of the cool aid served by "cloud providers" and their clever faux grassroots marketing/blogs. As compared to the Linux and BSD "movement" (no such thing), which was about liberating ourselves from having to run apps on commercial OS's, based on a well-understood OS baseline (POSIX, a term coined by RMS).

reacharavindh 5y ago

Eh. I like and use Kubernetes as a tool. But, this over simplification at best. Kubernetes is not a defecto and always better replacement of Ansible and shell scripts. In most small scale deployments, the value brought by Kubernetes is trumped by the costs of complexity. Bunch of scripts you say? Now you have bunch of yaml files laying around. Atleast before, you could find and fix problems manually quickly. Now, first find someone who has been in the weanies if kubernetes and it’s ecosystem to fix your problem. In large scale infrastructure, kubernetes may bring the standardisation that is needed. Being able to hire people who knows kubernetes would be easier than hiring people who know how you wired your infra with ansible playbooks and scripts. Portability you say? How easy do you think it is to move your infra(not just the apps, but - users, security rules, storage etc) to another kubernetes provider? EKS to AKS? Do you think AWS IAM and whatever equivalent Azure uses would be straight portable? Your S3 buckets and it’s policies to Azure block storage? Selling K8s with infra portability is a lie. Applications - yes, but that is achievable by other means as well.

Fiahil 5y ago
Portability is _THE_ killer feature of kubernetes. You may argue that it is not straightforward to move from EKS to AKS, but consider that any replacement solution will suffer from the same shortcomings. However, moving from 1 cluster in one region to another within another, is very simple. And that did not exists before kubernetes.

otabdeveloper4 5y ago

No. Kubernetes solves imaginary problems, not real ones. The reason k8s took off is because it provides the fief that devops engineers so desperately need to be motivated to stay on the job. (And that's mostly a good thing. Look at software testing to see what happens when you don't give developers career incentives.)

Fiahil 5y ago
> Kubernetes solves imaginary problems, not real ones. Portability between cloud providers is not imaginary. Same for portability of network configuration.