4 ms·

> Imagine the K8S team porting from Go to some other language for similar reasons. k8s was originally written in Java, so they have already done this once.

tyingq 8y ago
I didn't know that, but it makes it a more interesting comparison. I imagine at least part of rewriting it in Go was to "eat your own dogfood".
- pjmlp 8y ago
  Actually it was more like "new team got in charge" actually. There is a FOSDEM 2019 talk about it.
  - tyingq 8y ago
    Thanks! The talk: "The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
    - tannhaeuser 8y ago
      Wow. Didn't realize it was that bad: > We look at what it would take to begin undoing the spaghetti code that is the various Kubernetes binaries Well at least the developers are being frank about it I guess.
    - patrec 8y ago
      One wonders if there'll be a similar talk in a year... > The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project. As an occasional user of kubernetes, minikube etc. it's not something I would have guessed to have been developed by the word's top engineers. I mean kubernetes tries to, and probably manages to provide an useful abstraction, but at a few million LOC and a few man-month of full time senior engineering effort to run anything in production it's not exactly a epitome of elegant and efficient engineering.
      - pjmlp 8y ago
        You would be surprised at the quality of Android tooling stable releases, to the point that now there is Project Marble in place to try to improve its image. https://adtmag.com/articles/2019/01/17/project-marble.aspx https://adtmag.com/articles/2019/01/17/project-marble.aspx If you want to have some reading fun, check /r/androiddev/ every time there is a "stable" release.
        tyingq 8y ago
        I bet k8s would look different if it were written by developers used to a more limited set of cpu, io, and memory resources.
        pjmlp 8y ago
        Well, given the hops one has to go through for the privilege to work at Google, another level of code quality is to be expected.
        patrec 8y ago
        Even people working for Google on Android tell me the tooling is pretty garbage, so I'm less surprised than you might think ;) The interesting thing with Kubernetes is that it's basically a re-imagining of Borg, which one assumes was not a few million lines of code when it was already running all of Googles infra more than a decade ago. It's obviously not solving the exactly same problem (e.g. Google correctly recognized that DNS isn't so hot and wrote their own replacement protocol, BNS which wouldn't fly for external adoption etc.). But I'd be curious to know how Borg's code quality and size back when it became the standard way to run stuff at Google maybe 12 years ago compares to Kubernetes today.
- CamouflagedKiwi 8y ago
  My guess would be more on the side of native binaries (i.e. no runtime JVM dep) and lower memory use, but could be that too.

tyingq 8y ago

I didn't know that, but it makes it a more interesting comparison. I imagine at least part of rewriting it in Go was to "eat your own dogfood".

pjmlp 8y ago
Actually it was more like "new team got in charge" actually. There is a FOSDEM 2019 talk about it.
- tyingq 8y ago
  Thanks! The talk: "The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
  - tannhaeuser 8y ago
    Wow. Didn't realize it was that bad: > We look at what it would take to begin undoing the spaghetti code that is the various Kubernetes binaries Well at least the developers are being frank about it I guess.
  - patrec 8y ago
    One wonders if there'll be a similar talk in a year... > The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project. As an occasional user of kubernetes, minikube etc. it's not something I would have guessed to have been developed by the word's top engineers. I mean kubernetes tries to, and probably manages to provide an useful abstraction, but at a few million LOC and a few man-month of full time senior engineering effort to run anything in production it's not exactly a epitome of elegant and efficient engineering.
    - pjmlp 8y ago
      You would be surprised at the quality of Android tooling stable releases, to the point that now there is Project Marble in place to try to improve its image. https://adtmag.com/articles/2019/01/17/project-marble.aspx https://adtmag.com/articles/2019/01/17/project-marble.aspx If you want to have some reading fun, check /r/androiddev/ every time there is a "stable" release.
      - tyingq 8y ago
        I bet k8s would look different if it were written by developers used to a more limited set of cpu, io, and memory resources.
        pjmlp 8y ago
        Well, given the hops one has to go through for the privilege to work at Google, another level of code quality is to be expected.
      - patrec 8y ago
        Even people working for Google on Android tell me the tooling is pretty garbage, so I'm less surprised than you might think ;) The interesting thing with Kubernetes is that it's basically a re-imagining of Borg, which one assumes was not a few million lines of code when it was already running all of Googles infra more than a decade ago. It's obviously not solving the exactly same problem (e.g. Google correctly recognized that DNS isn't so hot and wrote their own replacement protocol, BNS which wouldn't fly for external adoption etc.). But I'd be curious to know how Borg's code quality and size back when it became the standard way to run stuff at Google maybe 12 years ago compares to Kubernetes today.
CamouflagedKiwi 8y ago
My guess would be more on the side of native binaries (i.e. no runtime JVM dep) and lower memory use, but could be that too.