A bit over a year ago I researched what "Devops" means, and the answer seemed to be Developers being able to push code to production without having to involve Operations. This sounds like a good goal to have (presuming you've got good unittests etc.) as it removes an unnecessary friction for developers.
What it doesn't include is all the higher-value work the people on the Operational side tend to provide, like thinking about rollbacks, machine failure, network failure, provisioning, capacity planning, change/configuration management, security, monitoring etc - which is not to say that all developers don't think about these things, their focus tends to be on developing product rather than these non-functional requirements.
I'm presently in a world of Ubuntu LTS+a few manual backports for similar reasons as the authors. My home systems are ansible managed, giving me things like wireshark installed everywhere if I need it and new machines automatically hooked into Prometheus monitoring (which is much easier with my debs). I've seen what happens if you try to manually manage machines, and know that a small bit of upfront work will bring dividends later.
Writing the core code is just one critical step in running software long term, let's not forget the rest of the critical steps to keep it running in a sane way in the future.
Among all the definitions I found, that was the only common theme.
I've been discussing this with others in the "DevOps" space and in recruiting terms a "DevOps engineer" seems to mostly mean an "Ops engineer". True Devops (in the sense of developers who also care about and perform all of their own operations) is a culture, not a job role and one that seems quite rare in the wild.
The problem is that DevOps isn't a person, DevOps is a team.
Historically large companies had strictly separate development and ops teams. DevOps is about fusing them together so they talk to each other and influence each other's thinking for the benefit of everyone.
But of course sane definitions don't make good buzzwords so now we hire "DevOps" people just like we buy "private cloud" servers.
DevOps is as much about making your developers ops engineers as Agile is about making your stakeholders developers. It's a possible side-effect, but neither necessary nor sufficient.
Definitions of the term are almost as diluted as "cloud" is. It is easier to define it as what it's not.
Look up Jez Humble for a bit more idea into the origins of the term. The term is a primarily a buzzword among larger companies and almost always followed up by some engineering cultural change objective rather than about how code is deployed or even developed and run. You know that it's another management-focused trend when there's entire conferences where people say devops constantly without mentioning anything about code and half the folks in attendance or speaking are consultants in suits that consider Excel formulas the extent of their coding skills.
So the common theme I see is "any way besides what we used to do operations traditionally." It's mostly used for "operations with some idea of what is being deployed on the stack above them." Most start-ups don't have this problem at all with modern infrastructure (no more rack and stack at your 5-man start-up probably) though by definition because rigidly defined roles are a Big Company Problem.
The problem modern startups have is that a developer sees he can make calls to AWS or Azure APIs and assumes that makes him qualified to define system architecture, security policies, deployment processes, etc.
"Modern" infrastructure (by which I assume you mean provisioned, destroyable VPS instances + associated services such as AWS, Azure, etc) is effectively just a new "how" - you call an API instead of deploying a config file or similar. You still need to know the "what" and the "why" to be effective.
I don't necessarily see the situation as inflated egos as much as lack of resources to do it better. I have rarely met developers that are excited to do operations work like defining and implementing system security policies, change control, and orchestration. It's a chore that's as exciting for them as doing their laundry.
I'm being very conservative with what "modern" means (within the past 20 years is about right). Traditional shops are still racking and stacking machines and maybe deploying VMs by hand using ITIL stuff trying desperately to slow down system changes to deal with demand rather than to speed things up like most shops have done. Where I am now, the "traditional" IT side of the house takes roughly 5 months to provision a new server (I lead operations on anything bleeding edge, which is now standard for most start-ups).
Going from using maybe kickstart files to API calls is not as big of a deal as the fact that you can even get something on demand in any way instead of going, finding another job, quitting that job, coming back in shame, and realizing that the server you asked for is finally up.
I've definitely met developers who made the choice to say "I can do this myself, I don't need someone else to do it", and I've also met developers who when tasked with "make our app run" simply say "ok, its running on port 80, so it's up right?" without any of the associated work to make it secure, reliable, backed up, etc.
The common themes IMO are either, developers doing ops (a nightmare if you ask me) or ops teams utilising more "development" like processes such as automated setup tools, configuration management, etc.
As I said, I don't treat "developers can push to an environment" to be the defining factor or the definition of devops
The problem with targeting Debian Stable + Backports is that your packages are going to perpetually out of date unless you go to the trouble of packaging up your dependencies as .debs and running your own apt server. Targeting Debian stable is fine if you can get away with using three year old libraries. But for a lot of languages, like Python, 3 year old libraries are at a significant feature disadvantage when compared to their current counterparts.
When you say "out of date", you probably mean feature wise, not security and stability wise? For me that is an acceptable tradeoff for most of the packages. Most of the stuff doesn't evolve at such pace that I should have the latest and greatest (I am talking about core libs and similar). And the packages where I miss some new functionality, I can just upgrade them manually. Take Firefox for instance - if you don't like/trust Iceweasel, you can just install FF to /opt/ and trust Mozilla for upgrades. For me this is win-win situation. You have a stable and secure foundation and you put bleeding edge stuff on it when you need it.
Indeed, for myself I prefer stable releases (Debian, Ubuntu LTS, etc) and use apt pinning so that I can use newer versions of apps that I need to use. Very rarely will I have a problem; in fact the few times there is a problem it is normally solved by apt-get source ; dpkg-buildpackage.
It depends, normally in order of preference LTS, LTS backports, then latest release. So then if you want the newer version you can do apt-get install <package>/<release>. I typically use Apt::Default-Release "<release>" in a separate apt.conf.d file.
Just yesterday I had a problem which was some combination of Debian Jessie's incredibly outdated Python CFFI library (0.8.6) and its interaction with OpenSSL which took a script from taking milliseconds to launch to over 1.5 seconds, purely due to that import.
Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic.
The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path).
That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.
> The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me.
And what about the way management thinks that's when you don't have to pay Operations people (those guys who always try to stop progress in your company)?
> No one says "we don't need someone to setup/maintain our servers".
Of course they do. And there are a lot of products which are marketed using that idea:
"AWS Elastic Beanstalk is the fastest and simplest way to get an application up and running on AWS. Developers can simply upload their application code and the service automatically handles all the details such as resource provisioning, load balancing, auto-scaling, and monitoring."
The configuration management/orchestration tools also help with that (you don't need anyone to provision the servers, take care of dependencies etc., you can just include these 15 Chef cookbooks, and everything will be done automatically). Btw: I'm not saying configuration management tools are bad - they are a must-have, I'm just saying - nothing will replace a person who knows what they are doing.
> Developers can simply upload their application code and the service automatically handles all the details
In this situation, you've basically traded your own Ops staff for a combination of your developers and whatever support AWS provides you - so you're back to a managed service like every man and his dog was using in the 90s.
The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me.
I'm also in the same boat as the author, in that I recommend and target Debian Stable + Backports (and some vendor/community repos when required).