Why Kubernetes Is the New Application Server

No disagreement here.

There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people.

This has been hashed about at length, but the inverse is also true. Developers must learn to operate their software in production.

(I, like sibling comments, feel that greater restraint in tone and wording, such as avoid "name calling" would amplify, or at least keep the focus on your point, which I believe has at least enough merit to discuss.)

Being in Ops, and having first been paid to do sysadmin work 30 years ago, and having been raised by semiconductor industry veterans, it's pretty safe to say I know tech history.

Having experienced plenty of that history first-hand, including learning to "know better" the hard way, has resulted in a certain amount of conservatism and skepticism toward any new technology, especially one that gains popularity with particular speed.

However, "skepticism" isn't a synonym for "summary dismissal", but, rather, actual skepticism in the sense of asking uncomfortable questions and paying attention to the answers, even they end up being uncomfortable to hear. That's how we grow and, ultimately, know even better.

I've also learned that I enjoy working in smaller companies and/or startup environments far more than the alternative and this has, inevitably, required adapting to some amount of the "move fast and break things" method. Even if its genesis is with leads that can legitimately be labeled as "immature", it merely increases risk, and risk is inherent in startups anyway.

As it applies to my evaluation of new tech, it usually means I get to evaluate it already in operation, instead of merely asking questions. Often, that empirical data is far more valuable, even in forming an argument to stop using that tech.

All that said, so far, I can't help but agree with your assessment of "boondoggle" when all the layers of abstraction, complexity, and cost are included in, languages, ci/cd, virtualization/containers, orchestration, and cloud.

Yes to all. The most difficult thing is persistent volumes, but leveraging things like Heptio's ark allow you to send them to an alternative storage class. It's awesome stuff.

https://github.com/heptio/ark

> There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people.

I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but totally devalued Ops skills in the minds of many tech hiring managers who have exclusively programming backgrounds.

I was on a phone interview today, in fact, lamenting, along with my interviewer, that there exist such sysadmins who don't even write scripts or automation. He suggested that they've started to call themselves "IT", and, IMO, that may well be a more apt term even than "Ops". My own experience is that, back in the dark ages, a traditional sysadmin not only had to be proficient at scripting but also at some amount of C just to port open source tools between various proprietary Unix version, especially with new releases.

That does not, however, bestow upon me, anything that I could call, with a straight face, "development abilities". I hold in my head none of the best practices having to do with programming that have accumulated over the 3 decades of my career, for example. Instead, I hold the Ops best practices. Being able to implement FizzBuzz in bash is neither necessary nor sufficient for software development.

> Developers must learn to operate their software in production.

I disagree here, as well, on behalf of developers.

I think you'll find having to learn what is, essentially, a completely separate, new, engineering discipline, in addition to software development, severely cuts into their productivity.

Unless I bring production to the developers, almost like bringing the upstairs downstairs in the cartoon pushbutton house[1]. I do actually feel it's a responsibility of Ops as part of Devops culture to create as frictionless (for their needs) a simulation of production as possible for developers. The practice has all sorts of benefits, including eliminating "works on my machine" debugging issues, that has been one of the rallying cries for containers.

[1] https://answers.yahoo.com/question/index?qid=20080403063620A...

In my experience, people are using k8s et al and microservices because "everyone is doing it", "nobody got fired for choosing microservices", "I need more cloud stuff on my resume" and a vague (and unsubstantiated, unless you're in SF maybe) hope to hire ops staff on the cheap. Frequently, it ends up in a mix of a partial k8s setup for services plus dedicated DB, logging, backup, and other proprietary persistence infrastructure services. In other words, the union of problems/risks, and the intersection of capabilities; and in particular such that moving to another cloud provider is impossible :)

Cloud services is pretty much a business of huge marketing budgets and old-school lock-in strategies.