What is DevOps? Everyone wants it, but it’s hard to find a definition that everyone agrees on. Some think of it as a toolset, some think of it as an application delivery pipeline, some view it in the context of developer IT, and some view it as calling to cloud. Taking it to the more abstract, some view it as a way of applying Agile methodologies to operations, and some see it as sharing pain between all technical stakeholders as a forcing function for iterative improvement. They are all right.
DevOps has been around, as a named concept, for nearly a decade now. Early pioneers of DevOps hailed from the ranks of backend coding gurus, Ops veterans, and CompSci visionaries. Whether they had automated their own development environments, continuously removed bottlenecks with shell scripts and cron jobs, or viewed the technology landscape through the lens of shared-nothing distributed computing, they had one thing in common: a search for a new way to tackle the age-old challenges of IT in a progressive, iterative way that would result in the ability to quickly scale applications to meet uncertain demands, while simultaneously removing the need for linear staffing and inefficient toil.
So, again, what is DevOps? Well, it usually depends on what your background is. I find it useful to take a look at it from two distinct lenses, which seem to be the major perspectives from which the subject is generally discussed:
Devops and devOps
Since the practice originated from the merging of two disciplines, it stands to reason there will be a Dev-centric view, and an Ops-centric view. Neither is incorrect, but alone they are incomplete.
Devops, in this framing, focuses on the reduction of:
- Time to working code
- Barriers to developer productivity
- Testing overhead
- Delivery time to production
devOps, in contrast, focuses on the reduction of:
- Provisioning and deployment lead times
- Configuration variance
- Operator error
- Admin to server ratio
By aligning these views with the pivot point in the well-known Continuous Integration/continuous Delivery (Converged Infrastructure (CI)/CD) pipeline, we see where the old handoff lines lie. What used to be The Wall between development and operations has been demolished, reduced to rubble (the “/”) and in its place, a DevOps pipeline has been built. This pipeline takes code that is developed in a modern architecture (microservices are favored in this new model), packages them into containers, applies automated processes for merging code with continuous unit and integration testing, as the Continuous Integration process (CI).
The continuous delivery (CD) portion of the process takes the verified and integrated code, and deploys it into production, which occurs by promoting verified code to production platforms, that have themselves been engineered to be quickly reproducible and scalable, via configuration management and Infrastructure as Code design principles.
From a DevOps perspective, one revolutionary trend that radically collapses this “/” chasm is “cloud native” development. This doesn’t mean “public” cloud, mind you, it could be on any cloud, public or private. What it does mean is microservices based, containerized architectures. When armed with modern tools and environment for cloud-native development, a DevOps organization can deploy code packaged with the infrastructure bits to go with it almost literally at a click (or a single command).
This process isn’t born whole, nor does it occur overnight. Sometimes, these transformations toward modern development and deployment models take years of blood, sweat, and tears by dedicated teams and individual champions. The required cultural transformation is not for the faint of heart. However, for the stalwart, the results are a new way of doing business, a new way of delivering value to customers, a new way of competing with a sharp edge in an increasingly competitive technology landscape.
Learn more from the recent webinar hosted by NetApp’s Ingo Fuchs on Building More Impactful IT with a Hybrid Multi-cloud Experience.