More accurate headline: The Register publishes ad for Google Cloud services
Google admits Kubernetes container tech is too complex
411–420 of 449 posts
Re: Google admits Kubernetes container tech is too complex
#412I 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…
Nice! Thanks to you we just reached level 3: The complainers of complainers of complainers! Level 4 is coming!
Re: Google admits Kubernetes container tech is too complex
#413I 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…
You spent more than 3 person-years migrating twenty services from one container orchestration system to another and you think it was worth it? Not sure that seems worth it to me...
Re: Google admits Kubernetes container tech is too complex
#414I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today).
I've seen this (a long time ago) in the education world market. Very small school with a STEM program. They had specific scientific software they wanted undergrads to use (and some of it was pretty proprietary and used to interface with lab equipment) + a pre-configured IDE.
Instead of going through the compatibility matrix of OS and their versions they just gave all students a VM image that would "just work". Everyone could bring in their own devices and as long as you could run an hypervisor everything would "just work".
Re: Google admits Kubernetes container tech is too complex
#415Earlier quoted context omitted.
I used Docker for embedded. Running a cluster across your IOT fleet (1k+ devices; 5-10 apps each) gives a nice interface for pushing out tasks, choosing applications for a device, configuring supervisor-device relationships, etc. It turns out from scratch Docker containers on ARM are very portable. I think you’re being dramatic — embedded is notorious for crazy builds of weird config flags to even get “hello world” t…
That sounds fascinating. Would be very interesting to read more about your IoT fleet, tasks, and deployment with that stack.
[deleted]
Re: Google admits Kubernetes container tech is too complex
#416Earlier quoted context omitted.
I use Docker without the network virtualization as a package manager. Docker make it easy to run the same version of code in different places and let’s things run next to each other without version conflicts. Also, I think you’re in a very small minority not to care about $720/yr increases in your hobbies.
GP was talking about projects that had revenue, and about "hiring someone" past a single instance. I replied that beyond a single instance, you can probably get away with not hiring a K8s devops person and just spinning another instance. I'm not sure you've read this whole thing right. And yes, I certainly wouldn't mind paying an additional $720 / yr for a project that had revenue; I almost certainly wouldn't want to…
[deleted]
Re: Google admits Kubernetes container tech is too complex
#417Earlier quoted context omitted.
> but you could use that to dismiss any technology at all No, you can't; you need three (-ish) factors: 1. The technology is sufficiently incompatible with what you're currently using that you need a rewrite to use it (eg, this generally doesn't happen with gcc -> llvm, for example). 2. The technology is sufficiently (faux-)popular that it's possible to convince a pointy-haired boss that you need to switch to it (eg,…
I think in your eagerness to 'gotcha' me, you missed my point. :) Anyway, we're trying to assess Kubernetes' value proposition (i.e., to answer "does it suck?"). If your system for answering that question depends on already knowing the answer, it's not a very useful system.
> we're trying to assess Kubernetes' value proposition (i.e., to answer "does it suck?").
Well, I'm not, since I already know that, but if you don't know that yet, then your position makes more sense. (That is, using "dismiss" in the sense of finding out that it sucks, rather than (as I read it) in the sense of justifying a refusal to use technology that you already know sucks.)
Unfortunately, due to market-for-lemons dynamics, it's usually not possible to convey knowledge that a particular technology sucks until things have already gone horribly wrong. See eg COBOL or (the Java-style corruption of) Object Oriented Programming.
Re: Google admits Kubernetes container tech is too complex
#418Earlier quoted context omitted.
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…
Kubernetes is not too complex. There are things to learn no doubt, but it's easy to reason about once you cross the initial learning curve.
Ofcourse transitions can fail. People can think yea let's do this small thing and end up chewing off a much bigger problem than they thought they were getting into. But that problem is in the whole of tech. "Let's just use our present people and switch from all proprietary to all open source in 3 months.." yea, best of luck with that... You need a solid team and going all in on K8s is hard, you need technical talent and leadership to drive this.
Agreed, maybe it may not be for everyone. Benefits are both technical and financial, less compute resources used, more reliable deploys, more resilient services. The problems being solved by this are not trivial. There are tangible benefits. Is it a risk? Ofcourse it is. The risk is not in the technology, the risk is in the competence of the team deploying it. If it can't change and adapt, maybe a lot more fundamental things need to change in that organization than just deploying a new orchestration layer.
My only point is, this shift from dedicated servers to VMs and now to containers is a fundamental shift in how things are done. People can hate on it all they like, but it's a better way of doing things and everyone will catch-up eventually.
Re: Google admits Kubernetes container tech is too complex
#419I 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…
You spent more than 3 person-years migrating twenty services from one container orchestration system to another and you think it was worth it? Not sure that seems worth it to me...
If you have about 20 developers spending 10% of their time fighting with your current system it adds up fast. I mean 10% may be high but 20 may be low. It depends a lot on the exact situation if it was worth the time.
Re: Google admits Kubernetes container tech is too complex
#420Earlier quoted context omitted.
Besides just giving you a warm fuzzy feeling of running only one server. What is the point of running one server? Do you also object to them running in the cloud in VMs and not on physical hardware that they own? Sounds like an old man's "kids these days" rant..
Netflix in fact 'run on servers' https://papers.freebsd.org/2019/fosdem/looney-netflix_and_fr...
Ofcourse, everything runs on servers. Question is, who owns and maintains the hardware.
The link you shared just says they manage their OS layer, ofcourse they do. Everyone running on AWS VMs is responsible for their own OS layer. Wether they want precise control over their OS doesn't change their preference for who owns and manages the hardware..