When I consider the new DevOps movement from the first rumblings I heard of it to my first reading of the definition of DevOps to my current job as a DevOps engineer, albeit a self-proclaimed one, I often wonder what the difference is between my position and the positions of engineers past.
I have heard speakers at conferences mention silos in organizations as well as the better approach of cross-functional teams. When I think of DevOps it seems to be more a move towards a more functional team management and workload distribution methodology than it seems to be an individual job description, or even a set of new job descriptions.
Further, it seems to be an acknowledgment by the IT community that for a developer to be successful the developer has to do some systems work and likewise an acknowledgement that for a system administrator to be successful they have to do a bit of programming.
Is DevOps not just a mind-based, thinking correction for the IT industry as a whole?
If not then would that indicate there are situations where the DevOps approach is not appropriate and a more siloed approach is?
With all of this in mind, how measurably different are the job descriptions of a team with DevOps engineers from the teams of the early '90s early '00s or the teams of ten years ago?
1) what is the difference between now and 19 or 15 years ago? The difference is that a) operators and their responsibilities are getting much more visibility that they had 10-15 years ago. Partially because their job has gotten much more difficult. and b) the tools to support various deployment and continuous deployment pipelines are astounding and continue to improve.
Your second question is are there situations where DevOps is not appropriate? The answer is, of course. Continuous delivery and deployment assume that all tests can be automated and that errors in production can be found and fixed relatively quickly. This is not the mind set I would want for someone designing a nuclear power plant or an aircraft flight control system.