Figure 13-14 Dev and Ops Calendars
Traditional IT service delivery is slow, manual, and often
prone to errors (see Figure 13-15). The infrastructure is a
shared resource, and one change can have a ripple effect
that could break other unrelated systems. The fragile
nature of the infrastructure makes it very hard to
anticipate issues that can arise. To combat this, many IT
organizations create layers upon layers of approval
processes. While this sounds like a rational way to
protect the business from downtime, the net effect is to
slow new deployments to a crawl. For these reasons and
many others, DevOps was created.
Figure 13-15 Traditional Sequential Approach to
Operations
WHAT IS DEVOPS?
In 2009 two employees from Flickr (an image sharing
site), John Allspaw and Paul Hammond, presented a talk
titled “10+ Deploys per Day: Dev and Ops Cooperation at
Flickr” to a bunch of developers at the O’Reilly Velocity
conference. In this talk, Allspaw and Hammond said that
the only way to build, test, and deploy software is for
development and operations to be integrated together.
The shear audacity of being able to deploy new software
so quickly was the carrot that fueled the launch of the
DevOps concept. Over the years since then, DevOps has
moved from being revered by a small group of zealots
and counterculture types to being a very real and
quantifiable way to operate the machinery of software
creation and release. The vast majority of companies that