Live data from Hacker News

As Kubernetes grows, a startup ecosystem develops in its wake

techcrunch.com

41–50 of 156 posts

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#41

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

Kube is too complex. To derive any kind of business value from it you need highly skilled people. The winner of the container orchestration battle will be the one that simplifies, not complicates.

To me this is just another hype train, like TensorFlow/Caffe before it, and like Hadoop/Spark before that.

These tools all have their uses in specific, non-common cases, but for your average business they are a net loss in time and money.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#42
Recently I have been playing with kubernetes through Rancher. I like how easy it is to install kubernetes through rancher, essentially I ran 2 commands: 1. on the machine that runs rancher and 2. on the first node in my cluster.

After a few days of playing I set up lets encrypt with load balancing, a running app (Rails). A remaining issue are persistent volumes and how truly persistent these are. I haven't found out yet which solution I should pick for this. Longhorn is a Rancher product, which is probably what I will read more about now, but I cannot be sure. There are so many concepts and terminology that you need to figure out. Having Rancher in between is not helping me get a hang of kubernetes itself more purely of course.

A while back I was playing with Docker Swarm and I must say that I like Docker Swarm better in the sense that it feels closer to the source and because it is built into Docker. I get a feeling however that Kubernetes is where the future is so learning more about Docker Swarm is probably less worthwhile.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#43
post #40

Earlier quoted context omitted.

Every tech companies with thousands of employees has google problems.

I highly doubt it. Even most of Google doesn't have "google problems". (Having to design things for "google scale" when you have no reason to was a popular gripe while I was there.) You don't go Google scale because it's cool to. You either do it because you absolutely have to, or you don't because, thankfully, you don't have to.

It sure is trendy to think so though!

I'm currently supporting ops of some "eventually consistent, globally distributed" (if you can fathom through the previous engineer's algorithms) built-from-scratch system designed to be resilient in the face of multi-megaX-transactions-per-second, that currently contains all of 8K records.

Whereas stackoverflow.com runs on SQL. Their own hardware at that.

I half wonder if a large chunk of AWS's revenue could be replaced by https://www.amazon.co.uk/electrical-sockets-adhesive-sticker...

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#44

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

What I'm waiting for, though, is for a big player to do a modern, clean "Kubernetes first" cloud offering.

IBM Cloud Private is a Kubernetes-based private cloud offering, though from your other points I don't think it will have everything you want.

https://www.ibm.com/cloud/private

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#45
post #4

Earlier quoted context omitted.

Well RedHat's OpenShift.com is kinda that, have a look at it !

I did infrastructure work on OpenShift for the majority of last year, and I can tell you that my team's experience was absolutely horrendous. OpenShift, to me, suffers from "too early syndrome", and since it was building features on top of k8s before the underlying platform was mature, has ended up in a very weird state in relation to k8s. Frankly, it was a supremely painful platform to work on. They obfuscated just…

My team's experience is the exact opposite - we're very happy with it, especially because it _doesn't_ obscure the k8s API and is quickly rebased on top of upstream.

It's been great for us since we were productive from day one without having to worry about setting up Kubernetes or figuring out things like deployments and builds. Their documentation is great and the Ansible installer is very helpful. They have a lot of operational docs, which are invaluable (day two ops guide, among others).

Apart from the obvious PaaS features, it has a lot of small and seemingly minor improvements like "oc rsync --watch" (copy changed files to a container) or "oc rsh dc/foobar", proper auditing, and a lot of other small stuff that makes life easier.

Red Hat is one the main k8s contributors and is responsible for the RBAC implementation, among others.

You did not mention any particular pain points, but I'd love to hear about them.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#46
post #41

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

Kube is too complex. To derive any kind of business value from it you need highly skilled people. The winner of the container orchestration battle will be the one that simplifies, not complicates. To me this is just another hype train, like TensorFlow/Caffe before it, and like Hadoop/Spark before that. These tools all have their uses in specific, non-common cases, but for your average business they are a net loss in…

Too complex compared to what? All other commonly used web infrastructure is complex in various ways.

In my experience building and running Kubernetes clusters for Fortune 500 companies is that actually it's much simpler, it's just different from traditional infrastructure.

Different != Complex.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#47
post #16

Earlier quoted context omitted.

Kubernetes came out of the engineering team at Google. It was created by engineers for engineers. The fact that it's being exploited by enterprise consulting types doesn't change that premise.

But there's this from a fairly influential former googler: https://medium.com/@steve.yegge/honestly-i-cant-stand-k8s-48... It's a quick read, but to summarise: it's almost as complex as google's internal borg system but the benefit isn't even close (partially because nobody else has google problems). I can't down K8s personally, as I've never used it myself. But I wonder if there's the possibility of a system that's…

I didn't know he was still writing.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#48

Earlier quoted context omitted.

> and not something that wasn't designed to create jobs for consultants. I wouldn't be so sure about that. Consulting companies are drawn to operational complexity, of which Kubernetes has a lot of, like bears are to honey. https://kubernetes.io/partners/ https://www.google.com/search?q=kubernetes+consulting&ie=utf...

Kubernetes came out of the engineering team at Google. It was created by engineers for engineers. The fact that it's being exploited by enterprise consulting types doesn't change that premise.

>Kubernetes came out of the engineering team at Google.

Attaching the Google name to projects stopped having meaning ~5 years ago. Their hiring process optimizes for fresh graduates who know nothing about engineering. Something coming out of Google means nothing, especially when Google itself doesn't even use it!

>It was created by engineers for engineers.

So was openstack. Then the feature creep happened.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#49
post #16

Earlier quoted context omitted.

But there's this from a fairly influential former googler: https://medium.com/@steve.yegge/honestly-i-cant-stand-k8s-48... It's a quick read, but to summarise: it's almost as complex as google's internal borg system but the benefit isn't even close (partially because nobody else has google problems). I can't down K8s personally, as I've never used it myself. But I wonder if there's the possibility of a system that's…

I don't think that's true. If you believe the team that designed Kubernetes, Kubernetes is an attempt to improve on Borg. Borg is an accumulation of a decade's work with containers at Google, and has been described by googlers as a rich but a little messy, having been designed incrementally over many years as needs have surfaced. Borg could never be open-sourced because it's so specific to Google; for example, it use…

All of the things you described as improvements are more complexity and layers of indirection. Kubernetes may be an attempt to improve on Borg but adding on a bunch of features and plugin architectures to solve more use cases isn't necessarily an improvement.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#50
post #38

Earlier quoted context omitted.

At least DO supports IPv6, for our application the 40ms latency penalty we encountered for half our customers when on GCP from not supporting IPv6 was not worth it. On that note, HE.net really peers with everyone over IPv6, even ISPs that won't peer with them on IPv4, its quite impressive how much better the routing can be on certain ISPs due to this!

Genuinely curious: how does the lack of IPv6 cause 40ms of latency?

Tunneling to a v6 provider.
Post reply on HN