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

131–140 of 338 posts

Re: The Cult of Kubernetes

#131

Post by chasd00 »

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've been around enough to see a couple iterations of this. Being able to spot when something is about to fade away and something else come into focus is a valuable skill for consultants. I suppose it's necessary for tech. progress but, man, a lot of money gets spent chasing the new thing.

Re: The Cult of Kubernetes

#132

Post by jmartrican »

xena wrote: post #98
jmartrican wrote: post #85

Earlier quoted context omitted.

Thank you for posting your experience. I am starting on the same path. I am at the point where I got the deployment working and a pod setup. Now I need to be able to access my service from the Internet using a DNS name and SSL certs. Before reading your post I didn't realize how many supporting characters would be needed to do this. It feels daunting and am grateful you posted your scripts and configurations. I'm run…

I'm using DigitalOcean for O(money) optimization reasons. I also wanted as "vanilla" of Kuberenetes as possible while having it be managed. DigitalOcean seems the least bad pick for this. What do you mean? That term is so overloaded it could mean anything.

I got my answer on the service discovery. Its basically done for you by the spec.selector portion of the Service definition, where you tell it which Pods to include in the service.

Re: The Cult of Kubernetes

#133

Post by madhadron »

merb wrote: post #90
tomxor wrote: post #64

Earlier quoted context omitted.

> 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. To balance this with a counter example from the quieter group of people not "hot for the latest tech": I'm a "dev" and i've never had this problem, however I work for a small company, where everything I make and deploy I also have to maintain in some…

well even in a small company you might need: - non downtime deployments (yes you can have a downtime, but everytime you deploy an app?!) - schedule more than one thing (no company has a single product that only has a single binary or at least nearly no company, there are some unicorns tough) - some kind of automation (this is complex, no matter what you use)

> non downtime deployment

Oddly, a lot of small companies really don't need this. If your customers are mostly businesses in a limited set of time zones, having a maintenance window outside of their business hours is probably easier.

Re: The Cult of Kubernetes

#134

Post by madhadron »

dragonwriter wrote: post #119
xena wrote: post #61

Earlier quoted context omitted.

Stagnate by what standard though? There is a certain joy in just maintaining the status quo.

> Stagnate by what standard though? Range of employment options. Possibly salary, though that's more variable. There are some jobs keeping the lights on with legacy tech long after it is done being the hot thing, but typically with any particular stack it's a shrinking numbwrt of jobs often with shrinking average real pay unless it hits a phase where the decline in people able to do it exceeds the decline in work. If…

> Range of employment options. Possibly salary, though that's more variable.

I'm not sure this is true. Most of the shops I've been in don't care about whether you know this or that language or library. You're expected to learn that as you need to. Most of what I've seen cut people from interview loops is missing fundamentals.

Re: The Cult of Kubernetes

#135

Post by mirceal »

step 1) keeping a service up and running is hard. we have all these issues and it seems like we are struggling to do simple things

step 2) only if there was some magic tech that could solve all these issues. and have a cool name. and we could put it on out resumes... drum roll: K8Sssssss

step 3) bro. it’s working. i don’t really understand what it’s doing but look at all the containers we are running. and the config... super configurable. we’re devops we can figure this shit out right?

step 4) what do you mean we have to update the k8s version we’re running on? we barely got this one working. ahh... the beta tools we were using got a bit more polish... makes sense....

step 5) sob silently when you realize that the work k8s has supposedly saved you now goes into maintaining the k8s cluster. reminisce about the good all days when you could just xcopy deploy your app.

epilogue) in the age of the cloud, k8s make zero sense to me. use the abstraction provided by your cloud and focus on writing your crappy app. you’re not google or amazon. you don’t have to solve the problems they do and you’ll probably never have their scale. oh? you have thousands or bare-metal servers and looking for a solution that can help manage them? you can also afford a dedicated ops TEAM to manage them? (dave jumping on the latest tech trend does not count as a team). go ahead!!!

Re: The Cult of Kubernetes

#136

Post by arethuza »

wayoutthere wrote: post #127

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…

Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?

Re: The Cult of Kubernetes

#137

Post by grenoire »

wayoutthere wrote: post #127

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…

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.

Re: The Cult of Kubernetes

#138

Post by madhadron »

lukasLansky wrote: post #29

Kubernetes is our one shot at having the universal vendor-neutral cluster interface. The fact that it's time consuming to do simple things directly against it doesn't surprise me in the same way I'm not surprised that writing todo app directly against POSIX abstraction would be time consuming. It's a great way to learn how these interfaces work though.

> writing todo app directly against POSIX abstraction would be time consuming.

That actually wouldn't be bad, and probably faster than getting it running on Kubernetes.

Re: The Cult of Kubernetes

#139

Post by chasd00 »

xena wrote: post #79
echelon wrote: post #3

Earlier quoted context omitted.

What's the cheapest you can run a k8s cluster in the cloud? I've been looking to spin one up in AWS, but it looks remarkably expensive for running personal projects.

My cluster is at $30 a month, which is slightly more than my dokku server; but I get so much more out of it that I think it's worth it.

I'm not very familiar with kubernetes, what do you get out of it that you don't with dokku? I really like dokku and use it on my personal server for all my half-baked personal projects.

Re: The Cult of Kubernetes

#140

Post by grenoire »

xena wrote: post #104
collyw wrote: post #99

Earlier quoted context omitted.

Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React wi…

The real trick is to make your site load so fast people swear it's magic. I use a combination of serving things from ram and https://instant.page to do this with a fairly boring plain old HTML rendering on the server app. I even have a Progressive Web App out of it too.

Honestly, very true. After doing some brief work for a financial services company, the one thing they were consistently surprised at was how fast the application ran!

Yeah, duh. I render simple HTML templates on the server and serve them as browsers expect them; not with a thousand lines of JS for topping.

Post reply on HN