[fauigerzigerk]

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.

[barrkel]

K8s establishes a pattern for implementing many ops tasks as controllers rather than scripts or configs. The level of abstraction will be raised, and more and more of the custom hacks specific to individual companies will become modules you deploy on your cluster.

In this way, devs will be doing ops, but not as ops for any given prod environment, rather encoding operational tasks in reusable software.

Ops themselves will bifurcate, one towards configuring prebuilt controllers, others towards troubleshooting problems in production. The middle ground will hollow out.

[parasubvert]

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.

[chris_mc]

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

[zeckalpha]

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.

[fauigerzigerk]

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

[halbritt]

Indeed. That's why Google has SRE and Facebook has Production Engineering, and so on.

[freeone3000]

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.

[halbritt]

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.

[mmt]

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

[twblalock]

I've only seen devs doing that stuff at very small startups.

[solomatov]

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.

[jerf]

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

As someone trying to be primarily a dev who keeps getting roped into doing ops stuff for deploying my stuff, my experience is the exact opposite, and in particular putting Kubernetes on the end as the least complicated technology seems outright crazy to me, like, seriously, what on Earth are you talking about? You literally can't bring up a hello world web app without basically knowing everything you needed to know to bring it up on bare metal, and everything you needed to know to bring it up on a VM (whose crazy virtual networking stuff now seems like simplicity itself compared to Docker/Kubernetes), and everything you need to know to bring it up in Docker, and everything you need to know to bring it up in Kubernetes... and you need some sort of solution around building Docker images, too, so you're still going to need to know that, too.

There's all kinds of reasons this is necessary and there's all kinds of reasons why provising a new hardware server, blasting a Linux distro on to it, and just running your server is a bad idea. By no means am I proposing we need to go back to some glorious past, where losing a single hard drive sector means "oh well, guess the database is gone! recovery plan? Our recovery plan is to not need the database anymore!" I'm just saying, it's crazy to think this is all getting simpler. Try looking at this through the eyes of a fresh grad sometime.

Granted, I'm a bit crabby that literally every time I go to deploy something new, on a roughly 18 month time frame (the intervening time being maintenance and feature development), I have to go learn something else for my one-off task. (I don't think devops manages to beat the Node/JS world for churn, but it's probably in second place.) But still, it's getting more and more complicated, not less, and I don't even sense that we've passed an inflection point on the complexity reducing yet.

[mmt]

> There's all kinds of reasons this is necessary and there's all kinds of reasons why provising a new hardware server, blasting a Linux distro on to it, and just running your server is a bad idea. By no means am I proposing we need to go back to some glorious past, where losing a single hard drive sector means "oh well, guess the database is gone! recovery plan? Our recovery plan is to not need the database anymore!" I'm just saying, it's crazy to think this is all getting simpler. Try looking at this through the eyes of a fresh grad sometime.

Those "all kinds of reasons" aren't necessarily valid, though, because it's not actually possible to go back to that caricature of the past that you describe.

The reason it's not possible is that some things actually have gotten simpler, at least from a user's perspective.

Automatic bad-block relocation has been standard for effectively forever. Even line-speed hardware RAID has been affordable for so long that it's not even a question. Hardware, in general, is routinely villified as being a nightmare, when the reality is that it's boringly reliable and, more importantly, has predictable enough failure rates that there are simple, standard engineering solutions around the failures (often already baked in).

That "inflection point" may well just end up being peeling away all the abstraction layers to discover that simplicity underneath works just fine, since we don't live in the 20th century any more.

[some_account]

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

[bamboozled]

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.

[rhlsthrm]

Eventually, it should be abstracted even further into something that looks like Heroku, but deploys your code onto serverless functions or containers depending on how your service needs to run. A nice, modular, microservice backend automatically with zero config.

[solomatov]

IMO, serverless in the future will be just a kind of resource on k8. k8 is not serverless, k8 is a open source AWS.

[gcoda]

Why wait for future? You can deploy openfaas on kubernetes, i belive there is more serverless projects you can deploy on k8s cluster

[solomatov]

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

[bamboozled]

We’ve had Heroku for almost over ten years now...

[zapt02]

Have you used the AWS interface lately? It's getting further and further away from being streamlined.

[pishpash]

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.

[zapt02]

I haven't worked with Kubernetes but I have worked a lot with Docker. Building your containers is difficult, using existing containers has a bunch of gotchas and getting your containers up and running anywhere resembling a production environment is a giant hassle.

I think containers is the future but we need idiot-proof GUI systems that Heroku and similar services provide to wire up our applications, and we need a good way to handle persistence, which many modern tools ignore.

[parasubvert]

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.

[amorousf00p]

AWS is a feature factory and they are breaking their own back. Today I had an issue where creating an AMI for an application feature set as a golden image (with a very modest price tag at t1.supersmall or whatever) does not scale into high end compute instances due to lack of support for ena. Never was the case before.

Rolled it back into KVM/QEMU in colo with a glue layer REST interface over virsh and will never look back.

Of course we don't use containers..they don't offer an overt benefit in HPC...and I don't think they ever will.

[some_account]

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.

[marenkay]

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.

[pishpash]

Exactly. It will be as simple as working with one machine (long overdue), when developers never needed help.

[amorousf00p]

I think devops was defunct once the asphalt hit the hardpan. Approaching 'generic' secure operational environments as programmable, iterable and contained is one of the great IT lies of the last 20 years.

[cphoover]

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

[fauigerzigerk]

Understanding the characteristics of the underlying systems is one thing, but actually building and maintaining them is something completely different.

[pdimitar]

You definitely have to have a good knowledge about the underlying system, no doubt.

But actually shouldering the burden of creating and maintaining the entire runtime -- and orchestrate it -- is a bit much and stretches people thin.

[lainga]

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.

[yjftsjthsd-h]

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

[dorian-graph]

This is how we ended up with Electron apps.

[jimmy1]

VSCode is an electron app and it's pretty amazing.

[fauigerzigerk]

No, that's unfair. User interfaces have always been and will always be a key responsibiliy of developers.

Writing native UI code is no more low level than using electron. It's just less familiar to web developers and less portable. These are completely different considerations than the greater degree of division of labour I'm predicting for the server side.

[rubber_duck]

>Writing native UI code is no more low level than using electron.

For one JavaScript doesn't have shared memory threads like lower level desktop languages do, it's all neatly hidden in JS event loop or your forced to go IPC route. Shared memory multithreading introduces low level complexity but brings performance benefits if you can leverage it.

Plenty of other low level APIs and technologies that you either can't use or are wrapped in higher level sandbox constructs for JS for portability, security, ease of use, whatever.

Writing native UI code often forces you to deal with low level platform specifics but you get the benefits, HTML UI is just a cheap way to do it (not meant in a derogatory way - it's easy to find devs/designers and target multiple platforms from same code base)

[tormeh]

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.

[pjmlp]

You are quite right, I already have to jungle .NET, Java/Android, C++, SQL, Web on my head, don't need this as well.

[anothergoogler]

What does "DevOps is dead" mean?

[fauigerzigerk]

That devs will no longer do ops.

[_lflx]

DevOps is more like System Administrators doing the work of Software Engineers for half of the money.

[optimuspaul]

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

[josteink]

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.

[parasubvert]

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'

[fauigerzigerk]

There are three (non exclusive) variants of this theme.

a) The term is misappropriated to refer to some something rather different from what it was originally meant to refer to. I may be guilty of doing that.

b) The concept was too fluffy to begin with and sparked a cottage industry for consultants without helping anyone else.

c) The original ideas were flawed and have so many unintended consequences in practice that people rightly start associating the term with those negative outcomes instead of the well meaning goals.

Perhaps a bit of all the above is what's causing the dissonance here.

[vultour]

That's very much not the predominant definition, most companies that hire DevOps people just use it as a different name for a more modern infrastructure engineer. Shitty cheap companies use it to hire developers & infra in one role. My personal opinion is that a DevOps engineer is someone who probably once was a developer so he's very well versed in coding, but switched over to infrastructure.

[tannhaeuser]

That's not my understanding of the term DevOps. Rather, DevOps means using version-controlled artifacts for deployment rather than manual deployment or one-off scripts, and to consider those artifacts a "product" in their own right, or part of the main development artifacts. So that qualified devs could create/edit those along with other developer artifacts, though frequently these artifacts are created by admin-like persons.

And I don't see DevOps becoming obsolete at all; just the other day I spend deploying apps with an ops guy, where neither of us could do it all on his own: the ops guy lacked understanding of the code bases, the endpoints to configure, and integration test procedures, me not having permissions to redeploy and view logs.

[__blockcipher__]

The buzzwords are ultimately meaningless but that sounds more specific to ”infrastructure as code” than the meaning of “devops”. With iaac basically being one of the facets of devops. Does that sound right to you?

[bobbyi_settv]

It generally means "ops work that is done with the best practices of dev work".

Yes, that means infrastructure as code, including code reviews, frequent deployments, etc.

No, it doesn't require that the developers working on the devops code are the same ones who work on the app code. At a small company (e.g., three devs) they will be, but at a large company, you have a dedicated "devops team" who exclusively works on infrastructure (as code).

[mbesto]

I don't take Wikipedia as sacrilege, but I don't see anywhere where it says developers do ops: https://en.wikipedia.org/wiki/DevOps

[sethrin]

Was "sacrilege" the word you intended? Or perhaps "sacred"?

[dkarl]

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

[oblio]

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.

[markbnj]

It's more like experienced devs doing ops in support of devs. As with most terms like this ymmv.

[protomyth]

From some of the folks I was talking to, it seemed more like companies firing their SysAdmins, Release Management, and DBAs and making the developers do the production operations / support.

[rhlsthrm]

Yep, I think it means you can hire one "DevOps Engineer" to do the work of multiple sysadmins/dbas by using these cloud-based services.

[dsmithatx]

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.

[mandelbrotwurst]

Seems he's essentially just predicting an increase in the division of labor between product development and infrastructure work going forward.

[mancerayder]

That's interesting, sounds like the world 5 years ago and before -- outside of the Netflix/Google/Facebook monoliths. Sounds like the landscape made systems so complicated via ease of automation that they don't know what's happening under the hood anymore. That's good news for consultants like myself.

Sincerely,

DevOps guy formerly known as SysEngineer formerly known as SysAdmin for 15+ years.

[dsmithatx]

If you know Ansible/Puppet/Chef K8s platform doesn't require a complicated mess of scripts to manage.

Sincerly,

Platform Engineer former DevOps guy, former SysEngineer, former SysAdmin for the past 24 years.