DevOps Is Not Just About Pipelines

Over the past decade or so I have had the privilege of working in a variety of organizations. And no matter how different the organizations are from one another, I find one common characteristic. I find that virtually everyone says "We know DevOps!" or "We Do DevOps" and when I dig a little deeper I find that they think DevOps is about delivery pipelines. Most people think that if you practice CI/CD (Continuous Integration/Continuous Deployment) then you are "doing DevOps".

It is unfortunate that DevOps followed the Agile movement. It is also rather unfortunate that DevOps grew out of Jezz Humble's practice of Continuous Delivery. The history has caused a succession of corporate behaviors that has gotten us to a place where few have even attempted the cultural change that is necessary to be "doing DevOps".

Challenge I: The Cross-Functional Team Usually Lacks Ops

After organizations went through their Agile transformations they began to integrate systems analysts (application design) with developers (coders) and even QA folk (testers). By creating Sprint teams that included a deemphasis on design documents, and instead just iterating through the feature changes, velocity improved. When QA began shifting the testing tail left we began ensuring that developers began unit testing and even automating testing at the moment the application was being first developed. All of this helped align the delivery of software with the needs of the business.

But since most enterprises handled their infrastructures in a traditional operations department, there is still a lob-it-over-the-wall thing that is happening when applications are ready to deploy. This late stage involvement of operations often leads to missed opportunities in the area of infrastructure modernization. It is as though the presence of an automated delivery pipeline has caused development teams to think they don't need an ongoing presence of operations and infrastructure folk.

Challenge II: Keeping Pace With Technological Change

By automating a delivery pipeline we have created an appendage to the traditional data center and now if we change the datacenter we have to change the pipeline. This can instill a behavior of if-it-aint-broke and cause development teams to continue using legacy cloud technologies even after they are antiquated.

A case in point is the advancement of AWS with their diverse offerings and the implementation of Kubernetes. Many organizations think that after they have containerized their applications and begun using Kubernetes then they have completed a devops transformation. Most development teams that do not include cloud engineers and architects remain unaware of opportunities to improve their applications. It is simply not possible for a developer to remain current on all of the language and application architecture issues as well as the ongoing and rapid advancement of infrastructure.

Solution: A True Shift-Left Approach Requires The Ops With The Dev

"Shift left" doesn't stop when you integrate testing into your cross-functional development teams. It needs to include enterprise architecture at the onset of new development. Cloud Engineers and Architects should be part of application design to ensure that the most advanced infrastructure approaches available are considered at the beginning. Edge computing, serverless approaches, improved networking, and last but certainly not least... improved approaches to security, are all things that must find their way into application design.

To ensure that these new capabilities are part of the ongoing enhancement of existing applications there needs to be an enterprise architect capable of addressing the operations issues on the developer teams. Embedded engineering is a must to achieve some of the culture change required for DevOps transformations.