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

71–80 of 208 posts

Re: Why Kubernetes Is the New Application Server

#71

Post by taeric »

tyldum wrote: post #29
dnomad wrote: post #19

Earlier quoted context omitted.

Exactly. Docker files are worse than war files in pretty much every way. The economics are interesting though. Computing resources are super cheap and getting more cheap everyday. (Well except for RAM!) The waste produced by containers means says, yeah, give each application its own app server. Its own web server, its own JDBC driver, even its own JDK. We'll throw it all on the cloud and run it for a few cents each h…

We use containers to reduce the testing surface and enforce standards. And if course to ease testing as we now transition the same build through dev, staging and prod. The devs just have a single base container to work off from and we use CICD to further enforce whatever we need to. It also makes it easier for devs to propose changes, as we know we can consistently apply them.

A problem comes down to answering questions such as "exactly what versions of X are installed in our beta stack?" Usually trivial if X is part of your application. Much more complicated if X is some lib that is on the system/image.

Re: Why Kubernetes Is the New Application Server

#72

Post by some_account »

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

Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

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

Re: Why Kubernetes Is the New Application Server

#73

Post by pishpash »

zapt02 wrote: post #70
solomatov wrote: post #66

Earlier quoted context omitted.

Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

Have you used the AWS interface lately? It's getting further and further away from being streamlined.

AWS is legacy. That's why Kubernetes has uptake. They are in danger of becoming a rack provider if this continues. Their managed applications still have a place, but with third parties, they might become a glorified cloud app store, which they might desire anyway.

Re: Why Kubernetes Is the New Application Server

#74

Post by taeric »

colechristensen wrote: post #34
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…

Very similar abstractions are being created over and over, if you are too close it is hard to see that the abstractions are largely the same, and the grand benefits being toted are actually quite small when comparing one to the other and the differences are just attitudes and a tiny bit of tooling that could be recreated for any of the abstractions.

It does get frustrating to lose tooling you previously had. Even more frustrating when some of the instrumentation that you take for granted in the old world is "TBD" in the new one.

Re: Why Kubernetes Is the New Application Server

#75

Post by SteveNuts »

hodgesrm wrote: post #63
humbleMouse wrote: post #52

Earlier quoted context omitted.

What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s). So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.

What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like? There's a lot more to replicate than just the bits in the apps.

Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.

Re: Why Kubernetes Is the New Application Server

#76

Post by fauigerzigerk »

dorian-graph wrote: post #61
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.

This is how we ended up with Electron apps.

No, that's unfair. User interfaces have always been and will always be a key responsibiliy of developers.

Writing native UI code is no more low level than using electron. It's just less familiar to web developers and less portable. These are completely different considerations than the greater degree of division of labour I'm predicting for the server side.

Re: Why Kubernetes Is the New Application Server

#77

Post by grapeli23 »

xj9 wrote: post #48
grapeli23 wrote: post #26

Earlier quoted context omitted.

You probably never heard or used - Linux VServer. Available from the later version of the 2.4 kernel. https://en.wikipedia.org/wiki/Linux-VServer

> 2008 FreeBSD jails date from 2000 Solaris zones date from 2004 https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr... https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr...

2003 http://linux-vserver.org/Overview#History

In the Linux distribution that I used (PLD), the first vserver support took place in january 2004. https://github.com/pld-linux/kernel/commit/5be58c1bcc5568676...

Maybe a little earlier because the util-vserver showed in Nov 2003. https://github.com/pld-linux/util-vserver/commit/c4036d6e748...

Re: Why Kubernetes Is the New Application Server

#78

Post by zapt02 »

pishpash wrote: post #73
zapt02 wrote: post #70

Earlier quoted context omitted.

Have you used the AWS interface lately? It's getting further and further away from being streamlined.

AWS is legacy. That's why Kubernetes has uptake. They are in danger of becoming a rack provider if this continues. Their managed applications still have a place, but with third parties, they might become a glorified cloud app store, which they might desire anyway.

I haven't worked with Kubernetes but I have worked a lot with Docker. Building your containers is difficult, using existing containers has a bunch of gotchas and getting your containers up and running anywhere resembling a production environment is a giant hassle.

I think containers is the future but we need idiot-proof GUI systems that Heroku and similar services provide to wire up our applications, and we need a good way to handle persistence, which many modern tools ignore.

Re: Why Kubernetes Is the New Application Server

#79

Post by jerf »

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

Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

"I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise."

As someone trying to be primarily a dev who keeps getting roped into doing ops stuff for deploying my stuff, my experience is the exact opposite, and in particular putting Kubernetes on the end as the least complicated technology seems outright crazy to me, like, seriously, what on Earth are you talking about? You literally can't bring up a hello world web app without basically knowing everything you needed to know to bring it up on bare metal, and everything you needed to know to bring it up on a VM (whose crazy virtual networking stuff now seems like simplicity itself compared to Docker/Kubernetes), and everything you need to know to bring it up in Docker, and everything you need to know to bring it up in Kubernetes... and you need some sort of solution around building Docker images, too, so you're still going to need to know that, too.

There's all kinds of reasons this is necessary and there's all kinds of reasons why provising a new hardware server, blasting a Linux distro on to it, and just running your server is a bad idea. By no means am I proposing we need to go back to some glorious past, where losing a single hard drive sector means "oh well, guess the database is gone! recovery plan? Our recovery plan is to not need the database anymore!" I'm just saying, it's crazy to think this is all getting simpler. Try looking at this through the eyes of a fresh grad sometime.

Granted, I'm a bit crabby that literally every time I go to deploy something new, on a roughly 18 month time frame (the intervening time being maintenance and feature development), I have to go learn something else for my one-off task. (I don't think devops manages to beat the Node/JS world for churn, but it's probably in second place.) But still, it's getting more and more complicated, not less, and I don't even sense that we've passed an inflection point on the complexity reducing yet.

Re: Why Kubernetes Is the New Application Server

#80

Post by bamboozled »

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

Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

We’ve had Heroku for almost over ten years now...
Post reply on HN