DevOps as a service

I often get asked what DevOps is all about. The curious post questions having little to do with technology, as the term has penetrated our daily lives the same way as the blockchain, but this is for another discussion. People hear the word and wonder what it means for their day-to-day operations in their professional life and conversation topics. The topic is overloaded with interpretations, opinions, political agendas as well as sales pitches. The internet has many explanations and interpretations, depending on what answers you seek. One can satisfy their understanding by pointing to an internet resource and be solicited with the audience's view of What DevOps is all about. Some publicists suggest that DevOps is not a function but an SDLC practice, proposing to use it as an alternative to Agile and Waterfall approaches. I somewhat agree with that, but we can discuss this later.

I am proposing my personal view on the function of DevOps and justify it with experience and logic. The term or acronym ‐ DevOps combines two words – development and operations. Philosophically the question arises: "Can it be described as an operations function?" The development community usually asks and interprets this, implying that DevOps is an administrative and support function within a technology organization. It is essential to state that teams that practice DevOps are neither developers nor operators ‐ they are both and much more.

In private conversations, DevOps engineers tend to state:" We were trying to implement DevOps practice, but the architecture of a product or an application did not allow us to automate the release cycle fully." There are multiple reasons for this challenge, which perhaps I'll cover in another paper. Well, let's talk about the release cycle then. Releasing software in the enterprise organization must adhere to the SDLC process, project, and change management practices. The main reason for those practices to exist is to streamline application support and accurately manage operational resources. Naturally, an organization is driven by efficiency, whereas R&D or development is driven by functionality expansion. Project and change management forces perform a balancing role to ensure timely functional delivery and appropriate funding of operational evolution.

With the above statement in mind, the following questions arise: Who is looking after the efficiencies in operating the built software? What about the automation of some or all processes? What about functionality reuse? Depending on the organization, some of those functions are owned by the architecture teams. Solutions are articulated, documented, and strictly followed by developers, administrators, and operators. Often these groups operate in silos, which leads to interpretations rather than clear communications across the silos' borders, creating a gap in the ability to understand the end-to-end picture and leads to operational inefficiencies. Can the DevOps approach assist with the enterprise alignment?

In recent years the industry has become very iterative. Many options surfaced for developers to leverage and solve common problems, allowing them to concentrate on the value‐add functionality. Community or the common industry patterns are delivered in code or libraries and fully flashed systems. The introduction of such products that cover practices required by an organization is believed to save much money and address operational efficiencies. The abundance of those (out of the box) solutions leads to a new requirement within the enterprise to fill the gap of using the right solution that brings the most value to the company. The introduction of such systems often dictates the prescribed SDLC, practices, and operational considerations.

DevOps to the rescue. Initially, DevOps started as an advocate for the toolset maturity used by developers, answering the questions like How to set up an environment? What build standards to use across the enterprise? How to build and iterate the code? Where to deploy? The culmination of DevOps involvement was to monitor release processes and run analytics on the pipeline performance. I should stop, but I'd like to stitch my earlier comment about "DevOps is not a function, rather SDLC practice. "

Naturally, developers want to use the latest and greatest to deliver business functions to an end consumer. The conversation about the toolset, its function, integration, and deployment are incomplete without practical knowledge of the software and third‐party tools. The introduction of complex or unreliable tools can be expensive and even detrimental to the organization if the pattern is intertwined with the design and does not answer the business requirement in the long term. DevOps practice allows close collaboration between business, architecture, development, infrastructure, and operations to minimize the deviation from the pre‐defined (paved) road. Continuous integration and delivery create early visibility of software performance in a real environment. Toolset evaluation and configuration bring assurance to the proper choice selection. The close collaboration of DevOps engineers with development and architecture organizations eliminates product usability gaps in the target environment. Automation, reporting, and visibility into the SDLC process provide a clear understanding of organizational behavior.

DevOps, with this understanding, becomes the glue between the business, system design, and operations. When an organization thinks of the future in terms of efficiency and the silos no longer exist, the DevOps practice provides visibility across the teams and raises questions on the validity and reuse of the architecture.