The series so far:

1. DevOps and application delivery
2. DevOps application delivery pipeline
3. Database DevOps
4. DevOps security privacy and compliance
5. DevOps Database Delivery
6. 10 Guidelines for Implementing DevOps

The processes used to build and deploy today’s applications have undergone a dramatic shift. Efforts that were once segregated and performed in isolation are being joined into a single process flow that incorporates both development and operations. This new methodology, dubbed DevOps (a portmanteau of the two disciplines), bridges that gap between development and operations with the goal of delivering software more rapidly, frequently, and reliably.

This article is the first in a series about the DevOps movement and its impact on application building and delivery. In this series, I’ll introduce you to DevOps, provide an overview of the application delivery process, discuss issues that come with incorporating database management systems, and dig into specifics about security, privacy, and compliance. I’ll then tie up the series by discussing considerations to take into account when moving toward a DevOps model.

To help you get started, this article introduces you to DevOps and explains why this approach to application delivery is so important in today’s environment. As part of this discussion, I provide an overview of the advantages that DevOps offers and explain a few of the more important concepts that go into the DevOps process, with the proviso that I’ll be covering some of this information in more depth in subsequent articles.

Application Delivery Under Fire

Traditional approaches to application delivery place the development team on one side of the fence and IP operations on the other. The development team writes and tests the code, compiles it into neat little software packages, and tosses them over to the operations team, which deploys, integrates, and maintains the software, often in isolation from the other side.

This segregated approach to application delivery frequently relies on waterfall methodologies for building and deploying software. Waterfall development follows a logical progression of steps that start with gathering requirements and ends with application maintenance. The steps in between are carried out in a linear sequence, each with a distinct objective, such as defining the technical design, developing the code, or monitoring the application.

Figure 1 shows a representation of the waterfall methodology, in which the application delivery process is broken into five distinct steps—Plan, Develop, Test, Deploy, and Operate—with each step completed before the next one begins. In most cases, the tasks within a step are carried out by a single team (or individual), with relatively little cross-over between teams.

Figure 1. Traditional waterfall development

The steps shown in the figure are meant only to demonstrate the principles behind the waterfall methodology. In practice, the breakdown will likely be different and contain more steps. For example, the planning phase might be divided into two or more steps, such as gathering requirements, developing specifications, and designing the application. Regardless of the breakdown, the principles are the same: Each step is a discrete operation that is completed before moving on to the next step, similar to a cascading waterfall, or so the metaphor goes.

In the good ol’ days of simple desktop and client-server applications (accessed entirely behind the corporate firewall), the waterfall approach was usually more than adequate, providing a comprehensive, disciplined methodology with clearly defined roles and little room for deviation.

But we now live in an age of constant security threats, highly mobile users, and consumer-driven work models with little tolerance for disruption in services. In such an environment, application delivery processes based on a waterfall methodology or similar approaches are too inflexible, slow, and inefficient to meet today’s application challenges. And that’s where DevOps comes into the picture.

The Agile Connection

The DevOps story begins with the Agile approach to application delivery, which emphasises people and communication over processes and tools. Individuals work closely together to deliver software in quick and incremental cycles known as sprints. In each sprint, participants focus on a specific phase of the project, carrying out a small chunk of work in a defined period of time.

The Agile methodology has quickly supplanted the waterfall approach as the darling of development teams across organisations large and small. However, the model’s success also made it apparent that application delivery could achieve greater efficiency if development and operations worked more in concert with each other, rather than at odds—a realisation that has given rise to the DevOps movement.

DevOps attempts to bridge the gap between development and operations, which is something Agile doesn’t normally do. That said, the exact relationship between DevOps and Agile—or the differences between them—is not all that clearcut. Some people see DevOps as an extension of Agile, others see it as a replacement, and still others treat them as nearly one and the same. In fact, you’ll find a wide range of interpretations on how Agile and DevOps are related and how the two might differ.

But rather than add to this discussion here, I’ll say only that there seems to be at least some agreement that Agile and DevOps can serve as complementary approaches to application delivery, even if the lines between them are sometimes blurred.

DevOps and application delivery

The DevOps approach calls for a shift in perspective from one that sees application delivery as a set of discrete, independent stages to one that incorporates the entire application delivery chain into a continuous, integrated process flow that includes everything from application design to system monitoring. The DevOps approach brings development and operations together with the goal of streamlining application building and deployment into an automated process that takes into account the entire delivery chain.

Under the DevOps model, application delivery is a continual workflow that essentially loops back onto itself to support a continuous process, as shown in Figure 2. You still have specific tasks that must be carried out, but they’re performed as an integrated whole that requires all participants to work together to keep the flow moving.

Figure 2. The DevOps process flow

As with the waterfall approach, DevOps can be represented in various ways. You’ll often see the process illustrated as a figure eight rather than as a circle or the tasks following a different outline. For example, the Develop stage might be broken into the Code and Build stages, the Deploy stage might be divided into the Release and Implement stages, and the Operate stage might be separated into the Operate and Monitor stages.

Regardless of how the DevOps process is illustrated, the important point is that application delivery is a unified, integrated process flow, rather than the type of linear, segregated phases you see in waterfall development. In a sense, transitioning from a waterfall to DevOps methodology is like moving from a two-dimensional line to a three-dimensional grid in which the intersection points are all connected.

DevOps and the CAMS model

At its core, DevOps is about creating a culture of collaboration and transparency that fosters open communications across all teams involved in application delivery. The DevOps approach seeks to break down siloes and encourage a sense of shared responsibility, creating an environment in which everyone works together to build and deploy software more effectively than with traditional methodologies.

Although discussions around DevOps often focus on coding and deploying the application, a successful DevOps effort also requires that quality assurance (QA), security and business considerations be fully integrated into the process flow, with support for the type of cross-team communications necessary to fully protect data and ensure the application’s success.

To this end, DevOps is often described in terms of the CAMS model (culture, automation, measurement and sharing). Together these four principles define the operational foundation on which DevOps is built:

• Culture: A transparent and collaborative environment that encourages communication and cooperation among participants, with processes and tools in place to support these efforts.
• Automation: The ongoing automation of repeatable and time-consuming tasks to create a unified workflow throughout the application delivery process.
• Measurement: The ability to monitor and track the various tasks performed throughout the application delivery process in order to correct and improve the DevOps workflow.
• Sharing: The ongoing sharing of knowledge, resources, and tools among all individuals participating in the DevOps workflow.

The four CAMS principles promise to make the application delivery process more efficient, flexible, and responsive to changing requirements. Because each cycle is shorter, application releases are available faster and more frequently.

With the DevOps approach, you don’t run into the types of knowledge transfer issues you get with traditional development efforts, which can lead to increased costs and risks. Team members own the entire lifecycle, sharing information and participating in the same processes while avoiding many of the communication breakdowns that afflict segregated teams. The DevOps approach also includes a built-in mechanism for constantly improving processes and streamlining operations, based on current requirements.

The DevOps Process Flow

To facilitate application delivery, the DevOps methodology leverages a number of tools and technologies that support the process flow. Together they create an automated application delivery pipeline that offers continuous integration, delivery, testing, deployment, and monitoring. Figure 3 updates the previous figure to reflect the integral role that the continuous services play in supporting the DevOps process flow.

Figure 3. The continuous services of the DevOps methodology

The continuous services streamline the application delivery process, making it possible to implement software faster and more efficiently:

• Continuous integration provides a mechanism for adding, updating, testing, and validating the code on a regular schedule.
• Continuous delivery works in conjunction with continuous integration to provide a structure for developing, testing, and deploying code as part of an integrated automated process.
• Continuous testing incorporates QA into the automated operations while supporting such tasks as unit and functional testing.
• Continuous deployment provides a structure for automatically releasing code that has been committed to the repository and has passed the automated testing phase.
• Continuous monitoring tracks and reports issues that occur during the application delivery process.

Several tools are available to help teams implement continuous DevOps services, including source control and configuration management solutions. A DevOps environment might also incorporate such technologies as containerization, microservices, or infrastructure as code. In the next tutorial, I’ll dig into the DevOps process flow in more detail to provide a better understanding of how all these pieces fit together.

Moving Toward the DevOps Model

Implementing the DevOps methodology requires personnel who have the ability to bridge development and operational boundaries, people who can speak both languages to bring application delivery under one roof.

Although the exact requirements will depend on an organisation’s size and type of development efforts, most organisations will require individuals with broader skillsets than those required for more traditional approaches to application delivery. For example, a DevOps team might want operation engineers that have some understanding of software development or developers who have experience with deployment processes and tools.

The DevOps methodology relies on having the right people and tools in place to carry out all phases of the application delivery process. That said, DevOps is more than just skills and tools. It’s a philosophy and culture that requires a different mindset from traditional approaches to application delivery. It’s about collaborating and communicating and bridging the gap between development and operations in a way that has not seemed possible or practical until now.