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

331–340 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#331

Post by Guest42 »

jaywalk wrote: post #326
Guest42 wrote: post #268

Earlier quoted context omitted.

Yes, the number of proposed db switched I’ve seen is remarkably high. I once interviewed for a role as a database developer and was confused to find out they didn’t have the database that the role pertained to. One of the early questions in the interview was how quickly I could migrate production from ms sql to pg. Needless to say that was a gigantic red flag and I hope they found the right person for that job. I’ve…

I've got relatively modestly-specced SQL Servers handling tables with hundreds of millions and even billions of rows without breaking a sweat. Somebody either just really wanted a new toy to play with, or has no idea what indexes are.

Exactly, I’ve seen Sql servers handle billions of rows with 2 thousand columns. I think also people that work too long at one company don’t realize how problems were solved elsewhere.

Re: Google admits Kubernetes container tech is too complex

#332

Post by pferde »

jeremyjh wrote: post #276
MaxBarraclough wrote: post #215

Earlier quoted context omitted.

> 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). At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.

I don't know if that is the most important reason it is not equivalent. It also doesn't have any system processes; there is no systemd, sshd, no crond, etc. It doesn't need its own firewall rules configured or its own security managed. I could go on but I think you already get the point.

Indeed - essentially, a container is a glorified chroot with a few (important) bells and whistles attached to it.

Re: Google admits Kubernetes container tech is too complex

#333

Post by Guest42 »

eloff wrote: post #281
Guest42 wrote: post #268

Earlier quoted context omitted.

Yes, the number of proposed db switched I’ve seen is remarkably high. I once interviewed for a role as a database developer and was confused to find out they didn’t have the database that the role pertained to. One of the early questions in the interview was how quickly I could migrate production from ms sql to pg. Needless to say that was a gigantic red flag and I hope they found the right person for that job. I’ve…

> I’ve also seen a switch from rdbms to Hadoop because a company had “millions” of rows. Luckily on this one I only had to rewrite a handful of queries. Wat. That's gross. It probably costs them more per query now than the rdbms did.

Didn’t even think about that part because I don’t know too much about Hadoop other than it seemed impractical.

Re: Google admits Kubernetes container tech is too complex

#334

Post by zug_zug »

anchochilis wrote: post #311
vp8989 wrote: post #305

Earlier quoted context omitted.

Yeh this list is not surprising and none of these things you mentioned exclusively require Kubernetes or running containers in Prod. Like I mentioned in another comment, it feels like the purpose of Kubernetes is that it's "brand" provides political cover to introduce these practices to the engineering org.

I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper. That doesn't mean Kubernetes is a good fit for every organization or workload. You can roll your own anything with enough time and manpower. Whether it makes sense to do so depends on your circumstances.

Well for example, I'm a lead devops on a team of 2-3. We have 6 core services.

For the last several years, due to static load we've been fine with 2 instances per service. Now that we want autoscale (even though all the real load is really just the DB), it seems we could get ourselves onto AWS autoscale in ~1 month, though it would require some coding.

Spending 3 devops on 1 year doing something is a red-flag to me. If your changes save devs 1 hour per deploy, it'll pay off 6,000 deploys from now.

Re: Google admits Kubernetes container tech is too complex

#335

Post by anchochilis »

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…

There already are a number of platforms that make deploying and operating apps very simple! Heroku, AppEngine, Lambda, so many others.

Your 5-person startup does not need a DevOps engineer. Your 50-person org should start thinking about it. Your 500-person company probably needs multiple DevOps engineers -- having every dev team independently figure out how to handle things like deployments, reliability, and security is chaotic and wasteful. There are a lot of details that only start to matter at scale, and both Kubernetes and dedicated infrastructure teams are for this use case.

Re: Google admits Kubernetes container tech is too complex

#336

Post by mushishi »

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…

One great boon is to use Kotlin code to factor deployment descriptors into reusable parts that are somewhat statically type checked. I wasn't responsible for the migration from legacy system to Kubernetes, but that seemed to me a big win. Aside from being able to update the whole, and only parts of the system so trivially.

For me the scariest part would be that it's not tech I would use (i.e. update the descriptors) regularly, so what if something goes wrong, how quick would I be able to identify the problem. I have no answer to that because I'm off the project.

Re: Google admits Kubernetes container tech is too complex

#337

Post by warent »

gizzlon wrote: post #117
warent wrote: post #92

Earlier quoted context omitted.

I'm not sure why you're getting downvoted unless people are afraid that you're sponsored by Google. Your experience aligns with mine. Running a SaaS app by myself that serves heavy loads around 1 rps with burst of 400+ rps, k8s works really great for my use case. But I grant you, it has been a very complex, painful journey to get this working right, and in fact I'm still making tweaks and adjustments. Plus, often tim…

"k8s works really great for my use case. [..] But I grant you, it has been a very complex, painful journey to get this working right, and in fact I'm still making tweaks and adjustments." TBO, it does not sound like it's working great for your use-case =) Wouldn't something like Cloud Run, AppEgine Standard or Heroku be much simpler and cheaper? Or just a single $5-15 per month* VM? * depending on how much oomph you…

Sadly no because I need stateful RAM. A single VM might work but I'm scared

Re: Google admits Kubernetes container tech is too complex

#338

Post by M2Ys4U »

syrusakbary wrote: post #21

Kubernetes adds a vast amount of complexity, and in my rationale is because it centers scaling on the wrong unit (the Operating System). Docker introduced a great level of abstraction and reproducibility over platforms. However, Docker (or OS-based containers) are the most atomic unit of computation on Kubernetes. Which causes centering scaling on the Instance, instead of the Application or even the functions. This l…

>I believe a VM centered on the app (WebAssembly VMs) or functions (serverless approach) is the right computation unit to allow proper scalability and a simpler and more powerful system on the long term.

Docker's co-founder agrees:

"If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing."

https://twitter.com/solomonstre/status/1111004913222324225

Re: Google admits Kubernetes container tech is too complex

#339

Post by neonological »

anchochilis wrote: post #335
neonological wrote: post #321

Earlier quoted context omitted.

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…

There already are a number of platforms that make deploying and operating apps very simple! Heroku, AppEngine, Lambda, so many others. Your 5-person startup does not need a DevOps engineer. Your 50-person org should start thinking about it. Your 500-person company probably needs multiple DevOps engineers -- having every dev team independently figure out how to handle things like deployments, reliability, and security…

Yeah my point is, if you’re migrating to kube without using some service that handles all the details, even the 5 person start up needs a dedicated devops team.

Re: Google admits Kubernetes container tech is too complex

#340

Post by anchochilis »

zug_zug wrote: post #334
anchochilis wrote: post #311

Earlier quoted context omitted.

I don't know what to tell you except that with years of experience implementing this infrastructure outside Kubernetes, letting Kubernetes handle it is cheaper. That doesn't mean Kubernetes is a good fit for every organization or workload. You can roll your own anything with enough time and manpower. Whether it makes sense to do so depends on your circumstances.

Well for example, I'm a lead devops on a team of 2-3. We have 6 core services. For the last several years, due to static load we've been fine with 2 instances per service. Now that we want autoscale (even though all the real load is really just the DB), it seems we could get ourselves onto AWS autoscale in ~1 month, though it would require some coding. Spending 3 devops on 1 year doing something is a red-flag to me.…

It's not the only thing we've been doing, just the most important.

I think it's great you guys have 2.5 dedicated people operating 6 services across 12 prod instances, with that kind of ratio our team would be 15 people!

Post reply on HN