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

151–160 of 208 posts

Re: Why Kubernetes Is the New Application Server

#151

Post by dsmithatx »

anothergoogler wrote: post #40
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.

What does "DevOps is dead" mean?

In Devops ops write infrastructure as code. I'm an old school bash perl sysadmin. Devops with Agile is a cultural shift and has transformed the last 4 companies I've worked at. Two of them having ~100,000 employees. We now do ops with 6-10 people for systems that used to require 100+ people to build and maintain.

Re: Why Kubernetes Is the New Application Server

#152

Post by dsmithatx »

markbnj wrote: post #56
yobrobroprogr4m wrote: post #17

At least 50% of the neckbeard kvetching about containers is because they don't want to let go of their lovingly hand-crafted servers and mountains of bash scripts and config management crap that they've built over the past 20 years. edit: btw, I'm one of those (former) neckbeards...

I'm a neckbeard, literally, and it's even gray :). I'm not sure the implied age gap proves out... maybe. I mean there are always early, mainstream and late adopters of a thing. I remember teaching C++ back in the 90's and there was always at least one person in the back of the room who at some point would say "I can do all this with structs and pointers!" or something to that effect. But yeah, ultimately if you get t…

Fellow grey neckbeard here,

I resisted vm's at first.

I seriously resisted the idea of the cloud.

I resisted Devops and Agile.

I looked curiously at containers as possibly not just a fad having used jails for years.

Now I'm managing a large and growing exponentially K8s platform and having a great time.

Resistance is futile.

Re: Why Kubernetes Is the New Application Server

#153

Post by craftyguy »

JetSpiegel wrote: post #130
craftyguy wrote: post #88

Earlier quoted context omitted.

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.

Yea I guess most of my uses have been in things like python (e.g. open() and as.*). Got any examples of code paths that bypass that check and fail if you use /?

Re: Why Kubernetes Is the New Application Server

#154

Post by jacques_chester »

smarterclayton wrote: post #140
taeric wrote: post #124

Earlier quoted context omitted.

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

Agree, virtual hosts are ubiquitous. But I don’t know that anyone loves their virtual machines the same way they love the smaller, faster, and simpler alternatives (unikernels included). This is a somewhat pessimistic viewpoint, but lowest common denominator solutions tend to acquire the most network effects. A VM requires more touch points to manage for the person who has to set up a machine - despite ten years of s…

What's been interesting to watch from the Cloud Foundry POV is the circular migration of the boundary between development and operations.

CF built container technology before Docker or Kubernetes -- two generations of it -- because it was seen as the right primitive by people with experience of Borg. But containers were not touted as ends in themselves.

So the contract boundary given was: sourcecode. Buildpacks.

Docker comes along, then Kubernetes, and the container goes from being a hidden detail to a central concept around which a lot of other stuff orbits. And containers are a step forward on a lot of axes. Developers begin to want to use containers as their shipping unit.

So the contract boundary became: images.

Later ops realises that while opaque running containers are awesome for reducing their management complexity, it doesn't reduce all categories of risk. After all: what's in the damn containers? And so various tools have emerged from the container-oriented ecosystem to take sourcecode and turn it into a container image, so that developers and operators have a consistent handoff point.

So the contract boundary becomes: sourcecode.

It sounds like a nice story, and it might seem like we'll go in circles hereafter. But we're not doomed to do poetic laps: what's happened in the middle has been the rise of CI/CD tools, sitting between the container boundary and the sourecode boundary. Good fences make good neighbours and it turns out that fences made of helpful robots make even better neighbours.

As a Pivot with a long association with Cloud Foundry, I have enjoyed in the past few months getting to compare notes with Red Hatters and others in the k8s community.

Re: Why Kubernetes Is the New Application Server

#155

Post by yjftsjthsd-h »

lainga wrote: post #60
cphoover wrote: post #41

Earlier quoted context omitted.

Yes it makes no sense for developers to understand the underlying systems that run their applications. /sarcasm

Maybe that's true, but it also makes no sense for me to be interrupted every 15 minutes by someone asking me "I need you to restart your $deployment for something I'm doing" while I'm trying to develop.

Surely if they need to ask, they should be able to do it themselves?

Re: Why Kubernetes Is the New Application Server

#157

Post by freeone3000 »

halbritt wrote: post #115
fauigerzigerk wrote: post #111

Earlier quoted context omitted.

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

aka "ops"

The idea that this will kill "devops" is ludicrious, because devops doesn't actually replace job titles. We have a "Devops engineer". He's an ops engineer, with "dev" in front of his title because he codes in perl and python (...like an op). Visual Studio is a "DevOps Environment". I don't know what this means. It likely means that it can provide end-to-end integration in your development environment, which was previously an IDE. The idea behind devops being a raised layer of abstraction is fine, but we don't really need a new word for it, and as history has shown, raised abstractions do not lower. We're going to end up with "devops" until we find a new buzzword.

Re: Why Kubernetes Is the New Application Server

#158

Post by ironjunkie »

I hope that the Kubernetes Steering committee will continue its good work to keep the Core tidy and simple.

What really makes me afraid are the thousands of complex addons that are being pushed by the community (For example, Istio, Networking addons, etc etc). Those should be kept outside and it MUST be made clear they are definitely not needed for a normal installation of Kubernetes.

Istio for example, is such a political brainwash power-move by some bigger companies that benefit from it. I believe less than 5% of the use-cases really require Istio, still it is being pushed as something you should always install in your cluster. This is bad for everyone.

Re: Why Kubernetes Is the New Application Server

#159

Post by mmt »

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…

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

Sadly, I don't think it's actually developers that were pushing for this "freedom" (with which comes responsibility, hence it makes sense that it would be unwanted), as such.

Rather, I place the blame with managers and with (fellow) sysadmins for not embracing, empowering, or forcing (whatever it takes) the aspects of the original DevOps cultural movement to have Ops bring the equivalent [1] of a production environment to every developer.

> Containers provide isolation and immutable infrastructure

I thought they weren't even (necessarily) immutable. If not, then maybe they're merely immutable-through-practice, but that's as unsatisfying as configuration management systems creating reproducible deployments that lack traceability [2].

[1] In terms of tooling for things like builds, deployment, and management (especially of dependencies), not necessarily full hardware capacity, although at one place I did provide each developer with a copy of yesterday's production database on their own, personal bare-metal database server, less "beefy" than the production hardware.

[2] is that the right word? something like chain-of-custody for code and/or configuration.

Re: Why Kubernetes Is the New Application Server

#160

Post by lardo »

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.

I spent two hours scratching my head today because I had put

  "/path/to/thing/**"
in a nuspec file instead of

  "\path\to\thing\**"
The backslash was escaping the wildcard characters :(
Post reply on HN