Too often "DevOps" emerged as a way to walk around system administrators and their "blabling" about security, resource management, upgrades and long-term maintainability.

I'm always upset when I see a installations that are created with pattern: "we need it to run and we doesn't care where system will be in next two years" (in trashcan, usually - or it will act as a jumphost for another scam/DDoS). And I see such systems everyday. And that dramas, when I ask a simple question like: "how it will be upgraded"? "What is your plan about dealing with manually-installed python modules that overwrites files from system-installed ones when system upgrade will be performed?" and so on, and so on...

Fortunately a separate "devops" team that really cares about infrastructure reliability usually evolves into a normal sysadmins in no-time and their priorities are usually different that rest of "dev-teams".

this makes sense because operations and development have different priorities which are sort of opposite of each other.

changes increase instability and unpredicatability in environments. and the people keeping them running 24/7 are usually the ones getting paged when shit hits the fan.

Long-term maintanability is especially hard, and the lower you get in the OSI model, the more painstakingly it becomes to replace things without major impact.

This is why I like the 'platform engineering' meme - much better way to frame the value proposition. See: Thoughtworks' blogs and podcasts on platform-engineering-centric topics.