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

221–230 of 338 posts

Re: The Cult of Kubernetes

#221

Post by tootie »

dkhenry wrote: post #184
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…

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

This strikes as the exact opposite of reality. Java App Servers were specifically built for vertical scale. You just paid $80,000 to rack 30 CPUs and now you need to a way to optimally utilize all of them so we have a deployment model for sticking multiple applications in a single multi-threaded runtime. That was a pretty decent concept for 2005 and was pretty successful. The concept of packing code into archives (jar/war) has proven to be pretty durable.

Kubernetes is explicitly about managing horizontal scale where the hardware is abstracted away.

Re: The Cult of Kubernetes

#222

Post by asdfman123 »

dragonwriter wrote: post #124
marvin wrote: post #48

Earlier quoted context omitted.

Now imagine how hard it is for executives that don't know anything about technology to aid in making long-term strategic decisions that depends on this!

> Now imagine how hard it is for executives that don't know anything about technology to aid in making long-term strategic decisions that depends on this! Executives that don't know anything about technology shouldn't be aiding in making strategic decisions that depend on this. They might make decisions on the advice of others (including, hopefully, executives who do know something about technology—CEOs may make the…

I don't know what it actually means to be a CTO or CIO, but I think a lot of them have been spending the last 15 years working out strategic visions and reading articles about tech trends.

It's really hard to know this stuff unless you are down in the weeds every day.

Re: The Cult of Kubernetes

#223

Post by Shadowjack »

perfunctory wrote: post #173
goatinaboat wrote: post #32

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. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do…

> “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours” Until somebody cyberattacks those pods and steals all personal data of your users because the devs didn't bother to apply security patches. But hey, it's not your problem. You are not responsible for the pods. k8s is still up.

True. I own all 24 clusters from a management perspective plus own the core OS container they use. I rebuild the OS container, patch, and upgrade the clusters quarterly. I currently have to manually check to make sure they're not using some third party OS container and reject it if they do. I'm working on a PodSecurityPolicy that enforces that so I don't have to manually do it any more. They are fully aware of this because I'm part of their process, attending their scrums and adding lifecycle bits to their Jira backlog. It was initially a shock to them and pushback happened but since I "own" the environments, and could provide good reasons for it, and showed them it didn't adversely impact their workflow, they seem good with it. I can't say they aren't complaining about it among themselves though :)

Re: The Cult of Kubernetes

#224

Post by tootie »

asdfman123 wrote: post #219
humbleMouse wrote: post #178

These posts about kubernetes are so ridiculous. Installing kubernetes on multiple servers is not difficult, and understanding the components is pretty straightforward if you've ever worked on a distributed system. If you don't want to be in the "cult", dont use it. Meanwhile i'll be writing service and deployment yamls and avoiding all the proprietary expensive aws bs.

It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.

The fundamental flaw with Kubernetes is that the UI is so bad. The abstraction is leaky and the naming is confusing. It certainly didn't stop git adoption.

Re: The Cult of Kubernetes

#225

Post by wayoutthere »

meowface wrote: post #205
wayoutthere wrote: post #199

Earlier quoted context omitted.

Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case. Even Google only released K8s because they thought it would push people towards…

The wrapper can still be something self-hosted. There will always be SaaS/PaaS/IaaS abstractions out there for just about everything; even MySQL. The idea would be for someone to be able to very easily self-host something that's as simple to use and configure and interface with as AWS EKS or Google GKE. I have no idea what business case there'd be to open source it. Maybe some open source devs with former experience…

Would you do your day job “just for fun” after you just quit?

The reality is that most of this technology — especially around infrastructure — has become so complex at scale that the tech strategy and the business strategy are the same thing. So infrastructure software has to match your business architecture which is largely dictated to a technology org. Which is why “tech ops” these days is largely just “ops” — the technological complexity is a reaction to increased business sophistication, not the other way around.

Re: The Cult of Kubernetes

#226

Post by aaronbrethorst »

collyw wrote: post #182
cutler wrote: post #114

Earlier quoted context omitted.

Rails with turbolinks or Django/Laravel + pjax is good enough for most purposes. When Kubrrnetes first appeared it was laughable if you used it for anything less than provisioning a massive fleet of servers. Now it's something you sprinkle on your corn flakes.

Yep. We just started implementing it at my place. I had only just started and wanted to say that it seemed like overkill, but it was under way when I started and bringing that up in my first week didn't seem like a good way to start. Top be fair it has reduced our server costs a bit (after maybe 6 months of developer time). I am unconvinced it will be worth the hassle.

FTE dev, fully loaded, is what? $250,000 per year? More?

Are the improvements worth $125,000?

Re: The Cult of Kubernetes

#227

Post by root_axis »

lbotos wrote: post #203
wayoutthere wrote: post #148

Earlier quoted context omitted.

Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.

What is the right use case for K8s? And why is "ease of deployment" not something that someone should expect from K8s? I've been sitting on the K8s sidelines for a bit as things iron out, and I've been deploying it on bare metal on a test bed over the last few days with the intention of using it as IaaS for some of my own apps. It seems to be what it's meant to do. Keep my app running on infra following the rules I s…

The goal isn't "ease of deployment", the goal is "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. With k8s, individual machines become a homogenized resource that do not need specialized provisioning depending on the application they will host.

Re: The Cult of Kubernetes

#228

Post by jacques_chester »

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.

Then you'd be wise to stick stuff like Java or .NET, because there are probably millions of jobs requiring them.

Re: The Cult of Kubernetes

#229

Post by Shadowjack »

madhadron wrote: post #134
dragonwriter wrote: post #119

Earlier quoted context omitted.

> 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.

From a programming perspective, possibly. As an Ops Engineer, I'm having a hard time shifting jobs. Where I work now, it's heavily siloed so I can't shift into a CI/CD team because it's a different team or the Product Engineering team because they don't do Unix administration, automation, or Kubernetes (other than the deployment aspect). I focus on automation with shell scripts and Ansible plus Tower to get Infrastructure as Code going. I took on the Kubernetes role, and am the single point of failure for the 24 clusters I manage. And now management is asking what support contracts we have for Kubernetes (me, it's just me and asking questions in various places on the 'net). Add in that I'm taking courses for the CI/CD toolset and implementing them on my homelab. But I still can't get a bite on shifting jobs.

Re: The Cult of Kubernetes

#230

Post by wayoutthere »

dkhenry wrote: post #184
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…

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

I think you’re getting it backwards here. Kubernetes was explicitly built because the existing solutions were not robust enough to enable containerization at Google’s enterprise clients. Docker existed, and there were plenty of quick and easy ways to deploy your blog from a docker container and get it working. Those still work today.

The “running my blog” use case is a Docker use case. Kubernetes was designed from the ground up to enable transparent integration between containerized apps and ITSM platforms. I have always viewed it as more of a scaled application framework than a hosting platform.

Post reply on HN