Live data from Hacker News

Why Kubernetes Is the New Application Server

developers.redhat.com

181–190 of 208 posts

Re: Why Kubernetes Is the New Application Server

#181

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.

There's a lot of benefits to having the same people doing a lot of stuff (see also full-stack devs). It means that someone has an overview of things and have situational awareness.

Without generalists with overview and situational awareness, you're going to need a lot of documentation, paperwork and meetings to preempt communication problems.

Re: Why Kubernetes Is the New Application Server

#182
post #148

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…

I think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either.

The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT.

Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for a decent adult life are very much different from a college life.

Re: Why Kubernetes Is the New Application Server

#183

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.

Infrastructure already is streamlined as hell these days, even bare metal installations. Manual installations from 1996 versus a kickstarted USB installation, iPXE, etc. already feels like things are on pre-school level.

What will very likely not be going away in the next decade is networks.

Unless we can build tooling for setting up the network infrastructure below all these cloud tools, you will still be stuck with people doing admin work like 30 years ago. From personal experience: k8s clusters are easy. Building the hardware and especially networking below so that everything actually can be automated in k8s... whole different story.

Re: Why Kubernetes Is the New Application Server

#184

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

Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?

Re: Why Kubernetes Is the New Application Server

#185
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 think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either. The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT. Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for…

That's as may be for Kubernetes, but the GP specifically stated "that's the case for everything, not only for kubernetes", which struck me as an extraordinarily broad claim.

One might reasonably expect "everything" to include traditional deployment methods that require no changing of mindsets (not that that's likely a factor in my nascent startup example).

Re: Why Kubernetes Is the New Application Server

#186
post #148

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…

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 high quality service from day one because you don't have that much people consuming your services.

Re: Why Kubernetes Is the New Application Server

#187
post #185

Earlier quoted context omitted.

I think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either. The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT. Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for…

That's as may be for Kubernetes, but the GP specifically stated "that's the case for everything, not only for kubernetes", which struck me as an extraordinarily broad claim. One might reasonably expect "everything" to include traditional deployment methods that require no changing of mindsets (not that that's likely a factor in my nascent startup example).

Transition phases actually make sense even if you apply "everything" instead of just "Kubernetes" considering how every company transitions through stages in terms of tooling.

Think being a startup where deployments most likely will be manual and undocumented, upgrading to an initial automation using some scripting, transitioning to CI/CD, etc.

So from various experiences at companies of all sizes I would actually support such a broad claim, since companies are basically transitioning all the time through new phases to greener pastures. That of course assumes that the company values constant improvements and uses an iterative process for growth and change.

Re: Why Kubernetes Is the New Application Server

#188
post #14

Earlier quoted context omitted.

Although it's a bad point without any concrete examples. Without that, it just seems like a baseless emotional reaction to not liking something new. I might even be inclined to agree if there was a bit more detail given.

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.

Re: Why Kubernetes Is the New Application Server

#189
post #172

Guys who have worked with Kubernetes and virtualization, I have a genuine personal question for you - I have been working as SysAdmin and then into virtualization (VMware / HyperV sort of things) and while natural progression in it says go for advanced VMware courses (related to Virtual machine and its concepts), do you think its better to switch lanes now to container-tech rather than some years down the line? I am…

At this point it is clear that this is a thing that will happen for a whole lot of orgs. You would be well advised to dabble at this point and see if it connects with you. At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation. That said, VMs and scripted/config-managed deployment will continue to be with us for the foreseeable future.

"At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation"

Seriously, this is so embarrassing at the current point ( with me having absolutely 0 understanding of the concept)

Re: Why Kubernetes Is the New Application Server

#190
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.

Legacy? They are exploding with new stuff weekly, and growing like crazy.

There is a much bigger market for infrastructure in the cloud than people realize, and I will be very surprised if kubernetes is not replaced in 5 years.

Post reply on HN