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

111–120 of 208 posts

Re: Why Kubernetes Is the New Application Server

#111

Post by fauigerzigerk »

parasubvert wrote: post #84
fauigerzigerk wrote: post #38

Here's my prediction: DevOps is dead. In 5 to 10 years developers will no longer be mentioned in articles like this. There will be specialisation once again, because it makes absolutely no sense to make people whose main job it is to think about use cases, business logic and user interfaces to also deal with stuff like this.

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) But more broadly, Kubernetes in the hands of most developers that are doing non-platform level work is a step backwards and will be disastrous. It's far too low level, it's like, hey this Python…

>Your broader point is correct but I think you're mischaracterizing Devops

You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.

Re: Why Kubernetes Is the New Application Server

#112

Post by mehblahwhatevs »

gog wrote: post #106
amdelamar wrote: post #62

As mentioned in the article, The EFK stack (Elasticsearch, Fluentd, Kibana) is great for unified logging. And its not just for OpenShift, its working wonders for our current project with Kubernetes on AWS.

Could you give more details about why Fluentd and not Beats + Logstash on the other end? I don't like the idea of running Ruby on every machine just to ship logs somewhere. Beats are pretty lightweight and for what I used them they work.

Many people use the ELK stack which is Logstash. I imagine you can swap out Fluentd for Logstash.

Re: Why Kubernetes Is the New Application Server

#113

Post by halbritt »

threeseed wrote: post #94
dkhenry wrote: post #30

I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army…

I can spin up a Kubernetes cluster in seconds using AWS, Azure or GCP. And with helm installing new applications is a pretty trivial affair. I am not disagreeing that it’s complex and a lot of buzzwords but every day the situation is getting better and better.

Easy peasy.

Now try troubleshooting it.

Re: Why Kubernetes Is the New Application Server

#114

Post by halbritt »

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…

Infrastructure as software vs infrastructure as code.

Re: Why Kubernetes Is the New Application Server

#115

Post by halbritt »

fauigerzigerk wrote: post #111
parasubvert wrote: post #84

Earlier quoted context omitted.

Your broader point is correct but I think you're mischaracterizing Devops (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations) But more broadly, Kubernetes in the hands of most developers that are doing non-platform level work is a step backwards and will be disastrous. It's far too low level, it's like, hey this Python…

>Your broader point is correct but I think you're mischaracterizing Devops You are right. What I should have said is that using DevOps as an excuse to make application developers do complex infrastructure design, automation and maintainance as a side-job is an unsustainable practice.

Indeed. That's why Google has SRE and Facebook has Production Engineering, and so on.

Re: Why Kubernetes Is the New Application Server

#116

Post by smarterclayton »

parasubvert wrote: post #90
dnomad wrote: post #35

Earlier quoted context omitted.

The entire exercise is about expressing dependencies. (The real third hard problem in computer science. Only idiots fall for off-by-1 errors.) Containers are one way to force an application to explicitly declare all of its dependencies. The problem is the application then also bundles those dependencies. There's not much room for control or intermediation. Developers have total freedom to do all sorts of wackiness. (…

> There's not much room for control or intermediation. FWIW there are container-based app platforms that do allow you to swap out filesystem layers to update dependencies and to remove control from developers by having a standardized containerizer that has extension hooks but can't be mucked with at the lowest levels. This is how Cloud Foundry works for example, or Heroku.

For example, OpenShift (Kubernetes + stuff also from Red Hat) exposes this pattern like both heroku and cloud foundry by

A) focusing on having standard base images controlled by ops

B) encouraging combining source code / built artifacts as a layer on those base images

C) giving controls to ops so that the only images users could build or run must be built with A/B above.

In that mode containers are less wasteful because you can share the base image across every host (or rebuild everything centrally), and all that gets downloaded to a host is the source code top layer. Which is roughly indistinguishable from the lambda runtime and how it accesses the code to execute.

Re: Why Kubernetes Is the New Application Server

#118

Post by dkhenry »

brozaman wrote: post #110
dkhenry wrote: post #30

I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army…

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…

This is the same process that was done with J2EE and Application Servers, it starts out with a _simple_ standard to have a Java application served with a standard API, and then it grows out of control. You are already seeing it with Itsio and Helm being layered on top. Today you might be able to get the stock Kubernetes up without much assistance, but give it a few years as "features" get added on.

Re: Why Kubernetes Is the New Application Server

#119

Post by gcoda »

solomatov wrote: post #93
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).

IMO, serverless in the future will be just a kind of resource on k8. k8 is not serverless, k8 is a open source AWS.

Why wait for future? You can deploy openfaas on kubernetes, i belive there is more serverless projects you can deploy on k8s cluster

Re: Why Kubernetes Is the New Application Server

#120

Post by zeckalpha »

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…

That’s not a benefit to me. Is it reproducible? Keeping desired state under version control is valuable.
Post reply on HN