Not really, it has mostly been about managing operating systems and servers, not much else. There was a whole mess of homegrown scripts, and the PXE mess, and a

Not really, it has mostly been about managing operating systems and servers, not much else. There was a whole mess of homegrown scripts, and the PXE mess, and an even worse IPMI mess. Keep in mind that "ops" and "admin" really depends on 'how much you have', a half rack of hardware was also managed by "ops" and "admin", and generally bootstrapped by hand and maintained with individual remote access or kludges like cssh/pssh. Even legacy systems like puppet were mostly used in the context of cluster management, not an entire fleet of mixed systems. There was no API for any of this either, so any programmatic access had to traverse layers of incompatible proprietary systems. Developers did (and do) none of this. This work hasn't disappeared or changed much, and also isn't part of the DevelopmentOperations amalgamation. The grey area that it creates used to be the realm of release engineers and technical application operators. Those are the roles that have largely disappeared when an environment goes from legacy to more modern organisational structures. This overlap (and the legacy disaggregation and hyper-specialisation) exists for a reason: developers that don't have to wait to deploy and instrument can release faster and more often, which adds value. But specialisation to enable developers to do all this is now needed because that extra value that was created now needs to be protected and enabled at scale, something that is enough work to keep one or more FTE busy. This is where specialisation (in a business context) comes from in general. If administrating systems and operating those systems was a very small task and easy to learn, there would be no sysops/sysadmin specialisation and the janitor would do it.