PART IV Cloud Programming Paradigms

Chapter 15 DevOps

Introduction
• Previous chapters describe programming paradigms and technologies used in
building and running software in the cloud.

• This chapter describes a methodology that teams use to build and deploy
software and explains why it is especially appropriate for cloud software.

Software Creation And Deployment

• Software development starts with a business need. An organization identifies
how their business can benefit from new software. If no commercial software
satisfies the need, the organization uses its staff to create new software. In
theory, after an initial engineering effort, the software remains available
indefinitely, leading to a two-step deployment:

o Step 1. An initial engineering effort creates, tests, and

deploys a new piece of software, making it available for
use

o Step 2. Authorized users invoke the software as needed,

possibly over a span of many years

The Realistic Software Development Cycle

• In practice, the simplistic two-step deployment described above only
suffices for the most trivial computer programs because large, complex
pieces of code contain errors despite the best efforts of software engineers.
Hence, when an error is discovered, software engineers must change the code
to correct the error and then deploy the new version.

• Other factors may also require software to be changed such as updates to

the underlying operating system and/or libraries.

• Even if the OS does not change, users may suggest new features, extensions,
or other changes to improve the program.

• Hence, a software development process involves continual update which is

commonly known as the software development cycle.
Figure 15.1 The concept of a software development cycle in which the discovery of errors or
ideas for extensions and other changes require the software to be revised.

Large Software Projects And Teams

• Building and deploying a large software project is complex and involves a
wide range of expertise typically involving multiple teams, each focusing on
one aspect. Most organizations divide the effort into three basic teams:

o Development team - Software engineers who start with a list of

requirements, create a design, specify all the pieces, choose a
programming language (or languages) and programming tools, and
write the code.

o Quality Assurance (QA) team - Before new software can be

released to users, extensive testing must be performed to ensure the
software fulfills the requirements and works correctly.

o Operations team - Handles deployment, including configuring the

set of users authorized to use the software, network addresses, and
related details. The operations team also has responsibility for
monitoring the execution, restarting after failure, planning backups,
and creating multiple instances to handle scale.

Disadvantages Of Using Multiple Teams

• Dividing the effort among multiple teams has the advantage of allowing each
team to focus its effort and expertise on one aspect of software production.
However, the separate team approach has disadvantages, including:

o Conflicting management objectives - Each team manager sets

objectives and rewards for their team, and the rewards may differ.

o Competition and finger pointing - The division into tasks

inevitably leads to competition among teams and a tendency to blame
other teams when problems occur.
 o Long development cycle. Using a separate team for each part of the
software project means each team waits until its task has been
completed before passing the project on to the next team. With no
overlap among teams, the total time from start to full operation can
be months resulting in a big bang (i.e., a major release) rather than a
set of small, incremental improvements.

• The traditional approach to software development in which a team

completes its task before passing the project on to the next team can
result in a long delay between a change being initiated and the
deployment of a new version of software that incorporates the change.

The DevOps Approach

• The Agile methodology focuses on self-organizing teams that work closely
with users during planning and development, flexible and rapid responses
to changes, continual and incremental software creation and improvement,
and early delivery of software, even before all features are available.

• The DevOps methodology adopts and extends the Agile approach. Instead
of merely concentrating on building software applications that will be sold
to customers who run them, DevOps focuses on software that will be
deployed and managed by a local Operations team.

• DevOps squeezes the traditional teams (Development, Quality Assurance,

and Operations) into a coordinated effort that works on all aspects of
planning, building, testing, deploying, and operating software systems.

• Including the Operations team in the software creation process helps

ensure that the resulting software can be managed.

Continuous Integration (CI): A Short Change Cycle

• In a traditional software process, a long update time encourages developers
to collect as many changes as possible into each release resulting in extended
time between releases. Industry uses the term major release to characterize
a new version of the software that incorporates many changes.

• Like the Agile methodology, DevOps espouses a philosophy of Continuous

Integration (CI) in which the development team makes small changes in the
software continuously rather than waiting to collect changes into a major
release. Two ideas help make continual integration efficient and effective:

o Use of automated development tools - Automated development

tools reduce the time required for development by automatically
building a new version of the program whenever a programmer
changes a piece of the code. Tools also manage versions to keep
work-in-progress separate from the current production version.
 o Continual testing of small pieces. To achieve high quality, changes
must be tested before new versions of software can be placed into
production. To accelerate the software development cycle,
DevOps divides software into small pieces that can be changed and
tested quickly.

Continuous Delivery (CD): Deploying Versions Rapidly

• In a traditional software development process, the Operations team writes
new code, place the code in a source repository, and builds a new version of
the program. To implement the change from one version to another, the team
must terminate the old version before making the new version available. This
must be scheduled in advance and users are typically warned of a new release,
allowing them to plan for the change.

• The idea of scheduling a time for each major release does not work well in a
cloud environment. For example, halting all instances of a microservice
before a new release can be deployed may be inconvenient or impossible.

• Cloud software uses containers that, after handling a request, disappear

quickly. Hence, an operations team let old instances of the software continue
until they exit, and phase in the new version by using it for new instances.

• By breaking software into smaller pieces, the microservices approach makes

testing easier and faster. As it has fewer parameters, a module can be
changed, tested, and deployed rapidly; the approach works well for SaaS
services because the SaaS vendor controls the release of new versions.

Cautious Deployment: Sandbox, Canary, And Blue/Green

• Typically, an organization does not merely deploy the new version into
production. Instead, they may choose deployment strategies, such as:

o Sandbox trial – Involves creating a separate copy of the production

environment for a trial deployment. Deployed in this sandbox
environment, the copy is isolated from the production environment
so new modules can be tested to see that they interact correctly with
other modules without any risk to the production system.
Duplication means the sandbox approach incurs high cost. Isolation
from the production environment may mean a sandbox trial may not
catch all errors.

o Canary deployment – This approach overcomes some of the

disadvantages of the sandbox approach. Canary does not use a
separate environment for testing. Instead most users continue using
the old software, and a few canary users are switched to the new
version. Once the canary deployment succeeds, all users are
switched to the new version.
 o Blue/Green deployment – This approach divides the production
environment into two parts, known as blue and green. The blue part
is reserved for testing the new version, while the green part continues
to run the old version. Once testing completes, the two parts are
reversed, with the blue version becoming the production version, and
the green version used to test the next version.

• Because it involves many details and requires rapid reactions when

problems arise, continuous deployment requires a separate tool to
manage versions, testing, and trial deployments, and to roll back to a
previous version if a problem arises.

Difficult Aspects Of The DevOps Approach

• Although it offers the advantages of rapid and continuous integration and
deployment, DevOps has downsides, including:

o Change of culture and rewards - Instead of separate teams and

separate management for development, testing, and operations,
DevOps requires the groups to work together. Instead of rewarding
competition, DevOps rewards cooperation.

o Higher risk resulting from rapid deployment - Any approach that

emphasizes rapid deployment of new software versions increases the
risk of introducing problems. One approach to manage risk involves
introducing additions and support functions the new version will
need, and then making the changes to use the support functions.

o System-wide failures as opposed to module failures. To enable rapid

deployment of new versions, DevOps (and Agile) focus on testing small
modules. However, the interactions among modules is more difficult to test
and can cause a system to fail even if all modules perform correctly. For
example, a deadlock can occur if modules have circular dependencies.

Summary
• The traditional software engineering paradigm collects many changes into
each version of software, and then schedules a major release that puts the new
version into production. Traditionally, software production uses three
separate teams for development, testing, and operations. The traditional
approach does not work well in a cloud environment because it is difficult
to schedule a time to stop all instances and switch to a new version.

• To speed the software cycle, the DevOps approach divides software into
small modules that can be tested quickly and combines testing with
development. To ensure that the resulting software can be deployed and
managed, DevOps integrates the operations team with the development and
testing teams. DevOps strives for continuous integration, allowing changes
and improvements to occur quickly and continually.
• Rather than collecting changes into major releases, DevOps strives for
continuous deployment of new versions that each contain a minor change.
Several techniques enable continuous deployment.

o The sandbox approach uses a separate copy of the environment for

testing.

o The canary approach divides the production environment into two

pieces and allows a few users to try the new version while other
users continue with the old version.

o The blue/green approach divides the production into two parts, using
one to test the new version and another to run the old version. Once
the new version has been tested thoroughly, all users move to the new
version until a next version has been created.

• Continuous deployment involves many details, including directing each user

to an instance of the correct version and automatically rolling back to a
previous version if a new version causes problems. Consequently, a separate
tool may be needed to manage the deployment of new versions.

• Despite its advantages, DevOps has downsides. It requires a complete

change of the work culture and reward system, has higher risk of problems
resulting from the rapid deployment of new versions, and the emphasis on
smaller modules makes it more difficult to assess system-wide failures that
occur from interactions among modules.