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

51–60 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#51

Post by oauea »

ryandrake wrote: post #43
colesantiago wrote: post #10

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

My background is in embedded, so I admittedly know extremely little about web development, but whenever I'm curious and sit down to read about microservices and containers and orchestration and all that stuff, my mind starts to numb and I can't help but conclude that 99% of companies that use it probably don't need to. And that they're just a complex way for engineers to keep themselves spinning their wheels and not…

Yeah, everyone feels that way until they ran into several issues that suddenly make containerization look like a great idea.

Re: Google admits Kubernetes container tech is too complex

#53

Post by mfontani »

aroman wrote: post #28
colesantiago wrote: post #10

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!

Dokku is "it" for me, but I'm sure there are others. Works pretty well, but it's (to the best of my knowledge) for one node only.

Re: Google admits Kubernetes container tech is too complex

#54

Post by gostsamo »

ohmywhat wrote: post #6

Sadly, this is a typical Register headline. Google did not say "Kubernetes is too complex" but rather, they are making this new tool - called Autopilot - that is an abstraction layer on top of Kubernetes for certain types of applications / companies. This Autopilot system still uses Kubernetes AFAICT.

No, it is not a typical Register headline, it is a half of a typical Register headline. However, HN has limits on headline lengths and it has been cut instead of being editorialized which afaik is another HN guidelines violation.

Re: Google admits Kubernetes container tech is too complex

#55

Post by vyrotek »

aroman wrote: post #28
colesantiago wrote: post #10

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!

Azure AppService has some pretty good support for that.

https://azure.microsoft.com/en-us/services/app-service/conta...

Re: Google admits Kubernetes container tech is too complex

#56

Post by AbhyudayaSharma »

Clewza313 wrote: post #30
aroman wrote: post #28

Earlier quoted context omitted.

Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!

That's pretty much Cloud Run, no? https://cloud.google.com/run/

Cloud run is great. I'm using an Nginx image to serve my static website. However, if I remember correctly, you can only respond to HTTP(S). So though it may be enough for most usecases, it is not essentially equal to running any container on the cloud.

Re: Google admits Kubernetes container tech is too complex

#57

Post by TobTobXX »

arcturus17 wrote: post #49
trinovantes wrote: post #36

Kubernetes has to be most complex software I've ever tried to learn. I eventually gave up and decided to stick with simple single machine docker-compose deployments. I figure by the time any of my personal projects actually need to scale beyond 1 machine, I'd probably have enough revenue that I can afford to hire someone else to worry about it.

Maybe your starting instances are workhorses, but if you go from something like a t3.medium to two it’s a ~$60 / mth increase... Not something I’d personally optimize for. Also why Docker in the first place? I’m genuinely wondering - in the stacks I run (Express / Python) it doesn’t seem necessary at low scale. Elastic Beanstalk, Heroku, Digital Ocean etc all offer facilities for single-command deploys that work out…

I like Docker for the 'keeping it clean' aspect. Install php, composer and stuff juat because one of the projects you host requires it? Nope. Have to make excessive configuration on a system component just to run another application? Nope. Forgot how you set it up and now you are struggeling at the new machine? Use the Dockerfile.

Re: Google admits Kubernetes container tech is too complex

#58

Post by arcturus17 »

threeseed wrote: post #39
colesantiago wrote: post #10

What happened to "focus on the business logic / application"? Are we just making rabbit holes out of rabbit holes of abstraction using kubernetes? I just use and push code to Heroku and I'm done for the day, simple. NoOps I call it. I wish more tools and platforms were like this.

And Heroku is great for simple apps. When you start having a lot of pieces to manage eg. cache, database, auth, multiple applications then Kubernetes comes into its own. Because then you can scale, monitor, trace, debug, log, backup, audit, encrypt and visualise all of those pieces in exactly the same way. And do it irrespective of which cloud you use or whether it's even in the cloud at all.

Even if your default starting stack is somewhat complex, for example, separate client and server apps, database, cache, and queue, most one-click cloud providers (ex Heroku or ElasticBeanstalk) offer ways of unifying logs, monitoring, simple provisioning, etc. You are “locked-in” in that you can’t move to another provider within an hour, but the lock-in would still be very low, you can use generic technologies (ex: Memcached or Redis) and have an impact only on a few config files...

I’m not telling people what to do, if you like K8s or Docker or what have you knock yourself out, and I mean it. For example, people keep telling other people on HN not to use React and that’s a hill I’d die on - and could write a dissertation defending it. I’m just wondering what the dev experiences of others are so I may learn from them.

Re: Google admits Kubernetes container tech is too complex

#59

Post by AnHonestComment »

arcturus17 wrote: post #49
trinovantes wrote: post #36

Kubernetes has to be most complex software I've ever tried to learn. I eventually gave up and decided to stick with simple single machine docker-compose deployments. I figure by the time any of my personal projects actually need to scale beyond 1 machine, I'd probably have enough revenue that I can afford to hire someone else to worry about it.

Maybe your starting instances are workhorses, but if you go from something like a t3.medium to two it’s a ~$60 / mth increase... Not something I’d personally optimize for. Also why Docker in the first place? I’m genuinely wondering - in the stacks I run (Express / Python) it doesn’t seem necessary at low scale. Elastic Beanstalk, Heroku, Digital Ocean etc all offer facilities for single-command deploys that work out…

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.

Re: Google admits Kubernetes container tech is too complex

#60

Post by NathanFlurry »

trinovantes wrote: post #36

Kubernetes has to be most complex software I've ever tried to learn. I eventually gave up and decided to stick with simple single machine docker-compose deployments. I figure by the time any of my personal projects actually need to scale beyond 1 machine, I'd probably have enough revenue that I can afford to hire someone else to worry about it.

I’d recommend giving Docker Swarm + Traefik a shot. It’s dead simple to set up manually and has very little “magic” in how things work under the hood. Plus much of your existing Docker Compose config will work out of the box. It vastly simplified the deployment process too.

I previously avoided Docker Swarm for ages since I assumed it involved the same level of complexity as k8s. I also initially figured that managed k8s would be a safer bet than managing my own Swarm cluster, but if you’ve used anybody’s managed k8s (or read https://k8s.af), you’ll realize that every cloud provider has their own closed source fork of k8s with plenty of nasty bugs that you can’t do anything about.

Post reply on HN