DevOps_Automation White Paper

Copyright © 2015 Chef Software, Inc.
http://www.chef.io 7/2015

1
Executive Summary
The advent of the digital economy has fundamentally changed consumption patterns.
Today’s customers are accustomed to goods and services that are available online
anytime, anywhere and from any type of device. To satisfy these new expectations,
every enterprise must transform the way it does business or risk obsolescence. En-
terprise IT, once considered a back office support function, must become the front
office connection to customers and the linchpin of a mission-critical transformation.
Innovative companies such as Amazon, Google, and Facebook have set the
pattern for this transformation. These innovators, along with an active community of
web practitioners, have developed a workflow and set of practices, encapsulated by
the term DevOps, that brought about many technical and cultural changes to IT and
resulted in infrastructures and applications that were extraordinarily fast and scalable.
The hallmarks of a DevOps workflow are velocity, consistency, scale and the
ability to incorporate feedback.
Automation
and DevOps
DevOps is at the heart of becoming a software-led company, and it is no longer
for the select few. DevOps is becoming the norm for businesses of all kinds.
However, established enterprises have a challenge that the DevOps innovators
did not. They have legacy workloads and regulatory requirements to consider.
Migrating these workloads to a flexible technology stack must be done in a way that
reduces risk, ensures stability and guarantees regulatory compliance.
This paper focuses on the technical attributes of a DevOps workflow and
explains why choosing the right automation platform is critical to every business’s
journey toward DevOps.
VELOCITY CONSISTENCY SCALE FEEDBACK

2 AUTOMATION AND DEVOPS
Every Business Is Software
Every business is a software business, no matter what industry it’s in. Customers,
whether outside the corporate firewall or behind it, have higher expectations for
speed, reliability, and personalized content. They expect fast response times and
great customer service.
These expectations exist because innovative online companies such as
Amazon, Google, and Facebook constantly raise consumer expectations. Any busi-
ness that wants to remain competitive must emulate the patterns developed by the
web innovators, which are summarized by the term DevOps. Following DevOps
patterns allows companies to quickly respond to customer demands with the soft-
ware that provides the experience customers want.
Fast response to consumer demand requires a technology stack that can react
quickly to changing business needs while maintaining its resiliency and reliability, and
it requires the ability to deliver new application features just as quickly.
Deﬁning DevOps
DevOps innovators discovered that to promote agility and speed, IT and development
must work together to build a technology stack that can safely support rapid deploy-
ments and dynamic workloads.
These innovators combined software developers and IT professionals into uni-
fied teams aligned around shared business goals. These teams use a workflow that
relies, technologically, on automation and socially, on collaboration.
With these two emphases, DevOps has made it possible for companies to de-
velop infrastructure and apps that respond quickly to change while remaining stable
and reliable.The process also enables much faster and more reliable delivery of new
application features. The DevOps workflow is disrupting much of the conventional
thinking that has shaped IT operations in the past.
Staff
Complexity
Number of
servers
Time to
market
Dimensions
of Scale
DevOps Patterns
One of the goals of DevOps is to create a compute environment that supports rapid
deployment, and has the ability to react swiftly and effectively to changes in business
requirements.These attributes scale even as the overall system becomes larger and
more complex.
There are some general patterns that characterize how DevOps practitioners
operate. Here are some of the patterns.

AUTOMATION AND DEVOPS 3
DevOps practitioners focus on the digital customer experience. All the technol-
ogy they invest in and the innovations they create are a means for delivering a great
customer experience.These customers can exist either
outside or inside of the firewall. For example, a retail
business has customers outside the firewall who buy its
products. Any business might have customers within
the firewall. For example, developers might want to be able to order the environments
they need by selecting them from a service catalog.
DevOps practitioners collect data. Web innovators are great believers in data and
collect it on everything they can as often as they can. They improve their processes
based on evidence provided by the data they collect. The data helps them under-
stand what’s working and what isn’t.
DevOps practitioners invest in technical innovation. Successful online compa-
nies encourage innovation, and the investments don’t have to be large.
Intuit is a great example of a company that encourages innovation. Intuit gives
employees 10% of their hours as unstructured time. The legal department created a
tool kit that lets product managers try new business ideas without needing to talk to
legal. Intuit’s IT department leveraged a DevOps workflow to accelerate the setup
time for test environments for new web products from two months to two hours.2
DevOps practitioners use open source software and dynamic infrastructure. A
reliance on open-source software is typical in DevOps environments. The use of
open-source software and commodity hardware create a technology stack that can
be completely controlled and customized.
DevOps practitioners also rely on dynamic infrastructure where resources are
provided on demand to the company’s business units, with service-level agreements
that guarantee some level of quality in areas such as availability, performance and
security. Individual departments needn’t be responsible for planning capacity;
instead, capacity planning occurs at the corporate level and is aligned to the needs
of the business.
The incentive to use open source software and commodity hardware, and to
provide infrastructure as a service (IaaS) is not necessarily cost—it’s the ability to
customize and control the technology stacks and respond quickly to business needs.
DevOps practitioners tend to use service-oriented architectures. Factoring ap-
plications into stable, independent services that use web protocols and associated
architectural patterns is very common in the DevOps world. Each service can be
independently implemented, deployed, and scaled. As a result, teams become
aligned to business functions rather than divided into silos that isolate technical spe-
cialties from each other and put drag on the ability to deliver value.
DevOps practitioners improve through multiple iterations. Amazon, Google and
Facebook don’t wait until they’ve built what they think is the perfect product only to
find out that what they’ve done isn’t what the customer wants. Instead, they start with
a minimal implementation and build it incrementally. They use A/B testing to find out
what works and what doesn’t. In 2011, Google ran more than 7,000 A/B tests on its
search algorithm.Amazon.com, Netflix, and eBay are also A/B advocates, constant-
ly testing potential site changes on live users.3
DevOps practitioners avoid silos through transparency. Silos are not just orga-
nizational divisions but informational ones as well. For example, devs know all about
the code in their applications but don’t understand the production environment in
which it will run. Operations knows little about the application and everything about
the company’s infrastructure and release environment, which may not match what
the devs use. The consequence is a release process that’s slow and painful. When
the two groups share information, the release process is much more efficient.
We start with the customer and work backwards.1
– Jeff Bezos, Amazon.com

When Nordstrom used DevOps principles to build a continuous delivery pipeline,
they put developers, web site operations engineers, QA engineers, and configuration
management together to form a single team. The team combined expertise across
multiple technical disciplines and retained focus and accountability by holding week-
ly demos. The end result of all that transparency is that now people all over the
company, even people in the finance department, email senior vice presidents, ask-
ing how can they help with continuous delivery.4
Increased communication has many obvious benefits. Within a team, members
quickly learn about proposed changes and any problems that exist. Involving a
number of different stakeholders, such as product managers, members of the sales
force, and consulting can bring in valuable information from areas outside the team
members’ areas of expertise. Making information available to everyone in the com-
pany gives employees a sense of ownership and participation.
DevOps practitioners deploy software very quickly. Part of the reason DevOps
teams move so quickly comes from their belief that failure is expected in a culture
that innovates and moves rapidly. However, they don’t want to fail after having spent
months on a product. Instead, they use a very fast stream of incremental releases so
that, when there is a failure, it’s easy to correct and their investment is small. Again,
a flexible, managed infrastructure allows them to quickly put together prototypes and
test them.
DevOps practitioners build compliance into the software deployment pipeline.
Instead of being tacked on at the end of the production process, compliance is
embedded into the software production line. Compliance at velocity uses extensive
automation to increase velocity and accuracy.
For example, GE Capital (GEC) realized that, to remain competitive, it needed
to streamline the way it developed, delivered and maintained software. At the same
time, GEC operates in a highly regulated environment and is obligated to comply with
many requirements. GEC’s challenge was one
that many large enterprises face: How do you
remain compliant and still operate at velocity?
For GEC, the answer was DevOps. To en-
sure that compliance was an integral part of
this new software delivery process, they
brought the regulatory, compliance gover-
nance, and security teams in early to take toll-
gates out and get rid of manual processes so
they could deliver at velocity and at the same
time remain compliant and secure.5
DevOps practitioners use version control. Version control systems give transpar-
ency to all aspects of orchestration, configuration and deployment. With version
control team members can review the history of all change sets at any time.
DevOps practitioners use automation. An automation platform gives you the abil-
ity to describe your entire technology stack as executable code. DevOps practitioners
use automation to create a workflow that :
• Eliminates error-prone, time-consuming manual tasks.
• Standardizes development, test and production environments.
• Builds automated release pipelines.
• Improve cooperation between development and operations.
Automation solves immediate problems, such as repetitive configuration tasks
and also gives you the power to create and manage a technology stack that meets
the demands of today’s digital economy. With automation, you can move from infra-
structure that is inconsistent and static to one that is consistent and elastic.
“Steve Blank and Eric Ries, both serial entrepreneurs,
have studied what allows businesses such as Google to
succeed in today’s quickly changing world. They found
that…the companies that succeed in dynamic market-
places are those that rapidly develop products with
minimal planning and commitment of resources.”6

What is Automation?
Automation is a necessity for building a DevOps workflow. Using an automation
platform gives you immediate access to the same patterns of success that the web
innovators had to develop themselves.
When you automate your technology stack, you describe all the tasks you want
to perform as executable code. For example, here’s how you can use the Chef
automation platform to install an Apache package and run it as a service on a RHEL
or CentOS server.
package 'httpd'
service 'httpd' do
action [:enable, :start]
end
This code installs the Apache package, called httpd, starts the service and
enables it when the server boots.
If you’re not using an automation platform, you might perform this task by hand.
If it’s a manual task, imagine what it would be like if you had to do the same proce-
dure for 50 servers, 500 servers or even 50,000 servers.With automation, you simply
run the code once and all the servers are configured.
You might try an approach based on scripting, but automation platforms are or-
ders of magnitude better than isolated scripts. Platforms like Chef take care of many
of the complexities of configuring a server for you. Also, automation platforms can
give you a global view of your network, which is important when accounting for
dependencies between network components, while scripts can only give you a
piecemeal view.
Finally, consider the other advantages of describing your technology stack as
code.The same practices you follow to ensure the quality and manageability of your
applications can now be applied to your infrastructure and all of the services in the
stack. Once encoded, you can store the stack in version control and you can test it.
If you lose part of your stack or even all of it, you can recreate it by rerunning the code
that describes it.
Workstation Source Control
System
Automation Server
Nodes
Policy
State

Beneﬁts of automation
Automation enables velocity, scale, consistency and feedback.All of these qualities
are of a piece.Any one depends on the other two three—for example, you can’t scale
unless you are able to quickly add servers with consistent configurations. You can’t
get feedback automatically without being able to support different real-time testing
techniques.
VELOCITY
Automation increases velocity in many ways. Simply replacing manual procedures
with automated ones makes infrastructure management more efficient. However, as
your use of automation becomes more sophisticated, you’ll find that you’ll markedly
increase your deployment rate and the ease with which you manage all your resourc-
es, both on-premises and in the cloud. Automation makes techniques such as A/B
testing possible. You can quickly find out what works for your customers before in-
vesting huge amounts of time and money. Quick response to changing business
needs is essential.
SCALE
Automation allows you to scale up (or down) in response to demand. Automation is
a critical component of any strategy that requires dynamic provisioning of infrastructure
at scale. Automation enables elastic scale, whether you’re operating on-premises,
in the public cloud, or in a hybrid environment.
CONSISTENCY
Automation ensures consistency across your network. Consistency means confor-
mance to your business’s policies. An automation platform checks to make sure that
each server is within policy and corrects it if it isn’t. In other words, a good automation
platform must make it easy to prevent configuration drift over time.
Consistency makes infrastructure more robust and reduces risk in many ways.
The immediate benefit is that you have a standardized process for provisioning serv-
ers. Once you’ve expressed your infrastructure as code, you can test it to make sure
it performs as you intended. You can also save it in version control. You’ll be able
to keep track of changes and, if one version doesn’t do what you thought, you can
rollback to the previous one.
A consistent environment makes it much
easier to migrate applications to the cloud.
Consistency gives you control and control
reduces risk. With automation, moving lega-
cy applications to the cloud is an orderly
process.
Another advantage is that, because
your infrastructure is code, you can always
recover it. Even if disaster strikes you can
recreate your entire infrastructure, from the
bare metal up.
AUTOMATION ENABLES A DEVOPS WORKFLOW
By its nature, automation discourages silos that isolate one group from another and
bog down processes. To take full advantage of the cloud, you use automation to
quickly spin up resources and configure the entire stack. Scale up, down or horizon-
tally by running a program that provisions and configures your network in minutes,
not weeks. Because the process is automated, you know the results will be consis-
tent from one run to the next. Everyone on the team uses the same process to spin
up a stack. There are none of the organizational divisions, handoffs or conflicting
procedures that cause delays and errors.
When you represent [infrastructure] in code, you can
version that code, and you can say, “This is what the
machine looks like today and this is what it looked like
last week, and this is when somebody changed it.”
When you have that, you can almost print these new
machines like you have a factory press. You just put
the code in and Chef takes care of it. Chef prints out
brand new machines for you, faster than ever.7
—Jamie Winsor, software engineer, Riot Games

Another advantage to automation is that the stack is represented by
human-readable text files. DevOps encourages transparency. Describing the stack
as code means that it is accessible and readable to everyone on the team. In addi-
tion, you can keep these files in a source control system, where they are versioned
and kept safe.All the advantages of using a source control system with your applica-
tion code apply equally to the code that describes the rest of the stack. Examining
differences between versions of your configuration recipes shows exactly what
has changed since the previous known stable state of the system. Such visibility is
critically important.
The following illustration summarizes the relationship between automation and
DevOps.
As the illustration shows, DevOps has a critical dependence on infrastructure as
code.
Requirements for a DevOps
automation platform
To provide the foundation for building and managing infrastructures according to
the principles of DevOps, a good automation platform has these essential character-
istics:
• It creates a dependable view of your entire network’s state.
• It can handle complex dependencies among the nodes of your network.
• It is fault tolerant.
• It is secure.
• It can handle multiple platforms such as RHEL, Ubuntu and Windows
Server, as well as legacy systems.
• It can manage cloud resources.
• It provides a foundation for innovation.
Let’s examine these points in more detail.
begins with needs
just
like
version infrastructure
code
create infrastructure
consistently
test automatically

Implementing distributed coordination requires specialized techniques that take
a holistic view of the network. It’s more than just running scripts.
A good automation platform will allow the network to converge to its desired
state over time and provide search-based configuration that allows nodes to query
the automation platform for information about other nodes in the network. This is
sometimes called policy-based convergence.
Is scalable
Infrastructures tend to become larger and more complex over time. To ensure scal-
ability, a good automation platform will have a distributed, rather than a centralized
architecture. With a centralized architecture, most of the work occurs on the server,
which can become a bottleneck as networks grow.With a distributed architecture, the
work occurs on the nodes, and a node only has to take care of its own configuration.
Is fault tolerant
A good automation platform is able to recover when network connections go offline
or when a system needs to be rebooted. It should also be able to handle errors and
unexpected conditions.
Is secure
A good automation platform ensures that communications between the server and
the nodes are secure. It enables granular control over who can access different
resources. Additionally, it allows you to control security on particular nodes.
Creates a dependable view of your network
A good automation platform knows the state of your entire network at any given time.
You need a global view of your network. Scripts can’t provide this capability.
Can handle complex interdependencies
Most infrastructures have many dependencies between servers. For example, a load
balancer needs to know when a new application server is available. Isolated scripts
can’t handle complex dependencies that require distributed coordination.

Can handle multiple platforms
Many infrastructures include multiple operating systems. For example, there may be
Windows, AIX and Linux machines in the same network.A good automation platform
supports heterogeneous networks.
Can handle legacy systems
Most infrastructures include legacy systems that don’t fit any standard configuration
model. An automation platform should be extensible and not just a set of fixed
capabilities.
Can manage cloud computing environments
Are you already in the cloud or considering the advantages of migrating some of your
applications there? You need the same capabilities for managing cloud resources as
for your on-premises resources. A good automation platform is cloud capable and
provides the structure and consistency needed to make moving legacy workloads to
the cloud a low-risk operation.
Provides a foundation for innovation
A good automation platform lets you plan for the future. Even if you’re automating
basic configuration tasks now, what do you want to be doing a year from now, or five
years from now? You need an automation platform that can handle everything from
configuring a server to building a continuous delivery pipeline. In other words, you
need a platform that won’t limit you as you grow.
Why Chef?
Chef8
is the automation solution for creating a
DevOps workflow. Chef was born with the DevOps
movement, and experience with DevOps thinking
and best practices have been distilled into every
aspect of Chef.
Only Chef is a dynamic, policy-based auto-
mation platform that securely distributes intelli-
gence across the entire network. What does this
mean? It means that
• Chef has a unique ability to scale, from
start-ups to Facebook to GE.
• Chef has a unique ability to ensure consistency in complex, highly dynamic
environments.
• Chef is fault tolerant.
• Chef grows with you. When it comes to solving configuration and automation
challenges, Chef makes the easy things easy and the hard things possible.
Chef distributes intelligence across the network
Chef is constructed so that most of the computational effort occurs on the nodes
themselves rather than on the Chef server. In this highly distributed architecture, the
Chef server acts as a trusted repository that stores policies and data about the state
of the network. It doesn’t configure the nodes. Instead, it simply sends them the
instructions they should follow.
Code has … given us a single way to communicate.
Before we had different groups operating with different
tools, and different mindsets in how they approached
things. By distilling it all down to code, we’re able to
leverage the same practices among different groups.
It allows us to be more agile, move faster and respond
when the business needs us to respond.11
—Rob Cummings, Infrastructure Engineer, Nordstrom

If Chef were a centralized system, then the Chef server would be responsible for
ensuring that all the nodes were in compliance. Given how infrastructures can grow,
both in scale and complexity, a centralized server can quickly become a bottleneck.
Chef is the only automation platform that uses a fully distributed approach, and this
has some implications that make it uniquely suited for web-scale IT.
Chef is highly scalable
Chef’s unique ability to scale is one of the reasons
Facebook uses Chef for its production systems.
Such a high level of scalability would simply not be
possible if Chef did not distribute most of the work
to the nodes.
Chef can handle complex, highly
dynamic environments
Chef has a unique ability to ensure consistency in complex, highly dynamic environ-
ments. This is a weak spot of a centralized approach where a server blocks while
waiting for a response from a node, or of a distributed approach where logic executes
on the server.
Here are some examples of how Chef handles these types of environments.
BIDIRECTIONAL DEPENDENCIES
If a network uses database replicas, each replica must know about the others in
order to remain in sync. Symmetric dependencies such as these create a sequencing
problem that can only be solved by using policy-based convergence. Full configura-
tion doesn’t occur in a single step, but the network as a whole eventually converges
to its desired state.
It can take several iterations for a server to comply with policy. (An iteration
occurs when a node and the server communicate with each other to see if the node
There are three dimensions of scale we generally look
at for infrastructure – the number of servers, the num-
ber of different configurations across those systems,
and the number of people required to maintain those
configurations. Chef provided an automation solution
flexible enough to bend to our scale dynamics without
requiring us to change our workflow.9
—Phil Dibowitz, Production Engineer at Facebook
Chef Server
Node
Policy
Request current policy
Policy and network state
Current node state
State
With Chef, the intelligence about the desired state of the network is distributed
across the network itself. Each node of the network periodically executes the current
instructions from the Chef server. This iterative process ensures that the network as
a whole converges to the state envisioned by business policy.

is compliant.) Full compliance may not occur in a single iteration. Even in complex
situations, with many dependencies, Chef ensures that the network as a whole
continually moves closer to the state defined by business policy.
REBOOTS AND NETWORK RESETS
Centralized approaches that rely on long-lived network connections break down
when the networking service goes offline or the system needs to be rebooted as a
part of the requested operation. A more distributed approach, where the node itself
initiates contact with the server, allows the node to update state after coming back
online. The Chef server can orchestrate a complex series of operations, even when
nodes under management require network resets or must reboot as part of the pro-
cess.
CHEF IS FAULT TOLERANT
When intelligence is distributed to the nodes, appropriate recovery measures can be
taken when an error or unexpected condition occurs. It is more difficult for a central-
ized server to respond in this case.
Test-driven infrastructure
When your infrastructure is described as code, you can treat that code just as you
would your application source code. For example, do you have unit tests for your
applications that are initiated automatically whenever there is a check-in to your
version control system? You can now do the same with your configuration code.
With automated testing, you will catch problems earlier, before they impact your
release cycle. The earlier you catch a problem, the easier and less expensive it is to
fix, and this is why testing is such an important part of DevOps practice.
The V-diagram, common in software engineering, illustrates this.
Architecture
design
Acceptance
testing
Component
design
Integration
testing
Coding Unit
testing
As you can see, each kind of testing activity (on the right side of the V) checks
a particular phase of development (shown on the left side). The cost of rework rises
as defects are discovered later in the project. It’s better to begin testing at the vertex
of the V, with unit tests. Catching a bug during a unit test is much easier than trying
to fix it when it’s being tested with other components that might make it difficult to
discover where the actual problem lies.
The practice of automatically testing your configuration code is called test-driven
infrastructure.Testing the code that provisions and configures your infrastructure has
the same benefits as testing your application code. You’ll find errors earlier, which
means they’ll be easier (and less expensive) to fix. You’ll also have confidence that
your infrastructure is behaving as it should. A major consequence is that problems
with your infrastructure won’t delay your deployments.
Chef has a strong commitment to test-driven infrastructure as part of the DevOps
workflow. In fact, it is the only company that provides commercial support for a full
suite of tools for test-driven infrastructure.

Create new
skeleton
cookbook
Create a VM
environment
for cookbook
development
Write/debug
cookbook
recipes
(iterative step)
Perform
acceptance
tests
Deploy to
production
When you install Chef, you get a set of tools
that support automated testing. For example, the
tool called foodcritic is a static analysis tool that
checks that your Chef cookbooks are syntacti-
cally correct. The tool called chefspec lets you
unit test your Chef code. Unit tests check small
pieces of code in isolation and ensure that they
do what they should.
The following workflow shows how you can
use the different tools Chef provides to test your
code at all stages of development.
Chef Handles Diverse Environments
Chef has other advantages that make it the automation platform for DevOps.
Chef is secure on every type of network
Chef uses SSL to ensure that a Chef server responds only to requests made
by trusted users. When a node is configured to run the Chef client, bidirectional
validation of identity occurs between the Chef server and the newly added node.
This makes Chef suitable for managing nodes on every type of network, even public
networks.
Chef supports multiple
platforms and legacy systems
Chef supports many flavors of Linux and Unix,
as well as Windows Server. For example, Chef
includes support for Microsoft’s Desired State
Configuration (DSC) PowerShell extension.
Chef also supports containers. With Chef, engi-
neers can use the same skill set to manage
every platform in your network.
Chef comes with a large number of pre-de-
fined building blocks, called resources, which describe pieces of infrastructure, such
as files, templates, and packages. The Chef community has also written many col-
lections of configuration instructions called cookbooks, which cover many situations.
However, if you need to write your own configuration steps for a particular
system, you can do it with Chef. Chef uses the Ruby programming language, which
means it isn’t constrained by a limited domain-specific language. You have the
flexibility you need to describe any piece of infrastructure you have.
By bringing in Chef, we were able to automate a
very heterogeneous infrastructure that included
both legacy and new applications and we were
able to open up some interesting career paths for
our engineers. We have hardcore UNIX engineers
now happily automating Windows infrastructure
because they can do it through code.12
—Rob Cummings, Infrastructure Engineer, Nordstrom
We’re looking at cloud architecture. We’re looking at
public cloud, we’re looking at private cloud. We want
to do some completely different things that we haven’t
been able to do before. The only reason that I’m able to
consider those is because of what we did with Chef. It’s
now opened a completely new capability that I hadn’t
foreseen. I view Chef as the tool that has had the single
biggest impact in our transformation.10
—John Esser, Director of Engineering Productivity
and Agile Development, Ancestry.com

Chef can manage cloud resources
If you’re already in the cloud or thinking about moving some servers there, Chef has
proven to be a great way to manage your resources. For example, Splunk uses Chef
to manage its cloud offering, Splunk Storm. Cycle Computing uses Chef to manage
tens of thousands of nodes. A large percentage of customers use Chef to automate
and manage cloud resources.
Summary
No matter what your plans are for your company, Chef can help you create and main-
tain the infrastructure that will make those plans possible. Chef gives you end-to-end
control over application deployment, beginning with the developer laptop and ending
with the production servers. Chef’s scalability
means that no matter how large and complex
your network becomes, Chef can handle it.
Chef’s flexibility means that you can describe any
configuration you have.
Companies such as Intuit, Nordstrom, and
Disney use Chef to spur innovation, create new
offerings, and speed deployments.
Here are the key points of this paper.
• Web innovators such as Amazon, Google, Facebook and others have set
customer expectations for what the digital experience should be. These
customers can be either outside or inside the firewall.
• Any company that wants to remain competitive must follow the lead set
by the web innovators, who have redefined the customer experience.
• To provide a fast, responsive, personalized experience to their customers,
web innovators have adopted a series of practices that, collectively, is
known as DevOps.
• DevOps is for any business that wants to move at velocity.
• The technical foundation of DevOps is automation. There are also important
cultural and organizational aspects of DevOps.
• Automation supports a workflow that provides speed, scale and consistency.
• A good automation platform is scalable, can handle complexity, and has
features that let enterprises plan for the future.
• Chef’s distributed architecture lets it securely scale to any infrastructure,
no matter how large or complex.
• Chef supports multiple platforms, including Windows, AIX, Linux, and
containers.
• Chef is the only automation platform with commercial support for automated
testing tools for IT automation.
• Chef helps you through all aspects of application deployment, beginning
with a developer’s laptop and ending with the production servers.
We can bring up a new database server with one
command. We can bring up a whole Splunk environment
with one command. The amazing story is that Splunk
Storm would not be here today without Chef.13
—Alex Munk, Product Manager at Splunk

Notes
1. http://www.slate.com/articles/news_and_politics/newsmakers/2009/12/we_start_with_the_
customer_and_we_work_backward.html
2. http://www.forbes.com/sites/bruceupbin/2012/09/05/four-ways-intuit-keeps-new-ideas-flowing/
3. http://www.wired.com/2012/04/ff_abtesting/all/
4. https://www.youtube.com/watch?v=Ot5H2KfWAxI
5. http://www.forbes.com/sites/benkepes/2015/04/17/ge-capital-and-its-devops-reinvention/
6. Fail Fast, Fail Often: How Losing Can Make You Win, Ryan Babineaux and John Krumbolz
7. http://www.youtube.com/watch?v=URi4_DLrFxQ
8. http://www.chef.io
9. http://www.youtube.com/watch?v=YA8p65qcD0I
10. http://www.youtube.com/watch?v=5enyC4lyPWE
11. http://www.youtube.com/watch?v=XqFrvYJ6IGc
12. http://www.youtube.com/watch?v=XqFrvYJ6IGc
13. http://www.youtube.com/watch?v=VZEbhiQ0-EI

DevOps_Automation White Paper

More Related Content

What's hot (17)

Similar to DevOps_Automation White Paper (20)

DevOps_Automation White Paper