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

161–170 of 449 posts

Re: Google admits Kubernetes container tech is too complex

#161

Post by FlyingSnake »

goatinaboat wrote: post #160
FlyingSnake wrote: post #109

Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…

but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill There are very strong financial incentives for every individual developer and sysadmin to adopt Kubernetes, regardless of the impact it has on the organisation as a whole. In a sense this is engineering reaching the level of corporate maturity of the sales department who will optimise everything for…

I'm sure there's a name to this phenomenon. Companies want stable software, and Regular Joe want better pay, but companies won't pay unless Joe starts doing crazy complex stuff that complicates things further.

Re: Google admits Kubernetes container tech is too complex

#162

Post by danjac »

FlyingSnake wrote: post #109

Putting on my Asbestos Longjohns: The more I look into k8s ecosystem, the more I'm convinced that it's one of those things that suits FAANG etc, but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill. After all no one got fired for buying IBM and recommending Kubernetes. Most teams need a simpler deployment strategies that other's have succinctly mentio…

Putting on my tinfoil hat: it suits FAANG to have potential competitors burn their runways on baroque tech fads like Kubernetes or . Extra credit if they end up hosting their overly complex solution on your platform.

Re: Google admits Kubernetes container tech is too complex

#163

Post by Avalaxy »

Kubernetes is dramatically complex to the point where I refuse to touch it if I have to do any configuring myself. Unfortunately there are not really any good alternatives. I work on the Azure stack myself, and it has only Azure Container Instances, which Microsoft recommends to not use for production purposes (without explanation why). For deploying a simple machine learning model on Azure Machine Learning, you need to set up a whole Kubernetes cluster, and if I remember correctly it also needs to have a minimum of 6 machines which is a very high amount for simple projects. At least with Azure ML they have an abstraction layer over Kubernetes so that you don't have to deal with any of its intricacies.

Re: Google admits Kubernetes container tech is too complex

#164

Post by je42 »

grey-area wrote: post #116
trumpeta wrote: post #85

Earlier quoted context omitted.

Maybe I can offer an answer to your question, I have worked at a couple of companies where we ran "small" scale k8s clusters (1-100 nodes as you say). We have chosen k8s and I would again, because its nice to use. Its not necessarily easier, as you point out, the complexity of managing the cluster is considerable. But if you use a managed cluster like EKS or DO's k8s offering, you don't have to worry too much about t…

Thanks, that's really interesting. Everyone has different challenges and requirements, and of course different experiences. For smaller setups (say 1-10 services) I'm quite happy with cloud config and one VM per process behind one load balancer per service. It's simple to set up, scale and reproduce. This setup doesn't autoscale, but I've never really felt the need. We use Go and deploy one static binary per service…

>We use Go and deploy one static binary per service at work with minimal dependencies so docker has never been very interesting.

how do you deploy your static binary to the server? (without much downtime ?)

Re: Google admits Kubernetes container tech is too complex

#165

Post by je42 »

jillesvangurp wrote: post #102
AbhyudayaSharma wrote: post #56

Earlier quoted context omitted.

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.

Websockets now work on cloud run. We implemented that last month. Cloud run does have a few limitations: no service discovery built in, no docker compose support, limited set options for CPU/memory, no persistent disk, etc. But it's great for things like a simple Spring Boot server or any kind of stateless service. But you won't be running redis or a database there. It's just not designed to do that. It's also not gr…

websocket support: awesome ! have been waiting for that ! :)

Re: Google admits Kubernetes container tech is too complex

#166

Post by machiaweliczny »

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!

CloudFoundry has ability to host your own docker images easily AFAIK.

Edit: fixed name

Re: Google admits Kubernetes container tech is too complex

#167

Post by FlyingSnake »

endymi0n wrote: post #120
FlyingSnake wrote: post #96

Earlier quoted context omitted.

> If you actually took the steps of learning the basic abstractions, then for me it's really hard to see what you could still get rid of. This argument basically sums up to "Developers just need discipline, and stop blaming the tools". While this is a sound argument on paper, the intrinsic complexity of software systems make it hard to pin the blame on developers. BTW This is the same argument Uncle Bob makes which i…

I get what you're saying, but my point is a bit more nuanced: If your goal is to build highly reliable and available services to end users that are secure and scalable with a team of more than 10 engineers, eventually you will run into more than 50% of the concepts in Kubernetes anyway and end up re-inventing them. Scaling up and down, node draining, finding out whether services are healthy, RBAC, resource distributi…

Agreed, the truth usually lies somewhere in between and my point was we can't absolve the tools/ecosystems and put it on squarely on the devs. That definitely doesn't absolve teams and they need to do their homework before jumping on the bandwagon. K8s is great if you know what you're signing up for.

Re: Google admits Kubernetes container tech is too complex

#168

Post by danjac »

FlyingSnake wrote: post #161
goatinaboat wrote: post #160

Earlier quoted context omitted.

but the regular Joe developer has caught on the fad and wants to add it to his repertoire, even though it's an overkill There are very strong financial incentives for every individual developer and sysadmin to adopt Kubernetes, regardless of the impact it has on the organisation as a whole. In a sense this is engineering reaching the level of corporate maturity of the sales department who will optimise everything for…

I'm sure there's a name to this phenomenon. Companies want stable software, and Regular Joe want better pay, but companies won't pay unless Joe starts doing crazy complex stuff that complicates things further.

Regular Joe learns complex stuff at your expense. He then leaves for greener pastures and higher pay thanks to the boost to his resume. You are then left with complex stuff you need to maintain and so you have to hire another Regular Joe for a higher salary than your first Regular Joe.

Re: Google admits Kubernetes container tech is too complex

#169

Post by kkapelon »

yen223 wrote: post #72
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.

Looking at the istio-linkerd-traefik-consul-whatever-the-heck mess of cloud-native ecosystem projects, I want to decree that backend engineers are no longer allowed to make fun of Javascript engineers for having too many frameworks anymore.

Not a good analogy.

All the tools you mention are not integrated into your app neither change how you write code. In fact your application shouldn't even know what service mesh you are using.

I can write a back end application once and then have it run with istio/linkerd/traefik/whatever with zero code changes.

That doesn't happen in the Javascript world. The choice of framework directly affects your code.

Post reply on HN