Hacker News Reader

Comment by fh973 | Hacker News Reader

It seems a bit that the big players also realize that making money off their technology investments would be nice.

Here we have the interest of IBM/Redhat that as a services company benefits from an as open as possible model, whereas Google as a product company notices that their hugely successful k8s play does not turn into business for their cloud product as intended.

View on HN

Could you please elaborate on what this has to do with this dispute about how to open source the trademark?

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/12798801693443358...

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.

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?

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.

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,...

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.

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.

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.

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.

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.

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?

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.

> OpenStack, CloudFoundry, DataDog, New Relic, GKE-on-prem and the likes

All of these are pretty pricey.

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

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.

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

Reply on news.ycombinator.com