But Isn't kubernetes meant for managing containers easily.
Google admits Kubernetes container tech is too complex
101–110 of 449 posts
Re: Google admits Kubernetes container tech is too complex
#102Earlier quoted context omitted.
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.
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 great for running batch jobs; we tried and our jobs kept getting killed/throttled. Use a vm for that.
Luckily, there are lots of other Google services for that that you can plugin for that sort of stuff. Cloudrun is great if you are planning to use those things.
Kubernetes is what you use when you want to mix stateful and stateless stuff so you can avoid depending on those services. That makes sense if you need to support multiple clouds or on premise installations. But otherwise, it's a lot of extra complexity and devops even before you consider the overhead of managing the kubernetes cluster. There are lots of companies that talk themselves into needing this where the need is arguably a bit aspirational. I've been on more than one expensive project where we served absolutely no traffic at all with hundreds of dollars worth of kubernetes clusters idling for months on end that had no realistic hopes of ever getting more than a very modest amount of traffic even if everything worked out as they planned.
Re: Google admits Kubernetes container tech is too complex
#103I can't fight the feeling that this is all circling back to the application server stuff that was popular for a time. And, really, I can't tell when those went so wrong. :(
The circle of tech: 1. Someone has an idea. It's alright. Really good for their use case. Someone else hears about it, likes it, and adapts it to a similar use case. So and so forth until the idea has a large user base 2. Employees of large companies hear about the idea and implement it 3. Marketing gets a hold of the idea, gives it a flashy name, and uses it in promotions 4. A majority of the loudest voices in the i…
> Marketing gets a hold of the idea, gives it a flashy name, and uses it in promotions
After a half-decade in the industry, I am beginning to realize there is a lot of bad engineering hiding behind marketing and emoji. So many of these web tools have nightmarish interfaces and add complexity that, for most of the industry, is unnecessary. But their docs pages are full of rocket ships and confetti.... I swear, seeing a page with rocket ship emoji has become such a turnoff. Why do we need our engineering handed to us sprinkled with decorations like a cupcake?
And the imposter syndrome that the entire industry seems to share dictates that a large percentage of developers feel like they need to be using these tools as a badge to wear saying, "Yes, I am with it and hireable."
Meanwhile, the technology itself keeps churning because there is now a profession full of people believing that creating and open sourcing the Next Big Thing in ____ Technology is the best way to move their career forward. People keep reinventing wheels because everyone is focused on making a name for themselves with the new; no one notices the person doing mundane maintenance on Rails or whatever.
I think it's been this way since the 70s/80s to some extent, after having done some reading on the history of the profession. I think it's just scaled with the number of programmers and the Internet has applied its intensification effects.
Re: Google admits Kubernetes container tech is too complex
#104What 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.
In my day, we used to just insert the server into the rack, plug it into the network, terminal into it and configure it. I'm not being sarcastic here. There was a clear correspondence between what we were doing and what it meant for the infrastructure. Now there are so many layers of abstractions that we've basically forgotten it's all just CPUs, hard disks, memory modules and network connections.
People still do that, a lot. It doesn't make the headlines.
Re: Google admits Kubernetes container tech is too complex
#105Earlier 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.
gRPC and WebSockets are in preview. Doesn't look like you can use arbitrary ports though. https://cloud.google.com/run/docs/triggering/grpc
You can open just 1 https port but you can map whatever port in your docker container to that. Some websocket implementations work with a second port and that just doesn't work. But you should probably split those services into two. But if you use something that can mix websockets and normal https traffic over 1 port, it works great.
Re: Google admits Kubernetes container tech is too complex
#106Kubernetes 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.
It's the right attitude. The management fees alone for this autopilot thing are 0.10$ per hour. Or about 70$/month. It's a bargain considering all the hidden costs kubernetes imposes in terms of requiring people that know how to tame the complexity associated with it (i.e. very expensive devops people costing magnitudes more than that). Automating those people away is worth money. I like Cloud Run for the same reason…
I think you mean 70$, not 700$
Re: Google admits Kubernetes container tech is too complex
#107As someone who has never worked with containers, I find this rather amusing: Kubernetes is so complex that Google needs to roll out an "autopilot" feature, yet "it has won in the critically important container orchestration space". Makes you wonder what the alternatives must have looked like?!
Re: Google admits Kubernetes container tech is too complex
#108What 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…
> How did the world get into this situation where you need all this complexity just to deploy and configure not even an application, but part of an application? Amazing!
Because everyone else is doing it.
Things have gotten so complex that we need complex solutions, but w're afraid to make and own the solution ourselves because of cost, focus on core business or recruitment/knowledge concerns. So we need to find the next best open source solution to leverage the collaborative effort to reduce time and cost and have a large community to fall back on for support. And because everyone jumps on board of the same train all use cases must/will be accounted for (else the solution will fade into a niche), meaning the solutions becomes a problem in and of itself.
Repeating the cycle once again.
Re: Google admits Kubernetes container tech is too complex
#109Putting 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 mentioned elsewhere in this page.
Re: Google admits Kubernetes container tech is too complex
#110What 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!
render.com