Why Kubernetes Is the New Application Server • Hacker News Board

Re: Why Kubernetes Is the New Application Server

#121

Post by zeckalpha » Thu, Jul 12, 2018, 10:55 PM UTC

chris_mc wrote: post #85

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 (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 suppos…

Which they barely did in Phoenix Project toward the end. The first part was building silos to slow the input and reduce work in progress.

Re: Why Kubernetes Is the New Application Server

#122

Post by taeric » Thu, Jul 12, 2018, 11:10 PM UTC

threeseed wrote: post #97

taeric wrote: post #74

Earlier quoted context omitted.

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.

Instrumentation on Kubernetes is pretty incredible albeit complex. You have host, container, application and ingress level metrics. But via the mesh networking eg LinkerD detailed metrics of how containers are talking to each other. All of which roll into a single metrics server (Prometheus) and dashboard (Grafana).

Most of the instrumentation I have found myself losing have been at the application levels. And to be clear, most of them are still somewhere, but not nearly as well polished as in services we have not on containers. (I'm also primarily talking about a bunch of internal practices at my current job.)

Re: Why Kubernetes Is the New Application Server

#123

Post by taeric » Thu, Jul 12, 2018, 11:15 PM UTC

cpuguy83 wrote: post #101

taeric wrote: post #22

Earlier quoted context omitted.

The problem is when there is a vulnerability in some part of an earlier layer. You have to rebuild the entire stack. I honestly don't think this is necessarily a terrible thing. But, the idea that your common layers are stable is a dangerously bad assumption.

What are you defining as stable? Never changing? That's not something that should even hinted at. The fact that you can login to a VM and update a package does not make the system stable either (and of course you can actually do this with running containers as well). Add to that you still need to restart running applications to take advantage of the package update (assuming the packages is a shared lib). Meanwhile yo…

I suspect we mostly agree with each other. My experience with folks in containers so far has proven to be that this is often hoped, though.

Specifically, we had devs talking about how we wouldn't have to worry about system patching anymore, because the containers would take care of that. With no answer for how we trace versions and patches through our systems.

If you are already tooled enough such that you can completely redeploy a full stack easily without worrying about some in place modifications, the difference between a VM and a container are relatively minimal, all told. Especially since you have to be ready to pull down the host of the containers anyway.

Re: Why Kubernetes Is the New Application Server

#124

Post by taeric » Thu, Jul 12, 2018, 11:18 PM UTC

smarterclayton wrote: post #116

parasubvert wrote: post #90

Earlier quoted context omitted.

> 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 beca…

Don't most virtualized hosts already solve the "less wasteful" point? I get that hypervisors and friends aren't bulletproof, either; but I have fewer ways to shoot yourself with those than I have with containers.

More, you have to worry about the container host anyway, so you haven't removed the need to maintain a host. You've just added to it the need to maintain the rest of the container infrastructure as well as your application stuff.

For places that have not solved the "virtual hosts should be virtually free" problem, containers are quite welcome. You can get going with them quite quickly. If you have already solved that problem, they can look an awful lot like just more work.

Re: Why Kubernetes Is the New Application Server

#125

Post by solomatov » Thu, Jul 12, 2018, 11:18 PM UTC

gcoda wrote: post #119

solomatov wrote: post #93

Earlier quoted context omitted.

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

I think serverless will be included in the k8 or competing product replacing it out of the box.

Re: Why Kubernetes Is the New Application Server

#126

Post by taeric » Thu, Jul 12, 2018, 11:19 PM UTC

redbeard0x0a wrote: post #100

taeric wrote: post #8

Earlier quoted context omitted.

Be fair here. The software world is slowly recreating technology. Being even more fair, they do often add to it. Usually UX capabilities, but sometimes full on features. Yes, often the features require more resources than were available before. Such that previous versions couldn't have offered some of these things. That said, it is not limited to any one set of our industry. It is likely not even limited to our indus…

Software getting recreated, sometimes without the security promises (linux containers as they started vs. solaris zones) the previous solution had. To be fair, Google didn't really need the security in linux containers, they didn't run multi-tenant workloads, so it wasn't their top concern when submitting code to the linux kernel... We like building new things, from different angles, but in the end it seems like ever…

Completely agreed. It is hilarious because we all preach "don't reinvent the wheel" at the same time that our interviews are basically "can you implement this ridiculously low level wheel" on top of "come here where we are simply using the latest rims!" :)

Re: Why Kubernetes Is the New Application Server

#127

Post by cpuguy83 » Thu, Jul 12, 2018, 11:20 PM UTC

taeric wrote: post #123

cpuguy83 wrote: post #101

Earlier quoted context omitted.

What are you defining as stable? Never changing? That's not something that should even hinted at. The fact that you can login to a VM and update a package does not make the system stable either (and of course you can actually do this with running containers as well). Add to that you still need to restart running applications to take advantage of the package update (assuming the packages is a shared lib). Meanwhile yo…

I suspect we mostly agree with each other. My experience with folks in containers so far has proven to be that this is often hoped, though. Specifically, we had devs talking about how we wouldn't have to worry about system patching anymore, because the containers would take care of that. With no answer for how we trace versions and patches through our systems. If you are already tooled enough such that you can comple…

The main difference is the container is focused on an application and a VM is focused on a machine.

Generally the patching problem can be solved with image scanning, of which there are tools out there to deal with this, both FLOSS and pay for.

Re: Why Kubernetes Is the New Application Server

#128

Post by taeric » Thu, Jul 12, 2018, 11:25 PM UTC

sewercake wrote: post #16

We're in the process of migrating our (primarily) java services from straight AWS to kubernetes. At the beginning the author poses the following questions: * Do you use Mac, Windows, or Linux? Have you ever faced an issue related to \ versus / as the file path separator? What version of JDK do you use? Do you use Java 10 in development, but production uses JRE 8? Have you faced any bugs introduced by JVM differences?…

Honestly, most of the introduction I've seen has been bottom up or from new hires. I think there is a major point in having happy development environments. Happiness with tools is a very important point that is hard to quantify. https://www.johndcook.com/blog/2011/07/31/enjoyment-of-ones-... has a fun exploration of two great quotes on this vein.

That said, if you can, I'd be ridiculously interested in a retrospective when you have a chance on your transition. Good luck with it!

Re: Why Kubernetes Is the New Application Server

#129

Post by dsmithatx » Thu, Jul 12, 2018, 11:27 PM UTC

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 helping build an Openshift platform with 2-3 redhat consultants. I do not work for Redhat, I'm a Linux/Devops admin. It's been very simple to install and fully automate everything. It also is allowing developers to focus on writing code and not infrastructure as AWS does. Most of it is bare metal for now, but we will be able to spin up AWS and Azure in a few hours with the same code.

The instructions are accurate, it's been easy to learn, and does not require an army of consultants. We will be moving 1000's of apps to multiple data centers globally with a team of around 6 people. It took 100s of employees years to build and maintain infrastructure for those apps.

Note - Consultants are not needed at all, they simply help speed up the process with expert knowledge.

Re: Why Kubernetes Is the New Application Server

#130

Post by JetSpiegel » Thu, Jul 12, 2018, 11:28 PM UTC

craftyguy wrote: post #88

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.

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