4 ms·

My understanding is that there is a faction in Google that believes that making Kubernetes freely available as it did was a massive strategic mistake on the par

by Zafira 6y ago

My understanding is that there is a faction in Google that believes that making Kubernetes freely available as it did was a massive strategic mistake on the part of Google[1], tantamount to giving away the crown jewels. With this in mind, my impression is that there is a strong suspicion that Google is trying to find a way to continue to control the direction and ability to monetize Istio (and future projects if this works out) which obviously makes IBM irate since it now throws into doubt a slew of potential business opportunities on their end. [1] https://twitter.com/ThatMightBePaul/status/1279880169344335874 https://twitter.com/ThatMightBePaul/status/12798801693443358...

ForHackernews 6y ago
That's interesting because there's also a vocal contingent who believes Google giving away Kubernetes was a punji trap that the rest of the tech world has falling into. Is k8s an amazing force multiplier or an unmanageable white elephant? Can it be both?
- polotics 6y ago
  K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non-enormous IT systems operator will eventually realize they can be a pure-play no-fixed-costs service provider. The only challenge is of course that good ops is not the same thing depending on scale, so hype is essential to bring the plebs into accepting maximal complexity of highest-scale ops.
  - pjmlp 6y ago
    Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...
    - tracker1 6y ago
      I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications. The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models. Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.
      - pjmlp 6y ago
        I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries. The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.
        tracker1 6y ago
        My biggest practical issues are around a few libraries with really restrictive licensing without good floss alternatives. At least short of the effort to hire and create appropriate ML models in house, which isn't a proficiency we currently have.
    - harpratap 6y ago
      The API and the packaging standard is the main contract between users. Once everyone has agreed to the fact that they need to package their applications into containers, the orchestration can be done in any way. Google's Cloud Run uses Kubernetes API + Container packaging but doesn't actually run on GKE, it's running on their regular old compute engine and users don't even come to know.
- tracker1 6y ago
  It's a bit of both. In the end, I appreciate it and have been an advocate for the use of k8s. The harder part is actually hiring or developing in-house skills to manage the cluster(s). Not every company can afford a 6-7 figure consulting contract for a couple small clusters.
  - harpratap 6y ago
    I never understood why a small company wants a completely in-house developed platform. Wouldn't it be more economical to directly use Cloud offerings? Or in case you need on-prem wouldn't it be wiser to just pay for offerings like OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes?
    - ForHackernews 6y ago
      > OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes All of these are pretty pricey.
    - tracker1 6y ago
      For k8s, we have been leveraging some cloud solutions. Working with govt agencies, it's been a difficult push. At least with k8s, we can do internal, cloud and hybrid models depending on application and client needs. Moving away from bespoke applications deployments has helped a lot.
foobiekr 6y ago
Geeze. If kubernetes is google’s Crown Jewels they must be in terrible shape internally.
- brutus1213 6y ago
  Not a google dev but I looked closely at K8s in the early days .. in my personal opinion, I think it is complete fiction that K8s was Google opensourcing their actual code (in the traditional way). I think they rewrote the bulk of the initial code drop. So agreed that K8s is not Google's crown jewels by any stretch. They were inspired by the Borg paper I'm guessing though the early scheduler in K8s was laughable IIRC.
  - jeffbee 6y ago
    This is confirmed by K8s/Borg devs on blogs and Twitter. k8s shares not one line of code with Borg. One easy way to tell is every line of Borg is in C++ and every line of k8s is Go. This thread is a pretty good explanation of how k8s is derived from the need to be compatible with some Borg concepts, while not deriving from Borg itself. https://twitter.com/bgrant0607/status/1131202013411176448 https://twitter.com/bgrant0607/status/1131202013411176448
jeffbee 6y ago
There is (or was, while I was there) a feeling coming from Tech. Infra. leadership that the company must avoid "industry-enabling" software projects and conference papers. There also is/was a faction that desired to avoid "getting Hadooped", referring to the map/reduce knockoff. Hadoop has a large mindshare outside Google but it is also incredibly bad and about 20 years behind Google internal practices. It both enables and disables the industry at the same time. So they didn't want that to happen with Borg.

by Zafira 6y ago

ForHackernews 6y ago

That's interesting because there's also a vocal contingent who believes Google giving away Kubernetes was a punji trap that the rest of the tech world has falling into. Is k8s an amazing force multiplier or an unmanageable white elephant? Can it be both?

polotics 6y ago
K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non-enormous IT systems operator will eventually realize they can be a pure-play no-fixed-costs service provider. The only challenge is of course that good ops is not the same thing depending on scale, so hype is essential to bring the plebs into accepting maximal complexity of highest-scale ops.
- pjmlp 6y ago
  Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...
  - tracker1 6y ago
    I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications. The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models. Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.
    - pjmlp 6y ago
      I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries. The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.
      - tracker1 6y ago
        My biggest practical issues are around a few libraries with really restrictive licensing without good floss alternatives. At least short of the effort to hire and create appropriate ML models in house, which isn't a proficiency we currently have.
  - harpratap 6y ago
    The API and the packaging standard is the main contract between users. Once everyone has agreed to the fact that they need to package their applications into containers, the orchestration can be done in any way. Google's Cloud Run uses Kubernetes API + Container packaging but doesn't actually run on GKE, it's running on their regular old compute engine and users don't even come to know.
tracker1 6y ago
It's a bit of both. In the end, I appreciate it and have been an advocate for the use of k8s. The harder part is actually hiring or developing in-house skills to manage the cluster(s). Not every company can afford a 6-7 figure consulting contract for a couple small clusters.
- harpratap 6y ago
  I never understood why a small company wants a completely in-house developed platform. Wouldn't it be more economical to directly use Cloud offerings? Or in case you need on-prem wouldn't it be wiser to just pay for offerings like OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes?
  - ForHackernews 6y ago
    > OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes All of these are pretty pricey.
  - tracker1 6y ago
    For k8s, we have been leveraging some cloud solutions. Working with govt agencies, it's been a difficult push. At least with k8s, we can do internal, cloud and hybrid models depending on application and client needs. Moving away from bespoke applications deployments has helped a lot.

foobiekr 6y ago

Geeze. If kubernetes is google’s Crown Jewels they must be in terrible shape internally.

brutus1213 6y ago
Not a google dev but I looked closely at K8s in the early days .. in my personal opinion, I think it is complete fiction that K8s was Google opensourcing their actual code (in the traditional way). I think they rewrote the bulk of the initial code drop. So agreed that K8s is not Google's crown jewels by any stretch. They were inspired by the Borg paper I'm guessing though the early scheduler in K8s was laughable IIRC.
- jeffbee 6y ago
  This is confirmed by K8s/Borg devs on blogs and Twitter. k8s shares not one line of code with Borg. One easy way to tell is every line of Borg is in C++ and every line of k8s is Go. This thread is a pretty good explanation of how k8s is derived from the need to be compatible with some Borg concepts, while not deriving from Borg itself. https://twitter.com/bgrant0607/status/1131202013411176448 https://twitter.com/bgrant0607/status/1131202013411176448

jeffbee 6y ago

There is (or was, while I was there) a feeling coming from Tech. Infra. leadership that the company must avoid "industry-enabling" software projects and conference papers. There also is/was a faction that desired to avoid "getting Hadooped", referring to the map/reduce knockoff. Hadoop has a large mindshare outside Google but it is also incredibly bad and about 20 years behind Google internal practices. It both enables and disables the industry at the same time. So they didn't want that to happen with Borg.