This document discusses DevOps, including what it is, why it is used, its history and practices. DevOps combines cultural philosophies and tools to increase an organization's ability to deliver applications and services faster. It involves development and operations teams working together throughout the entire service lifecycle. Key DevOps practices include continuous integration, delivery and deployment; use of microservices; infrastructure as code; monitoring and logging; and communication between teams. The DevOps lifecycle aims to continuously deliver products through automation and monitoring at each stage of development and deployment.

1. Technology Trends
DevOps
What is DevOps ...2
Why DevOps ...2
History of DevOps ...3
DevOps Practices ...3
DevOps Lifecycle ...5
Summary ... 6
December 2016

2. What is DevOps ?
The Problem In A
Nutshell
 Everything needs
software.
 Software runs on a server
to become a service.
 Delivering a service from
inception to its users is
too slow and error-prone.
 There are internal friction
points that make this the
case.
 This loses you money.
(Delay = loss)
2
DevOps is the combination of cultural philosophies, practices, and tools that
increases an organization’s ability to deliver applications and services at high
velocity: evolving and improving products at a faster pace than organizations
using traditional software development and infrastructure management
processes. This speed enables organizations to better serve their customers and
compete more effectively in the market.
Why DevOps ?
Software and the Internet have transformed the world and its industries,
from shopping to entertainment to banking. Software no longer merely
supports a business; rather it becomes an integral component of every part
of a business. Companies interact with their customers through software
delivered as online services or applications and on all sorts of devices. They
also use software to increase operational efficiencies by transforming every
part of the value chain, such as logistics, communications, and operations.
In a similar way that physical goods companies transformed how they
design, build, and deliver products using industrial automation throughout
the 20th century, companies in today’s world must transform how they
build and deliver software.
DevOps is the practice of operations and development engineers participating together in the
entire service lifecycle, from design through the development process to production support.

3. DevOps Practices
3
There are a few key practices that help organizations innovate faster through automating and streamlining the software
development and infrastructure management processes. Most of these practices are accomplished with proper tooling.
One fundamental practice is to perform very frequent but small updates. This is how organizations innovate faster for their
customers. These updates are usually more incremental in nature than the occasional updates performed under traditional
release practices. Frequent but small updates make each deployment less risky. They help teams address bugs faster
because teams can identify the last deployment that caused the error. Although the cadence and size of updates will vary,
organizations using a DevOps model deploy updates much more often than organizations using traditional software
development practices.
Organizations might also use a microservices architecture to make their applications more flexible and enable quicker
innovation. The microservices architecture decouples large, complex systems into simple, independent projects.
Applications are broken into many individual components (services) with each service scoped to a single purpose or function
and operated independently of its peer services and the application as a whole. This architecture reduces the coordination
overhead of updating applications, and when each service is paired with small, agile teams who take ownership of each
service, organizations can move more quickly.
History of DevOps
The DevOps movement started to coalesce some time between 2007 - 2008, when IT operations
and software development communities got vocal about what they felt was a fatal level of
dysfunction in the industry. They railed against the traditional software development model,
which called for those who write the code to be organizationally and functionally apart from
those who deploy and support that code.
Developers and IT/Ops professionals had separate (and often competing) objectives, separate
department leadership, separate key performance indicators by which they were judged, and
often worked on separate floors or even separate buildings. The result was siloed teams
concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers.
You’re using agile methodologies for planning and development, but still struggling to get that
code out the door without a bunch of drama. You’ve heard a few things about DevOps and the
seemingly magical effect it can have on teams and think “I want some of that magic.”
The bad news is that DevOps isn’t magic, and transformations don’t happen overnight. The good
news is that you don’t have to wait for upper management to roll out a large-scale initiative. By
understanding the pillars of DevOps and making small, incremental changes, your team can
embark on the DevOps journey right away. Let’s start with the CALMS framework.
“But,” you might ask, “how is
the DevOps Lifecycle
different?” It can be summed
up with the acronym C.A.L.M.S.
 C – Culture
 A – Automation
 L – Lean
 M – Measurement
 S – Sharing

4. 4
Continuous Integration
Developers regularly merge their code changes into a central repository, after which automated builds and
tests are run. The key goals of continuous integration are to find and address bugs quicker, improve software
quality, and reduce the time it takes to validate and release new software updates.
Continuous Delivery
Code changes are automatically built, tested, and prepared for a release to production. It expands upon
continuous integration by deploying all code changes to a testing environment and/or a production
environment after the build stage. When continuous delivery is implemented properly, developers will always
have a deployment-ready build artifact that has passed through a standardized test process.
Microservices
Build a single application as a set of small services. Each service runs in its own process and communicates
with other services through a well-defined interface using a lightweight mechanism, typically an HTTP-based
application programming interface (API). Microservices are built around business capabilities; each service is
scoped to a single purpose. You can use different frameworks or programming languages to write
microservices and deploy them independently, as a single service, or as a group of services.
Infrastructure is provisioned and managed using code and software development techniques, such as version
control and continuous integration. The cloud’s API-driven model enables developers and system
administrators to interact with infrastructure programmatically, and at scale, instead of needing to manually
set up and configure resources. Thus, engineers can interface with infrastructure using code-based tools and
treat infrastructure in a manner similar to how they treat application code. Because they are defined by code,
infrastructure and servers can quickly be deployed using standardized patterns, updated with the latest
patches and versions, or duplicated in repeatable ways.
Infrastructure as Code
Communication and Collaboration
Organizations monitor metrics and logs to see how application and infrastructure performance impacts the
experience of their product’s end user. By capturing, categorizing, and then analyzing data and logs
generated by applications and infrastructure, organizations understand how changes or updates impact
users, shedding insights into the root causes of problems or unexpected changes. Active monitoring
becomes increasingly important as services must be available 24/7 and as application and infrastructure
update frequency increases. Creating alerts or performing real-time analysis of this data also helps
organizations more proactively monitor their services.
Monitoring and Logging
Increased communication and collaboration in an organization is one of the key cultural aspects of DevOps.
The use of DevOps tooling and automation of the software delivery process establishes collaboration by
physically bringing together the workflows and responsibilities of development and operations. Building on
top of that, these teams set strong cultural norms around information sharing and facilitating
communication through the use of chat applications, issue or project tracking systems, and wikis. This helps
speed up communication across developers, operations, and even other teams like marketing or sales,
allowing all parts of the organization to align more closely on goals and projects.

5. 5
Together, these practices
help organizations deliver
faster, more reliable
updates to their customers.
Here is an overviewof
important DevOps
practices.
Utilizing a DevOps lifecycle,
products can be continuously
deployed in a feedback loop
through:
 Infrastructure Automation
 Configuration Management
 Deployment Automation
 Infrastructure Monitoring
 Log Management
 Application and Performance
Management
Technical benefits:
Continuous software delivery
Less complex problems to fix
Faster resolution of problems
Business benefits:
Faster delivery of features
More stable operating
environments
More time available to add value
(rather than fix/maintain)
The DevOps Lifecycle Looks Like
1. Check in code
2. Pull code changes for build
3. Run tests (continuous integration server to generate builds and arrange
releases): Test individual models, run integration tests, and run user acceptance
tests.
4. Store artifacts and build repository (repository for storing artifacts, results,
and releases)
5. Deploy and release (release automation product to deploy apps)
6. Configure environment
7. Update databases
8. Update apps
9. Push to users – who receive tested app updates frequently and without
interruption
10. Application and Network Performance Monitoring (preventive safeguard)
Rinse and repeat
What are DevOps Skills
Our respondents identified the top three skill areas for DevOps staff:
 Coding or scripting
 Process re-engineering
 Communicating and collaborating with others
These skills all point to a growing recognition that software isn’t written in the old
way anymore. Where software used to be written from scratch in a highly complex
and lengthy process, creating new products is now often a matter of choosing open
source components and stitching them together with code. The complexity of
today’s software lies less in the authoring, and more in ensuring that the new
software will work across a diverse set of operating systems and platforms right
away. Likewise, testing and deployment are now done much more frequently. That
is, they can be more frequent — if developers communicate early and regularly
with the operations team, and if ops people bring their knowledge of the
production environment to design of testing and staging environments.
DevOps is also characterized by operations staff making use many of
the same techniques as developers for their systems work.

6. 6
Summary
DevOps isn't a tool or a product. It's an approach to operations. By uniting development and operations teams
to automate and standardize processes for infrastructure deployment, you get faster innovation, accelerated
time to market, improved deployment quality, better operational efficiency, and more time to focus on your
core business goals.
 Faster release of apps with automation of integrated build, test and deployment process
 Increase developer and operational efficiency by managing your infrastructure as code
 Improve customer experience with immediate feedback loops and continuous improvement
DevOps Values believe the fundamental DevOps values are effectively captured in the Agile
Manifesto with perhaps one slight emendation to focus on the overall service or software
fully delivered to the customer instead of simply “working software.”
References:
Gartner,IDC, Amazon, Wikipedia, HP, Microsoft and several technology vendors and
research companies.