Tension have existed between developers and IT operations teams since the dawn of IT. But as developers came under increased pressure to develop more applications faster they began to look for ways to deploy applications simpler. That requirement eventually gave rise to public clouds that developers could programmatically access via a published set of APIs. But as the number of applications deployed on those public clouds increased it became apparent there was a need to be able to manage the deployment of all those applications at scale. That requirement gave rise to DevOps, which as an IT management philosophy calls more organizations to develop application pipelines that are collaboratively managed by developers and IT operations teams.
Naturally, the degree to which DevOps is practiced varies widely by IT organization. Companies that started up in the last few years typically enjoy the benefit of having no legacy platforms to support. That makes it much simpler to integrate DevOps process because there’s no organizational inertia to be overcome. In contrast, organizations that need to manage multiple iterations of IT architectures spanning everything from mainframes to the latest container applications. In most of those IT environments there are not only divisions between development teams; each server, storage and networking function attached to each platform in use tends to create its own management silos.