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

81–90 of 208 posts

Re: Why Kubernetes Is the New Application Server

#81

Post by parasubvert »

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.

This reminds me of the OpenStack Hubris, wherein they would dictate requirements to AWS due to the sheer momentum of the community. Uh, nope.

Kubernetes' uptake is nowhere close to AWS by any measure. And AWS is the #1 public cloud that hosts Kubernetes workloads.

It's every IT vendor in the world vs. AWS, and so far, they're winning. Kubernetes and open platforms have a shot, but they're not moving fast enough yet in the direction that matters - up the stack.

Re: Why Kubernetes Is the New Application Server

#82

Post by humbleMouse »

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.

Well, that depends where those resources are running and also depends if you're leveraging persistent storage in k8's. All the routes/firewall/dns etc. will be preserved in the event a data center is nuked. Like I said, k8's is replicating your entire system behind the scenes.

Re: Why Kubernetes Is the New Application Server

#83

Post by parasubvert »

josteink wrote: post #54
optimuspaul wrote: post #50

Earlier quoted context omitted.

wait, is that what devops means to you? That devs are doing ops?

That is the predominant definition, so yes I would assume just that. It’s more or less a logical following of infrastructure as code, because it’s the developers who write and push those files.

If that's the predominant definition, then pretty much everyone that coined the term, written books about it, or run devopsdays events has failed, and we might as well pack up the use of the term. Because not one of them would agree with this.

Devops is/was a professional movement to get developers and operations folks to communicate with one another, create a shared value system and culture, drive continuous learning, enhance automation, visibility/metrics, so we can all build software faster safely and sustainably.

Infrastructure as code was one small aspect of this. Continuous delivery, microservices, cloud native platforms, a sharing/collaborative culture, lean product development, modern alerting/monitoring, all were part of this.

But it seems tech pop culture cliche's win out over best intentions again and again, as they did with 'agile', 'cloud', 'structured programming', 'object oriented programming', 'reactive', and 'REST'

Re: Why Kubernetes Is the New Application Server

#84

Post by parasubvert »

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/Ruby/Java thing was great, but have you seen this new bytecode linker and assembler?

New platforms and runtime built ON TOP OF Kubernetes are probably going to be fine. But that's going to take a while.

Re: Why Kubernetes Is the New Application Server

#85

Post by chris_mc »

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 (which isn't about developers doing this stuff, it's about a continuously improving culture + technology to support end-to-end delivery and operations)

Everyone who comments about DevOps should have read "The Phoenix Project" first, so that they understand what you just said. It's not about consolidating workloads onto generalists, it's supposed to be about breaking down the silos in an organization, nothing more!

Re: Why Kubernetes Is the New Application Server

#86

Post by oblio »

dkarl wrote: post #67
optimuspaul wrote: post #50

Earlier quoted context omitted.

wait, is that what devops means to you? That devs are doing ops?

"Devops does not mean devs doing ops" is like "story points are not time estimates." It gets repeated so often because it's such an easy mistake to fall into.

Just like communism, if in real life 99% of practitioners are doing it wrong, maybe we should revise the theory? Some dreams have a strong attraction, but they’re just like the mermaids of old.

Re: Why Kubernetes Is the New Application Server

#87

Post by bamboozled »

some_account wrote: post #72
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.

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.

Re: Why Kubernetes Is the New Application Server

#88

Post by craftyguy »

testvox wrote: post #3

Sorry but this article implies that containers can solve issues like the difference between path separators on Windows and Linux. They can't even solve issues arising from differences in kernal versions, not to mention operating systems.

Always use /

Windows can, surprisingly, handle it just fine.

Re: Why Kubernetes Is the New Application Server

#89

Post by parasubvert »

dnomad wrote: post #19
taeric wrote: post #4

It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around. My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That igno…

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…

> Exactly. Docker files are worse than war files in pretty much every way.

They focus at far too low level a problem.

> The problem is that testing isn't cheap. This is where microservices and containers and the all this craziness will fall down. Now you've got dozens and dozens of applications all running with their own application servers, JDBC drivers, and their own JDK. This is a combinatoric explosion in your testing surface.

I fail to see how this more difficult from 95% of existing enterprise systems that run various JDK versions, various WebSphere versions, JDBC drivers etc.

The difference with containers is that vendoring your dependencies makes all that explicit. Whether you choose to stay on old versions is a mistake you can still make (and will make if you leave container creation and patching in the hands of dev teams).

That said, since when does any organization build horizontal testing libraries, like, "test X version of JDBC", so they can standardize on a single driver across all projects? It's never done. Projects are all over the place with their dependencies unless there is institutionalized forcing through Maven repos or what not to block the download of old/insecure versions.

There is no combinatorial problem here, each test suite needs to unit test the individual service and then test the API contract of the service. If you let your dependencies decay you're accepting major security and maintenance risk, but you were in the WAR file world too.

> The true value of the application server approach is that it forced applications to conform to a clear contract. Once your application conformed to this contract it could be thrown over the wall into a full-time ops organization that could transparently deploy, monitor and manage the app.

LOL, I really think you're exaggerating. I've worked with WebLogic, WebSphere, IIS, JBoss, Tomcat, Django, Rails, Node, you name it over the years, and while some orgs got close in the Java world, this was mostly a pipe dream that never happened in any cost effective manner as a standard practice.

> The container madness will come to an end. People will realize that giving developers the keys to the kingdom and total freedom over their application is a terrible idea. (And smart developers don't want total freedom.)

This I agree with. It's all far too low level.

This really was Docker, Inc.'s fault IMO, their marketing message was to empower developers to get ops out of the way by building these containers that would magically just be run as opaque lego blocks. That was the hype everyone on HN was drooling over in 2013. Turns out it's not quite that simple.

Re: Why Kubernetes Is the New Application Server

#90

Post by parasubvert »

dnomad wrote: post #35
kinghajj wrote: post #23

Earlier quoted context omitted.

Nothing prevents one from having a container with many WAR files, so that there's only a single JVM for multiple applications.

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.

Post reply on HN