Why cloud makes agile and DevOps more important

The very characteristics of cloud computing that make it so attractive also expose the shortcomings of application development practices - and make improving them critical.

Cloud computing has changed the world of IT infrastructure forever. Today, immediate availability and unlimited scalability is the default expectation of infrastructure users. Developers and applications groups view anything that doesn’t measure up to this standard as deficient, and they’ll bypass deficient infrastructure in favor of cloud environments that provide quick access to computing resources. Consequently, many IT operations groups find their lethargic private cloud projects sitting idle, resulting in expensive write-offs and organizational friction.

However, the impact of cloud computing extends well beyond the debate about what infrastructure is right for application deployment. In fact, the biggest effect of the cloud may be on application groups, not their infrastructure counterparts. This is because the very characteristics of cloud computing that make it so attractive also expose the shortcomings of application development practices—and make improving them critical.

Why is this? Simply stated, once the infrastructure bottleneck is addressed, upstream bottlenecks are exposed. These latter bottlenecks all relate to the application lifecycle, which is the province of development and application operations groups.

Before the cloud came along, time frames for infrastructure availability were measured in months. Application groups had to perform only a bit better than that to avoid being “the long pole”—the project task that sets the final delivery date.

Development organizations often delivered no more than one release per year because the underlying infrastructure couldn’t be made available more quickly. Waterfall methodologies were the order of the day, and ITIL operations practices ensured that manual service processes would prevent rapid application changes.

Those days are gone. Application groups that use cloud infrastructure need to upgrade their development and operations practices to ensure they move at the speed of the cloud. The diagram below shows the new application lifecycle and the practices necessary for today’s applications.

Diagram: New application lifecycle and the practices necessary for today’s applications

Developing agile practices

The new application lifecycle starts with business objectives and presumes a close collaboration between application owners and development groups, all with the goal of accelerating innovation. One common practice is to co-locate product managers and developers to ensure information sharing and rapid decision-making.   Within the development group itself, agile practices rule. Groups gather each day in a “stand-up”—brief meetings with no sitting allowed—so that members can share progress and surface issues. Development teams implement frequent releases based on two-week development cycles (commonly called sprints, which gives a sense of their pace).   Continuous integration (CI) is critical to meeting this

Continuous integration (CI) is critical to meeting this biweekly release schedule. Every code check-in results in an automated build process that creates a complete application component. CI highlights any code conflicts or missing code fragments. A common rule is that any fail in a CI build brings all other work to a halt until the problem causing the failure is fixed.

Agile practices enable rapid development of application functionality and ensure that new releases don't compromise existing functionality. Agile also prevents the traditional outcome associated with protracted development timelines: The application is delivered only to be rejected because the business sponsor says it no longer meets market needs.   The move to agile development is not trivial. It requires both process and tool changes. From a process perspective, many development groups struggle to create two-week deliverables, since this requires greater functionality granularity. Said another way, developers have to get comfortable delivering relatively small changes and recognizing them as meaningful.   Development groups and their business counterparts often find rapid decision-making a challenge, as it requires making choices with little information. The flip side of this is being willing to change decisions later, should additional information show the original choice was wrong.   Agile also requires tooling changes to support CI and two-week delivery cycles. Incredible as it seems, many development groups still hand-build code releases and treat integration problems sequentially. To support CI, you need an automated build process triggered at each code check-in. This requires the integration of hands-off tools as well as helper tools, such as automated testing tools that run acceptance tests for every build and forward failures to the appropriate developer to fix.   The end result is a much faster development process, but one should not underestimate the work required to get there.

The move to agile development is not trivial. It requires both process and tool changes. From a process perspective, many development groups struggle to create two-week deliverables, since this requires greater functionality granularity. Said another way, developers have to get comfortable delivering relatively small changes and recognizing them as meaningful.  

Development groups and their business counterparts often find rapid decision-making a challenge, as it requires making choices with little information. The flip side of this is being willing to change decisions later, should additional information show the original choice was wrong.   Agile also requires tooling changes to support CI and two-week delivery cycles. Incredible as it seems, many development groups still hand-build code releases and treat integration problems sequentially. To support CI, you need an automated build process triggered at each code check-in. This requires the integration of hands-off tools as well as helper tools, such as automated testing tools that run acceptance tests for every build and forward failures to the appropriate developer to fix.   The end result is a much faster development process, but one should not underestimate the work required to get there.

Agile also requires tooling changes to support CI and two-week delivery cycles. Incredible as it seems, many development groups still hand-build code releases and treat integration problems sequentially. To support CI, you need an automated build process triggered at each code check-in. This requires the integration of hands-off tools as well as helper tools, such as automated testing tools that run acceptance tests for every build and forward failures to the appropriate developer to fix.   The end result is a much faster development process, but one should not underestimate the work required to get there.

Get the Forrester report - The Proliferation of Hybrid Cloud: A Look at Current Global Hybrid Trends and Approaches

Building automated operations

It’s not enough to develop code quickly. Once a code update is ready, it needs to go into production as quickly as possible. This brings us to the next common bottleneck: manual application operations processes.

There are often four or five steps between finished code and production deployment. Typically, most of those steps are manual. Worse, each step involves more work because the updated code needs to be recompiled and manually installed into new infrastructure resources.

Worse yet, each manual step introduces the possibility of errors, which prevents proper application operation and causes rework back upstream to identify the problem. This manual approach is outdated in today’s application world and is being supplanted by an approach referred to as DevOps (short for development and operations).

The hallmark of DevOps is automated code deployment and use of a single execution environment, such as a virtual machine or container, across deployment steps. A typical approach consists of:

  • Automated creation of the execution environment for updated code. This may take the form of creating new virtual machines or new containers via a control script. Alternatively, it may reuse the execution environment created during development and testing.

  • Automated installation of the updated code. Of course, if this step reuses the execution environment and application code packages from dev/test, there is no need for it.

  • Automated deployment of the execution environment/updated code bundle into the application topology. This places the code bundle into an application environment using the identity management and keys appropriate for the specific environment. Note that this may change across several stages between code release and production deployment, such as staging or load testing. Good DevOps practices ensure that the same code bundle can be deployed into multiple environments and environment-specific elements can be automatically injected from outside the code bundles themselves.

  • Configuration of the new code bundle to ensure connectivity with other application resources. This typically involves registering the bundle with a load balancer directing network traffic from upstream and connecting the bundle with any downstream resources it communicates with, including one or more load balancers. It also includes registering the bundle with monitoring and management tools so that alerts and logging can occur.

As with the shift to agile development, DevOps requires both process and tooling changes, which can pose challenges. However, once an automated DevOps capability is in place, the organization can roll out changes once a week, once a day, or even once an hour—all with no additional work on the part of operations personnel. A working DevOps pipeline is a thing of beauty to behold, and helps bring the vision of truly automated end-to-end application automation to life.

Agile development and DevOps both require immediate infrastructure availability, which is why they’re most commonly associated with cloud computing. Less understood is how the combination of agile, DevOps, and cloud can accelerate business innovation. Each automation stage feeds into the next, which ultimately enables more rapid delivery of application functionality—such as a faster response to a new business opportunity, or a changed business environment.

Preparing to meet the IT challenges of the future requires rework of all aspects of the application lifecycle. It’s not enough to solve one bottleneck. Indeed, addressing one bottleneck without conducting further monitoring to assess throughput almost ensures that overall lifecycle speed will not improve. Expect to see enterprise IT groups conduct iterative process improvement initiatives as they identify and address addition bottlenecks in their application lifecycle.

Application development: Lessons for leaders

  • Application groups that use cloud infrastructure need to upgrade their development and operations practices to ensure they move at the speed of the cloud.
  • The move to agile development is not trivial. It requires both process and tool changes.
  • Once an automated DevOps capability is in place, the organization can roll out changes once a week, once a day, or even once an hour—all with no additional work on the part of operations personnel.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.