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

Why Kubernetes Is the New Application Server

developers.redhat.com

Post reply on HN
Print view View original

191–200 of 208 posts

Re: Why Kubernetes Is the New Application Server

#191

Post by blackadder »

rdsubhas wrote: post #98

I feel a bit alone here. The most obvious benefit of kubernetes is that It's an API . There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API. Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and…

Bingo, you've hit the nail :) This is what I love about K8S. In addition you've got the K8S reconciliation loop running constantly to make sure the system is in the state you described via the API.

Re: Why Kubernetes Is the New Application Server

#192

Post by [deleted] »

mmt wrote: post #148
brozaman wrote: post #110

Earlier quoted context omitted.

I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "won't work at all without an army of consultants". While it's true that some of our customers have an army of consultants, the vast majority of our customers don't use consulting at all or that only use it very infrequently. If you don't want a lot of customiz…

> want to get in production after 2 months [...] > it will give lot of problems. But that's the case for everything, not only for kubernetes Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project? If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it does…

[deleted]

Re: Why Kubernetes Is the New Application Server

#193

Post by testvox »

craftyguy wrote: post #153
JetSpiegel wrote: post #130

Earlier quoted context omitted.

On interactive uses, sure. But it's not clear cut, some code paths are lower level and bypass that.

Yea I guess most of my uses have been in things like python (e.g. open() and as.*). Got any examples of code paths that bypass that check and fail if you use /?

I think they are wrong and actually it's the opposite problem. Some applications and libraries that do their own path mangling on Windows will choke if you give them a /. The win32 file I/O API handles them correctly.

Re: Why Kubernetes Is the New Application Server

#194

Post by toomuchtodo »

jrs95 wrote: post #188
toomuchtodo wrote: post #15

Earlier quoted context omitted.

Containers are a solution looking for a problem, used more for organizational reasons than technical. Disclaimer: Infra/DevOps engineer previously, 20 years total in tech

I hear things like this a lot but I never hear how you could accomplish the same things as Kubernetes (or any other orchestrator) without containers. Even if there were good solutions available for this, and the only advantage of containers was an organizational advantage rather than a technical one, I think that would still be a win.

The same way we orchestrated before containers: VMs, config management, and APIs at the control plane

Re: Why Kubernetes Is the New Application Server

#195

Post by humbleMouse »

newcrobuzon wrote: post #173
humbleMouse wrote: post #47

I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company. It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it.…

Isn't that problem solved equally with VMs?

No, not unless you replicated the VMs accross different data centers manually. Which actually isn't that difficult using docker.

Re: Why Kubernetes Is the New Application Server

#196

Post by halbritt »

mmt wrote: post #168
halbritt wrote: post #162

Earlier quoted context omitted.

No disagreement here. There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. This has been hashed about at length, but the inverse is also true. Developers must learn to operate their software in production.

> There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but t…

Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR.

As someone doing the hiring for such things, people looking to get hired seem to have a different view of things. I don't need someone with an advanced degree in CS and mastery of algorithms to produce API endpoints and orchestration bits.

As for having software developers handing off their software for someone else to operate, well, that's an anti-pattern that inhibits throughput and software quality. There's quite a bit of data around this topic. I would encourage you to read this book:

https://itrevolution.com/book/accelerate/

I'll grant you that it's difficult to get there in a traditional IT org, but once you do get there, the results are glorious.

Re: Why Kubernetes Is the New Application Server

#197

Post by mmt »

halbritt wrote: post #196
mmt wrote: post #168

Earlier quoted context omitted.

> There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people. I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but t…

Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR. As someone doing the hiring for such things, people looking to get hired seem to have a different view of things. I don't need someone with an advanced degree in CS and mastery of algorithms to produce API endpoints and orchestration bits. As for having softwa…

> Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR.

No dissonance from my end, and I'd say that other than the very narrow overlap of being able to "write code", that's quite distinct from what, for example, my Ops skills are.

To be fair, I did think of some other potential relatively narrow overlaps, such as revision control systems, strace/dtrace, and debuggers, but the latter is a bit tenuous, since it's a niche/vintage skill. Even with VCSes, I don't need, know, or use most features (and miss features like "svn export").

> As for having software developers handing off their software for someone else to operate, well, that's an anti-pattern that inhibits throughput and software quality.

You may be implying a false dichotomy (or maybe I'm reading one in that you didn't intend). I don't think anyone, myself included, is advocating in favor of the "throw it over the wall" anti-pattern that the original Devops cultural movement advocated so vehemently against.

I absolutely agree that developers should remain responsible for the operation of their software in production and, to whatever extent necessary, be involved in that operation. I'm also saying that if "whatever extent necessary" isn't remarkably minimal, it indicates something seriously wrong with the software, with the production-like development environment Ops is providing (i.e. implementation of Devops culture), or both.

Re: Why Kubernetes Is the New Application Server

#198

Post by mmt »

brozaman wrote: post #186
mmt wrote: post #148

Earlier quoted context omitted.

> want to get in production after 2 months [...] > it will give lot of problems. But that's the case for everything, not only for kubernetes Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project? If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it does…

I should have worded that differently. I meant migrating an existing production. If you have an existing production which works well after years of improvement and stabilization, with people with a lot of expertise on it, you won't get that in 2 months, not the stability and quality nor the ability to troubleshoot it. Startups start from scratch, don't have big workloads, also there isn't so much pressure to have a h…

Thanks. Where "everything" is in the context of a transition or migration, rather than any kind of deployment, including an initial one, 2 months seems like a very reasonable minimum.

It's certainly in line with technical new hire productivity "ramp up" time estimates (typically 3 months?), which I would guess are a similar (if individual) case of change-of-mindset.

Re: Why Kubernetes Is the New Application Server

#199

Post by rhlsthrm »

bamboozled wrote: post #87
some_account wrote: post #72

Earlier quoted context omitted.

No, the future is serverless applications in the major cloud providers where every server is abstracted away and things scale automatically. The reason for this is the enormous cost benefits (its super cheap, you only pay when your code actually runs, no upfront costs, no passive server costs, no overprovision or underprovision of compute resources etc).

If you’ve ever used a serverless framework, you’ll know this argument falls apart the second you need to run something for a long period of time, manage complex state or glue services together. There are numerous other details being glossed over. The servless approach has its place just like everything else, it’s not a panacea though.

Eventually, it should be abstracted even further into something that looks like Heroku, but deploys your code onto serverless functions or containers depending on how your service needs to run. A nice, modular, microservice backend automatically with zero config.

Re: Why Kubernetes Is the New Application Server

#200

Post by rhlsthrm »

protomyth wrote: post #142
markbnj wrote: post #53

Earlier quoted context omitted.

It's more like experienced devs doing ops in support of devs. As with most terms like this ymmv.

From some of the folks I was talking to, it seemed more like companies firing their SysAdmins, Release Management, and DBAs and making the developers do the production operations / support.

Yep, I think it means you can hire one "DevOps Engineer" to do the work of multiple sysadmins/dbas by using these cloud-based services.
Post reply on HN