Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cult of Kubernetes

christine.website

Post reply on HN
Print view View original

281–290 of 338 posts

Re: The Cult of Kubernetes

#281

Post by cloverich »

thewarrior wrote: post #56
usgroup wrote: post #12

I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…

I think jumping on new tech and marketing yourself is a good decision for a developer as its a good way to increase their compensation and market value. If you're a developer stuck maintaining a Java spring app at some unknown company the best way to make a shift is to pick up Go or something and move to a startup. Else your career will stagnate. The best way to get promoted at many companies is to write a framework.…

Java will be around forever, and becoming an excellent Java developer will absolutely remain highly lucrative for a very long time. That's its reputation at the companies I"ve worked for over the last 10 years (all startups). Go is more of an anti-language imho. Among myself and similarly minded colleagues, I would say its main attraction is its lack of features and it seems a haven for people that are grumpy like me. I always get a chuckle when I see it framed as "hip" because its just never felt like that to me. Elixir is Hip. Rust is somehow Hip. Go, just not in my experience.

Re: The Cult of Kubernetes

#282

Post by 013a »

geggam wrote: post #268
013a wrote: post #195

Earlier quoted context omitted.

https://cluster-api.sigs.k8s.io/

Quick read didnt show Azure or GCP cluster creates. Did I miss that ?

They're not included in the base binary, and are instead provided as plugins. You can find a list of them here [1]; they've got AWS, Azure, GCP, DigitalOcean, vSphere, Docker, OpenStack, maybe a couple others.

[1] https://github.com/kubernetes-sigs?utf8=%E2%9C%93&q=cluster-...

Re: The Cult of Kubernetes

#283

Post by rcarmo »

cameronbrown wrote: post #157
rcarmo wrote: post #150

Earlier quoted context omitted.

Well, maybe it isn't _only_ what it's for, but I have thought of doing largely the same and "bundle" a bunch of assorted projects onto a single 3-node cluster, including my blog. The only thing that's really prevented me from doing so is that I have my own micro-PaaS ( https://github.com/piku ) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really neces…

> The only thing that's really prevented me from doing so is that I have my own micro-PaaS ( https://github.com/piku ) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really necessary. How does it fare in production? I've got a tiny app with two containers (a frontend an a batch job) - it seems like a decent use case.

My website (https://taoofmac.com) is exactly that (web and batch workers) and has been running on it for almost 3 years now, but bear in mind that it does not use containers - it merely deploys relatively isolated services in virtualenvs (or equivalent).

Since I use CloudFlare (hi jgrahamc!), it's been peachy.

Re: The Cult of Kubernetes

#284

Post by rcarmo »

wayoutthere wrote: post #153
rcarmo wrote: post #150

Earlier quoted context omitted.

Well, maybe it isn't _only_ what it's for, but I have thought of doing largely the same and "bundle" a bunch of assorted projects onto a single 3-node cluster, including my blog. The only thing that's really prevented me from doing so is that I have my own micro-PaaS ( https://github.com/piku ) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really neces…

I mean, that’s kind of my point. It’s just not designed for that use case. Someone could build a simplified fork / derivative of Kubernetes designed for this purpose. That would be pretty rad actually, but it would cease to be Kubernetes because the complexity is the point.

k3s.io is great, and I use that as well - is to be what I will eventually run in "production" for my personal stuff.

Re: The Cult of Kubernetes

#285

Post by outside1234 »

tnolet wrote: post #251
root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

Often it is that they think they have never encountered the problem Kubernetes solves or have "gotten lucky" and never encountered it.

Re: The Cult of Kubernetes

#286

Post by hinkley »

gambler wrote: post #151
grenoire wrote: post #137

Earlier quoted context omitted.

Completely valid points, and I agree to all of them. Alas, as other commenters have pointed out, the issue is devs at smaller companies deploying smaller products buying into the idea that they need k8s. I believe that it is the community's duty to educate these devs on what k8s is and when it is needed.

They are probably scared that when they need to change jobs, the next company will require "5 years of Kubernetes experience". So they convince everyone at their current company to jump into a complexity clusterfuck to see how it works "in production" and can put it on their resume. This is how the entire IT industry works today. I am fucking appalled writing config files is a noteworthy skill is 2019. So should you.

I really hate the term "Configuration as code" because it's not code. For most of us, code means something that can be stepped through. For many, that means stepped through in a debugger. Descriptive languages have almost never provided that facility and we don't have it with Kubernetes or Docker Swarm.

Yes it's great to capture your configuration in version control. But if at the end of the day I'm staring at a config file in one window and a log file in another and waiting for enlightenment to grab me, that's not scalable and it's rigid. It also pisses me off to no end.

It's essentially the Frameworks vs Libraries debate all over again. I'd much rather have something imperative.

Declarative systems create a perverse incentive to keep things the way they are because it's difficult to reason about how changes affect the system, and it's virtually impossible to explore those effects. There are no guideposts you can use to apply Local Reasoning, and so there is no pressure to organize this 'code' in a manner that supports it. So as the system matures, everyone is working off of memorization. There are too few bite-sized chunks that can be learned a bit at a time. You are locked into your current way of thinking and you've locked out anyone who can bring fresh perspective.

It doesn't take a genius to see this will end badly. Again. It just takes anyone with enough distance to have perspective.

Re: The Cult of Kubernetes

#287

Post by devoply »

tnolet wrote: post #251
root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

Well how else do you build webscale software? What if later you want to deploy microservices. Premature optimization seems like a good idea with infrastructure because you have room to grow.

Re: The Cult of Kubernetes

#288

Post by dkarl »

tnolet wrote: post #251
root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you

"infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations

Who doesn't want that? Of course you want that.

But will the investment of time and effort pay off for your organization, and if so, how quickly? That's the hard question to answer. It depends on scale, personnel, the types of workloads involved, how easily your tools and practices can be updated, and presumably many other considerations. From my personal experience it seems like in practice the answer to this question is so murky that the deciding factors turn out to be social, including the personal risk aversiveness of the people making the decision, people's loyalty to the company versus their own resume, and whether leadership cultivates a hyperoptimistic growth mentality of making 10x or even 100x decisions (i.e., make decisions assuming the company will be 10x or 100x bigger in a year.)

The problem, then, is helping people compare the cost/benefit of Kubernetes compared to their current practices, for their own organization.

Re: The Cult of Kubernetes

#289

Post by ownagefool »

tnolet wrote: post #251
root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

Lots of people have some the problems k8s solve.

Infrastructure as Code - If you're not doing infrastructure as code, how do you know who is taking what actions on your infrastructure? How do you know your tests are running on an environment that represents production? How do you know the tester or dev hasn't fixed and not commited?

CI/CD - Do you have a quicker way to create test environments than just running kubectl create ns?

Resource Utilisation - Sharing servers to save money. Obviously you can use VMs, but do you want to do nested VMs on cloud?

I'm not sure most people should run k8s, but in a world where you can use GKE, I can't really see why not. What offers a better solution?

Re: The Cult of Kubernetes

#290

Post by hinkley »

peteradio wrote: post #152
grenoire wrote: post #137

Earlier quoted context omitted.

Completely valid points, and I agree to all of them. Alas, as other commenters have pointed out, the issue is devs at smaller companies deploying smaller products buying into the idea that they need k8s. I believe that it is the community's duty to educate these devs on what k8s is and when it is needed.

But they do need k8 ... on their resume.

I wish we were more willing to offer on-the-job training.

But I've worked with too many people who claim to be Senior or Lead developers but can't actually explain what they do.

I've been tempted a lot lately to try to think of a software team like a sports team. Coach, assistant coach, trainers, and physical therapists all about making you think about your abilities at a different, sometimes philosophical level.

The Surgical Unit idea of Brooks has always bugged the hell out of me. I've known enough nurses to know that you don't want to put surgeons in charge of more than one life at a time and then only for a couple of hours, and letting them interact verbally with those people is a fucking disaster half the time. Not unlike some highly decorated software developers I know. They're brilliant as long as they don't actually have to help people.

The head game in software has been overlooked for far too long and to everyone's detriment. Users as well as producers.

If we had the training part right, this FOMO anxiety would be classed as a disorder.

Post reply on HN