It doesn't have to be complicated: deliver your work as operating system packages which you've integrated and tested to production and Bob's your uncle. If you invested the gargantuan amounts of time and effort to master "Docker", or "Kubernetes" or "Ansible", then mastering how to make nice, clean RPM's[1] shouldn't be a problem, should it?
Use the "Ansible" RPM module to do mass-deployments (if you don't have anything better, like a software deployment server) and hey Presto! you have effective orchestration.
As soon as one goes OS packaging route, "Docker" for instance becomes immediately obsolete.
I fail to see how this has anything to do with the post. Did you even read it ?
>As soon as one goes OS packaging route, "Docker" for instance becomes immediately obsolete.
Reproducibility is still a brand new frontier on the OS packet manager scene, see Nix, much less the flexibility and integration you get with containerization. That's a completely asinine point you're making.
Yes I read the essay. Did you in turn understand what the root cause of that essay is, id est do you understand why "Devops" even came to exist? It exists because "developers" do not want to learn anything about system administration and do not want to learn how to make OS packages, even though ironically, OS packaging was invented for programmers to be able to deliver their software in a standardized, easy way.
RPM can decompress, dearchive, compile, link and automatically test software before packaging, and so can FreeBSD ports. By delivering their software as OS packages, none of this "Devops" nonsense would have to exist in the first place, and frankly it is utter nonsense, hacked-up mess we are in because of it.
Packaging is the answer. And it's much simpler than all these overcomplicated "CI / CD" pipelines.
That's the core problem in that essay. The rest are symptoms of this root cause.
Devops is agnostic to which tool you use. The same ideas apply regardless if you use RPMs, Docker containers, VM images, ... as the format to deliver apps. (remember, the term is from 2009, and that was just when the catchy label was attached, not when people started doing these things, I'm sure good teams did things the label is appropriate for in 90s too)
"Devops" is nothing more than making "developers" responsible for supporting the mess they "release", because the model of them just shrugging off all responsibility for support, and the sysadmins (2nd level support) being stuck with the fallout was unsustainable. That's the long and short of it.
Use the "Ansible" RPM module to do mass-deployments (if you don't have anything better, like a software deployment server) and hey Presto! you have effective orchestration.
As soon as one goes OS packaging route, "Docker" for instance becomes immediately obsolete.
--
[1] http://rikers.org/rpmbook/