6 ms·

K8s will be superseded by a simpler yet more powerful tool sooner rather than later. Just like it happened with: - Corba, MRI -> http apis - XML, Soap -> json

K8s will be superseded by a simpler yet more powerful tool sooner rather than later. Just like it happened with: - Corba, MRI -> http apis - XML, Soap -> json - Flash -> html5 - Perforce, svn, mercurial -> git Etc. We can’t think of anything better than k8s right now, but that’s just how it works. The moment that new tech appears, we all will be asking ourselves “how could we possibly use k8s?”

hutrdvnj 5y ago
This is not always the case. Sometimes we use a technology for decades and just upgrade its version. Like HTML, HTTP, GCC, ... the list goes on. It's very possible that we still use k8s as major container orchestrator in a decade, just in a higher version.
- xg15 5y ago
  I think a better way to think about it is in separating API and implementation or wire format and semantics. In terms of the wire-format and the low-level concepts, HTTP2 and 3 are completely different from HTTP1.x. it's not an extension like HTTP1.1 was, it's a complete reinvention. However, what they did was to reuse the high-level semantics and the "API" of HTTP1, so as a web developer you can pretty much pretend you're still using HTTP1 and let the browser and web server do the rest. This makes transition significantly easier. I could imagine something similar with K9s. Maybe some other product will come along that supports (a subset of) the k9s API but does something different under the hood. I believe, k9s itself did so with Docker: You can still define k9s images using Dockerfiles, even though no piece of Docker is actually involved in the process.
radicalbyte 5y ago
I find this amusing considering that the JSON community are slowly re-inventing XML with their versions of XSL, XSLT etc.
- tkiolp4 5y ago
  JSON is already 20 years old. I guess things can’t stay the way they are forever (and 20 years in the IT world is a lot).
  - marcyb5st 5y ago
    I am not sure. There are already superior (IMHO) alternatives and JSON still sticks around unaffected. For instance, at work we use protobuffers everywhere and now I am so used to that that I started using them also on my personal projects since I believe they are so convenient. In fact, I am not sure how many hours I saved from not having to write serialisation/deserialisation code, and how you can get full IDE support for your messages. However, it seems protobuffers (or alternatives like flatbuffers, cap'n proto) are still niches compared to JSON.
    - leetrout 5y ago
      Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them. However I have yet to convince anyone at an org that isn't already using them that they will change things for the better. Schema once, code everywhere. It is really nice. Have you seen Buf? https://buf.build/ https://buf.build/
      - marcyb5st 5y ago
        Indeed a chicken and egg problem since investing in the tooling to make protobuf usage smooth requires some prior use. No, thanks for sharing! I will have a look!
    - vstollen 5y ago
      I'm not too far into protobuf, etc., but do you only prefer them for your internal services, or do you actually see them as a viable solution for public-facing APIs?
      - 5y ago
tkiolp4 5y ago
To extend my comment: notice how the tech on the left side was/is usually backed up by companies or corporations while the tech on the right side usually is not. I think this is just a natural flow of software: some piece of software emerges for the benefit of a big corp disguised as open source… and suddenly everyone uses it. It takes some time to the “internet community” to come up with something better and less tied to any company in particular. It’s a win for everyone: Google is having his piece of cake with GKE now, the community thanks the effort and will use k8s as an inspiration to make something better.
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.
xg15 5y ago
> Flash -> html5 HTML5 is definitely not simpler than Flash was. I'd argue, it's far more complex, if you include all the sub-technologies and frameworks required to reach feature parity. There was also no "natural" progression from Flash to HTML5. Oracle and the browser vendors had to run an involved depreciation campaign to get developers off flash and move them to HTML5. If you had left the web ecosystem on it's own, my guess is, we'd still be writing flash applications today. > Perforce, svn, mercurial -> git This progression was definitely natural, but I doubt again that git is less complex than svn or mercurial. However, one big advantage of git is that it is extremely easy to set up: You can just install it and use it locally without bothering any admins or setting up any servers. Once you are already using it, it's also easy to connect your repo to a server. So, I'd argue, git has better UX and better availability than the alternatives, but it's not necessarily simpler.
- deleted 5y ago
  [deleted]
- gravypod 5y ago
  > required to reach feature parity I think most people don't need full feature parity. That's why a lot of these techs take off. They need something that is easier to understand. Similar with kubernetes, there's like 5 permutations of software deployment people actually want to do. Deployments are one of those but there are still a few areas that you have to get hacky with StatefulSets to achieve. Once some PaaS-wrapper for kubernetes takes off we'll see the V2 of that idea as a stand alone cluster management thing. If someone nips some ideas from MaaS [0] we might even see on-prem bare metal take off again once people realize they're getting screwed on perf/bandwidth and many of the benefits of cloud providers are already provided to you by something like Kube. [0] - https://maas.io/ https://maas.io/
- pyuser583 5y ago
  There are so many devs around now that have never programmed or used Flash. It’s details are becoming myths.
- jbergens 5y ago
  This is the first time _ever_ that I've heard git UX described as simpler or easier than something else. As far as I remember Mercurial was easier to start with but Github came along and won.
ksec 5y ago
>Flash -> html5 >Perforce, svn, mercurial -> git Not sure I agree with those two. Edit: Someone beats me to it.
rfoo 5y ago
I think all your examples are "simpler but less powerful" instead of "simpler yet more powerful". 25 years later and still, worse is better.
godisdad 5y ago
- Java -> wasm
nunez 5y ago
nomad has been trying for years despite being "simpler" and open-source; it's still in third place :(
bg24 5y ago
I think K8s will become simpler and easier to use. There will be platforms (eg. Knative) on K8s, that will become the norm for starters.
brianmcc 5y ago
Agreed. My go-to example is: J2EE and EJBs in particular -> Spring.

hutrdvnj 5y ago

This is not always the case. Sometimes we use a technology for decades and just upgrade its version. Like HTML, HTTP, GCC, ... the list goes on. It's very possible that we still use k8s as major container orchestrator in a decade, just in a higher version.

xg15 5y ago
I think a better way to think about it is in separating API and implementation or wire format and semantics. In terms of the wire-format and the low-level concepts, HTTP2 and 3 are completely different from HTTP1.x. it's not an extension like HTTP1.1 was, it's a complete reinvention. However, what they did was to reuse the high-level semantics and the "API" of HTTP1, so as a web developer you can pretty much pretend you're still using HTTP1 and let the browser and web server do the rest. This makes transition significantly easier. I could imagine something similar with K9s. Maybe some other product will come along that supports (a subset of) the k9s API but does something different under the hood. I believe, k9s itself did so with Docker: You can still define k9s images using Dockerfiles, even though no piece of Docker is actually involved in the process.

radicalbyte 5y ago

I find this amusing considering that the JSON community are slowly re-inventing XML with their versions of XSL, XSLT etc.

tkiolp4 5y ago
JSON is already 20 years old. I guess things can’t stay the way they are forever (and 20 years in the IT world is a lot).
- marcyb5st 5y ago
  I am not sure. There are already superior (IMHO) alternatives and JSON still sticks around unaffected. For instance, at work we use protobuffers everywhere and now I am so used to that that I started using them also on my personal projects since I believe they are so convenient. In fact, I am not sure how many hours I saved from not having to write serialisation/deserialisation code, and how you can get full IDE support for your messages. However, it seems protobuffers (or alternatives like flatbuffers, cap'n proto) are still niches compared to JSON.
  - leetrout 5y ago
    Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them. However I have yet to convince anyone at an org that isn't already using them that they will change things for the better. Schema once, code everywhere. It is really nice. Have you seen Buf? https://buf.build/ https://buf.build/
    - marcyb5st 5y ago
      Indeed a chicken and egg problem since investing in the tooling to make protobuf usage smooth requires some prior use. No, thanks for sharing! I will have a look!
  - vstollen 5y ago
    I'm not too far into protobuf, etc., but do you only prefer them for your internal services, or do you actually see them as a viable solution for public-facing APIs?
    - 5y ago

tkiolp4 5y ago

To extend my comment: notice how the tech on the left side was/is usually backed up by companies or corporations while the tech on the right side usually is not. I think this is just a natural flow of software: some piece of software emerges for the benefit of a big corp disguised as open source… and suddenly everyone uses it. It takes some time to the “internet community” to come up with something better and less tied to any company in particular. It’s a win for everyone: Google is having his piece of cake with GKE now, the community thanks the effort and will use k8s as an inspiration to make something better.

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.

xg15 5y ago

> Flash -> html5 HTML5 is definitely not simpler than Flash was. I'd argue, it's far more complex, if you include all the sub-technologies and frameworks required to reach feature parity. There was also no "natural" progression from Flash to HTML5. Oracle and the browser vendors had to run an involved depreciation campaign to get developers off flash and move them to HTML5. If you had left the web ecosystem on it's own, my guess is, we'd still be writing flash applications today. > Perforce, svn, mercurial -> git This progression was definitely natural, but I doubt again that git is less complex than svn or mercurial. However, one big advantage of git is that it is extremely easy to set up: You can just install it and use it locally without bothering any admins or setting up any servers. Once you are already using it, it's also easy to connect your repo to a server. So, I'd argue, git has better UX and better availability than the alternatives, but it's not necessarily simpler.

deleted 5y ago
[deleted]
gravypod 5y ago
> required to reach feature parity I think most people don't need full feature parity. That's why a lot of these techs take off. They need something that is easier to understand. Similar with kubernetes, there's like 5 permutations of software deployment people actually want to do. Deployments are one of those but there are still a few areas that you have to get hacky with StatefulSets to achieve. Once some PaaS-wrapper for kubernetes takes off we'll see the V2 of that idea as a stand alone cluster management thing. If someone nips some ideas from MaaS [0] we might even see on-prem bare metal take off again once people realize they're getting screwed on perf/bandwidth and many of the benefits of cloud providers are already provided to you by something like Kube. [0] - https://maas.io/ https://maas.io/
pyuser583 5y ago
There are so many devs around now that have never programmed or used Flash. It’s details are becoming myths.
jbergens 5y ago
This is the first time _ever_ that I've heard git UX described as simpler or easier than something else. As far as I remember Mercurial was easier to start with but Github came along and won.

ksec 5y ago

>Flash -> html5 >Perforce, svn, mercurial -> git Not sure I agree with those two. Edit: Someone beats me to it.

rfoo 5y ago

I think all your examples are "simpler but less powerful" instead of "simpler yet more powerful". 25 years later and still, worse is better.

godisdad 5y ago

- Java -> wasm

nunez 5y ago

nomad has been trying for years despite being "simpler" and open-source; it's still in third place :(

bg24 5y ago

I think K8s will become simpler and easier to use. There will be platforms (eg. Knative) on K8s, that will become the norm for starters.

brianmcc 5y ago

Agreed. My go-to example is: J2EE and EJBs in particular -> Spring.