Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google admits Kubernetes container tech is too complex

theregister.com

Post reply on HN
Print view View original

361–370 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#361

Post by sontek »

stickfigure wrote: post #351
anchochilis wrote: post #221

I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…

> "Kubernetes is the biggest quality-of-life improvement I've experienced in my career." Just wait until the developers discover Google App Engine, Heroku, or DigitalOcean App Platform.

Yeah, I think thats the point though. Kubernetes enables the orchestration and observability of a PaaS in a much more flexible way so that you can get all of that while still matching the requirements of your business.

I think Heroku and DigitalOcean App Platform are still going to be popular for small setups (as will things like Amplify) but when you outgrow those (or realize you are paying too much for them) then Kubernetes is a reasonable option.

Re: Google admits Kubernetes container tech is too complex

#364

Post by Sodman »

bavell wrote: post #260
pram wrote: post #200

Earlier quoted context omitted.

From my experience it's actually sold as a simpler alternative to other infra provisioning. So you end up with situations where a team deploys whatever with a helm chart, and it sets up the stuff like magic and they build on it. Then when something goes wrong they literally have no idea how to fix anything and it becomes a waking nightmare.

As a longtime and frequent user of k8s, I stay away from helm charts. I tried them out when they first got popular but I found they introduced more friction than they solved on the whole. Not every addon/tool for the k8s ecosystem is worth it. I also don't bother with the ever-growing list of service meshes... not enough value to me for the overhead. K8s is definitely the simpler alternative for me but there is still…

This is such a great point and so frequently skimmed over in k8s discussions. We as tech folks tend to focus on the front page blog posts about 1000s of nodes and all of the orchestration that goes into complicated top 1% high-traffic/high-complexity use-case setups. In reality there are a lot of profitable businesses out there happily running a simple cluster set up with a single-digit number of deployments chugging along on it with zero down-time.

Really when looking at tools in the k8s ecosystem, it's better to approach it as you would importing a new library into your application. Most decent devs wouldn't blindly import a new lib so that they can copy/paste a single line of code they found online for a business critical function, and k8s tools should be no different. We must think about what value does a given tool bring, and is it worth the cost of learning/maintenance? Sometimes the answer is a resounding "yes", but too often the question isn't even asked.

Re: Google admits Kubernetes container tech is too complex

#365

Post by strlen »

cameronh90 wrote: post #279
cyphar wrote: post #242

Earlier quoted context omitted.

Linux containers and equivalent technologies are virtualisation (specifically OS virtualisation[1]), just not a VM. Hardware virtualisation (VMs) isn't the only kind of virtualisation that exists. [1]: https://en.wikipedia.org/wiki/Operating_system-level_virtual...

By that logic, processes are arguably virtualisation too. They do after all use virtual memory. Threads, processes and containers exist on a continuum.

Indeed they are! The notion that each process has its separate address space is called virtual memory for that reason.

See also cgroups: while this feature is used by the container run times, it predates Docker, and can be used standalone with normal processes.

Re: Google admits Kubernetes container tech is too complex

#366

Post by dntrkv »

neonological wrote: post #321
anchochilis wrote: post #221

I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…

I’m tired of the complainers of the complainers. First a technology seems cool, then after engineers become experienced with the tool the warts rear itself and you get a vocal group of complainers. It doesn’t end there... after complaining for a really long time two things happen. First off so much time has passed that you get these domain experts (Devops people) whose entire job is to mess with kubernetes. Second th…

> A good tool would be something like allows me to to get it up and running in a week just by reading some docs. Even better an hour. Could such a tool exist and replace Kubernetes? Yes. Does such a tool exist? No.

Instead of complaining, why don't you build this tool? That's the problem I have with complainers.

Re: Google admits Kubernetes container tech is too complex

#367

Post by ascendantlogic »

anchochilis wrote: post #221

I work on a 3-person DevOps team that just finished migrating ~20 services from GCE vms running docker-compose to GKE. It's taken us a little over a year. Partly because K8s has a steep learning curve, but also because safely transitioning services without disrupting product teams adds a lot of overhead. The investment is already yielding great returns. Developers are happy. Actual quote: "Kubernetes is the biggest q…

That was my experience with Kubernetes when I set it up for a QA cluster a few years back. That learning curve is more like a sheer cliff face but once you get to the top the view is really nice. But getting there is a hell of a hike. It's easier now since every major cloud has a managed offering but my journey was pre-EKS so it was doubly as intense for me.

Re: Google admits Kubernetes container tech is too complex

#368

Post by moksly »

dmingod666 wrote: post #219
moksly wrote: post #203

Earlier quoted context omitted.

Stackoverflow has always run on a couple of IIS instances. If you’re not bigger than them don’t worry. You can pretend to be Netflix or Google, and build your tech-stack like they do. Or you can stop wasting your resources setting up a tech stack that you’re never going to get a return of investment on.

Why a few though? Couldn't they do with just 1..? that would make people on HN more happier it seems. Stack Overflow is not a unit of measurement that anyone would be able to take seriously or find useful? How many stack overflows is one asana? Or how many stack overflows is one trello? Horizontal scaling, docker K8s have their own benefits that are many and obviously to the industry. you don't need to be google to d…

> Why a few though?

Because it’s less dangerous and cheaper?

> Horizontal scaling, docker K8s have their own benefits that are many and obviously to the industry.

Which is why SO runs on more than one IIS...

You don’t need a tech-stack, that is apparently even too complex for google considering the article, to scale horizontally.

> If you deploy one server for each app and each team vs deploying a common K8s cluster where is the higher investment?

The investment comes from the complexity. We’ve seen numerous proofs of concepts in my country, and in my sector of work, where different IT departments spent one or two 2-5 full years worth of man hours trying to adopt a perfect devops tech-stach.

Maybe that’s because they were incompetent, you’re free and possible right to claim so, but that’s still professional teams expending real world resources and failing.

From a management perspective, and this is where I’m coming from much more than a technical perspective mind you, the most expensive resource you have is your employees. If software is so complex that I need one or two full time operators to run it, well, let’s just say I could run more than a million azure web apps, and have our regular Microsoft certified operators handle it.

> You claim more ROI with more physical hardware and more servers?

I haven’t owned my own iron since 2010. All our on-prem servers, and we still do have those, are virtual and running on rented iron.

I think we may be speaking past each other though. My point is financial and yours appear to be mostly technical. If you can set up and run your K8s without expending resources, then good for you, a lot of companies and organisations have proven to be unable to do that though, and in those cases, I think they would’ve been better off not doing it, until they needed to.

Re: Google admits Kubernetes container tech is too complex

#369

Post by koheripbal »

cactus2093 wrote: post #228
pantelisk wrote: post #184

Earlier quoted context omitted.

I agree with you. However, after spending years and years trying to compile software that came with cryptic install instructions. Or have the author insist that since it works on their machine I 'm just doing something stupid. Docker was largely able to fix that. It's a somewhat odd solution for a too common problem, but any solution is still better than dealing with such an annoying problem. (source: made docker the…

Completely agree. The whole compile chain for most software and reliance on linked libraries, implicit dependencies like locale settings changing behavior, basically decades of weird accidents and hacks to get around memory and disk size limits, can be a nightmare to deal with. If using slow dynamic languages, or modern frontend bunglers, all the implicit c extension compilations and dependencies can still be a pain.…

Aren't we conflating compile complexities with runtime complexities here? There are plenty of open-source applications that offer pre-compiled binaries.

Re: Google admits Kubernetes container tech is too complex

#370

Post by hrktb »

bob1029 wrote: post #277
pantelisk wrote: post #184

Earlier quoted context omitted.

I agree with you. However, after spending years and years trying to compile software that came with cryptic install instructions. Or have the author insist that since it works on their machine I 'm just doing something stupid. Docker was largely able to fix that. It's a somewhat odd solution for a too common problem, but any solution is still better than dealing with such an annoying problem. (source: made docker the…

I am totally on board with the idea of improving productivity. The issue I see is that this is avoiding a deeper problem - namely that the software stack requires a max-level wizard to set up from scratch each time. Refactoring your application so that it can be cloned and built and ran within 2-3 keypresses is something that should be strongly considered. For us, these are the steps required to stand up an entirely…

The issue Docker solves for me is not the complexity or number of steps but the compatibility.

I built a service that is installed in 10 lines that could be ran through a makefile, but I assume specific versions of each library of the system and don’t intend to test against the hundreds of possible system dependencies combinations or assume it will surely be compatible anyway.

The dev running the container won’t building their own debian installs with the specific version required in my doc just to run the install script from there, they just instanciate the container and run with it.

Post reply on HN