UNIT-III

Introduction to Devops:

DevOps is the acronym given to the combination of Development and Operations. It

refers to a collaborative approach to make the Application Development team and
the IT Operations team of an organization to seamlessly work with better
communication. It is a philosophy that encourages adopting iterative software
development, automation, and programmable infrastructure deployment and
maintenance.
DevOps emphasizes building trust and better liasioning between developers and
system administrators. This helps the organization in aligning technological projects
to business requirements. Changes rolled out are usually small and reversible,
which the entire team begins to comprehend.
DevOps is visualized as an infinite loop comprising the steps: plan, code, build, test,
release, deploy, operate, monitor, then back to plan, and so on.

While the visualization helps us understand how DevOps works. The following are
DevOps tools, and how they help an organization.
1. BUILD AUTOMATION – An automated code is prepared to be deployed in a
live environment where the tool used is tied to the programming language
chosen. This makes the whole process faster, consistent and more
repeatable. Further, it also ensures that your process is more reliable than
any manual build.
2. CI/ CD – Continuous Integration and Continuous Deployment deal with
frequent merging of codes and unit testing. Further, the deployment of small
code changes in a routine and frequent process is also a part of this method.
CI/CD helps massively as it helps you detect bugs early and maintains the
use of modular code with minimal effort. It also reduces the time to market
and introduces reliable rollbacks.
3. INFRASTRUCTURE AS CODE – This is usually to manage and provision IT
infrastructure through code and automation. This is reusable, and helps in
consistent resource creation and management. Furthermore, the
 infrastructure is self-documenting and simplifies complex material like
authentication and application servers.
4. CONFIGURATION MANAGEMENT – This is the process where you can manage
and change the state of infrastructure in constant and maintainable ways.
This way, we end up saving a lot of time while also minimizing configuration
drift, especially in large server environments. Configuration Management also
helps provide insight documentation on infrastructure.
5. ORCHESTRATION – Orchestration is nothing but an automation that supports
processes and workflows, like Resource Planning. It not only helps us, save
time, but you also achieve stability, especially with an automatic response to
detection of various problems.
6. MONITORING – By this method, you collect and present data about the
performance and stability of services and infrastructure, while also detecting
problems. This enables faster recovery, helps with cross-team visibility,
provides more data to analyze for better root-cause analysis and also
generates an automated response.
7. MICROSERVICES – It is basically an architecture that breaks an application
into many small and loosely collected services. This way, we end up reducing
complexity and increase flexibility in choice of technology.
Once we start following DevOps methodologies, it finds one way or the other to
make the software act in a similar way right from development to production, via
testing. It deploys changes individually, thus making bugs easily visible. These,
once discovered, lead to code improvements through investigations and constant
feedback channels. While developers run live software and IT Ops are involved in
design meetings – both of them, along with other specialists, can contribute to
investigations and feedback channels, which help foster a DevOps culture.

Evolution of DevOps

Originally coined by Patrick Debois, DevOps has become a critical discipline for
realizing the benefits of Agile that ensures that rapid, iterative code development
results in rapd, iterative code deployment! , DevOps resonated with both sides.
Organizations that have adopted ITIL can also implement DevOps, especially for
Cloud-based applications.
Starting with The Phoenix Project, by Gene Kim, DevOps has steadily gained
popularity and supporters, and is seen today as a crucial element of any Agile
technology organization. Consequently, large corporations and all sorts of
technology vendors now support DevOps. With the emergence of AI and ML in all
aspects of the software lifecycle, AI for DevOps is starting to make DevOps even
more smart, fast.

Methodologies, Principles and Strategies

While DevOps is seen as a natural extension of Agile, and somewhat of an

anathema for ITIL, it does not have its own framework – and can potentially be
relevant for a variety of situations.
Organizations that use traditional (waterfall) methods, characterized by sequential
stages of software development and long gaps between software releases, can use
 DevOps principles for better alignment between functions such as Dev, QA, and
Operations, with a greater transparency into all functions. Organizations that have
adopted one or more Agile methodologies can easily have their dev and operations
folks collaborate throughout the development process.
Newer disciplines such as AIOps, SRE (Site Reliability Engineering), SysOps,
DevSecOps and BizDevOps extend and expand DevOps principles and benefits while
adding other critical technology and methodologies such as AI, automation, security
and collaboration to further the cause of high quality agile software development.
The DevOps toolchain requires a variety of tools such as containers, configuration
management tools, CI/ CD tools, and many more as shown in the diagram below –

Cloud platform vendors such as Amazon AWS, Microsoft Azure and Google provide
a large range of such tools on their PaaS (Platform as a Service) offerings.
Finally, you need to have some of the key skills in the organization, with roles such
as DevOps engineers, full-stack developers and automation specialists.
Principles of Devops:

1. Collaboration

2. Data-Based Decision Making

3. Customer-Centric Decision Making

4. Constant Improvement

5. Responsibility Throughout the Lifecycle

6. Automation

7. Failure as a Learning Opportunity

1. Collaboration

DevOps in its purest form is the integration of the development (Dev) and
operations (Ops) teams. This means that collaboration is central to the foundation
of DevOps. By working together, development can better configure the software for
the operations phase and operations can test the software earlier to ensure it will
meet requirements.

Collaboration also depends on good information-sharing practices. An issue

discovered while the application is deployed should be adequately logged so the
development team can account for this in future builds.

In the same vein, feedback should also be shared across the team. Positive
feedback bolsters morale and reminds the team why its work is important. Negative
feedback is even more important to continuously improving software deliveries.

2. Data-Based Decision Making

Another central principle of DevOps is informing your decisions with data. We

should always collect data around each decision to ensure our choice agrees with
your team's metrics and historical data.

For example, a key performance indicator (KPI) for many teams is the time it takes
to resolve an issue. The longer a defect exists, the more damage it can cause.

Knowing your average resolution time will help us make informed decisions when
introducing new tools or procedures to your pipeline. You can compare their results
against your benchmark average and get a good idea of whether or not the new
addition will ultimately help or hurt your team.
3. Customer-Centric Decision Making

The customer should be a central focus in a DevOps lifecycle. Equally as important

as data, decisions should be weighed with the question, "Will this benefit the
customer?" Collecting feedback from the customer on the existing product will
guide future optimization.

DevOps teams also use live monitoring strategies to address problems before they
become an issue for the customer. Other tools allow the team to measure how end
users interact with the application in real time to see if they are encountering areas
of friction. The speed of the DevOps lifecycle then allows the team to push out
updates aimed at removing these pain points.

4. Constant Improvement

DevOps focuses on constant improvement, or the idea that the team should
continuously focus on new features and upgrades. Another key idea follows
the Agile methodology of incremental releases.

Previous software development strategies would focus on delivering the perfect

product all at once. Though this sounds ideal, in execution it often meant that
software deliveries would be delayed for long periods while issues were resolved.
Instead, incremental releases allow the team to focus on achieving a minimum
viable product (MVP) to meet the customer's core use case as soon as possible.

Once the MVP has been delivered, the team then shifts to producing features to add
additional value to the product and works their way toward the ideal software. In
the meantime, the customer can benefit from the tool sooner and learn the new
features as they're released as opposed to having to learn the entire platform at the
end of a waterfall delivery cycle.

5. Responsibility Throughout the Lifecycle

In traditional software development models, the development team codes and

builds the application. They then hand it to the operations team to test, deploy, and
deliver to the customer. Any bugs discovered in the second phase are left to the
operations team instead of the developers who wrote the code.
DevOps shows us a more logical approach: responsibility throughout the lifecycle.
The whole team is responsible for the product from initial planning to its end of life.
During this entire process, the development and operations teams are working
hand in hand to update the software and address issues.

Those most familiar with the source code are the same developers now working to
improve it and add new features. This places a new emphasis on producing quality
code and proactively rooting out bugs, which leads to better outcomes for the
customer.

6. Automation

A key benefit of the DevOps approach is speed: speed of software delivery, speed
of updates, speed of patches. This momentum is achieved with automation.
DevOps teams aim to automate every single phase of the process, from code
reviews to handoffs to provisioning and deployment.

Not only does this allow the pipeline to move faster, but it also leads to higher job
satisfaction among team members. They no longer have to perform manual and
tedious tasks. Instead, they can focus on higher-order tasks like planning future
improvements and researching new technologies to implement in the software.

The easiest route to automation is through purpose-built DevOps tools.

7. Failure as a Learning Opportunity

DevOps is a flexible approach to development. Processes are constantly being fine-

tuned just as the software itself is continuously improving. Part of maintaining this
flexibility is to view failure as an opportunity to learn and improve. Rather than
trying to avoid failure at all costs, encourage risk-taking in the right context.

Risks come with the possibility of failure, but they also can lead to success. No
matter how an experiment goes, you will better understand what does and doesn't
work. This experience will help you plan future strategies and act as another data
point for your decision-making.
Of course, early testing will enable you to fail fast where the failure isn't impacting
the customer. This is the ideal time to encounter issues versus failing after
deployment. This strategy is part of a concept known as "shifting left," which we'll
examine next.
Why does DevOps recommend shift left testing principles?

DevOps' emphasis on testing is a critical differentiator from other software

development strategies. While other strategies focus on testing after coding and
building the software, DevOps implements a "shift left" principle. If we imagine the
development process as a straight line, shifting left means moving testing as far left
toward the start of the process as possible.

Testing while still in the development side of the DevOps lifecycle offers notable
benefits. First, it's easier, faster, and cheaper to uncover defects early in the
process before more code has been written on top of it. More dependencies mean
more complexity, and this increases the chance that fixing one part of the code will
lead to something else breaking.

Another benefit of a shift left testing approach is that the emphasis for the
development team is now on producing quality code from the start instead of
waiting until a later stage to find defects. The product is delivered to the customer
faster and with fewer (if any) bugs. Everyone gains from this approach.

Automation :

DevOps automation is the addition of technology that performs tasks with

reduced human assistance to processes that facilitate feedback loops
between operations and development teams so that iterative updates can
be deployed faster to applications in production.

Need of Automation:

Automation helps businesses on their path to digital transformation. Organizations

today are dealing with major disruption—think Airbnb, Amazon, etc. They’re
challenged with supporting their employees and partners, reaching new customers,
and providing new, innovative products and services faster.
Automation is critical to managing, changing, and adapting not only your IT
infrastructure, but the way your business operates through its processes. By
simplifying change through automation, you gain the time and energy to focus on
innovation. The automated enterprise's goal is to get work done faster. This
frees up IT staff to focus on bigger issues, resolving them, and—in turn—making
them routine and eligible for automation.
 IT operations is hard work. It's even harder to keep up with legacy systems
and processes while adopting new ones.
 Requirements and demand are growing exponentially faster than IT and
business capabilities.
 New methodologies like DevOps are forcing cultural changes.
 The scale of technology (virtualization, cloud, containers, etc.) is too great to
do manually.
 Automation gets you there.
Advantages of automation:
Automation isn’t necessarily meant to replace people. Some of that will happen as a
result of removing steps that require human interaction, but the focus and
advantages are found in productivity, consistency, and efficiency. This is
the paradox of automation—as you become efficient using automation, human
involvement becomes both more important and less frequent.
Instead of seeing automation as a tool that eliminates jobs, the reality is that it
allows more experienced IT staff to focus on bigger problems and their solutions,
rather than mundane, day-to-day, repeated tasks.

Advantages
 Greater productivity. Your staff can spend more time making a bigger
impact on your business. Leave the repetition to software.
 Better reliability. By reducing the amount of human intervention, you run
into less oversights and issues. All of the same things happen the same way
—every time. That way you know exactly when processes, tests, updates,
workflows, etc. are going to happen, how long they’ll take, and that you can
trust the outcomes.
 Easier governance. More people means more potential for knowledge gaps.
More knowledge gaps means one side of your business might not know what,
or who, is involved on the other side. Codifying everything means better
control.

Challenges
 Cost. Building an effective automation solution takes time and energy. Work
with a trusted partner like Red Hat—who is able to handle the heavy lifting
for you—to help you save and get running faster.
 Scope. Automation doesn’t mean intelligence. Depending on what’s
automated and how it’s constructed, some parts may be vulnerable outside
of that scope. Limiting automation in some aspects or functions can mitigate
this concern. Your automation is only as smart and safe as how it’s
implemented, so keep that in mind.
 Types of Automation:

There are many kinds of automation, including IT automation, business

automation, robotic process automation, industrial automation, artificial
intelligence, machine learning, and deep learning.

IT automation
A system of instructions that carry out a repeated set of processes to replace
manual work done to IT systems, such as automating provisioning using a standard
operating environment (SOE).

Business automation
The alignment of business process management (BPM), business process
automation (BPA), business rules management (BRM), and business
optimization with modern application development to respond to market changes.

Business process automation

The use of software robots to perform repetitive tasks previously done by humans.

Robotic process automation

The use of software robots to perform repetitive tasks previously done by humans.

Industrial automation
The reduction of human labor in manufacturing processes as part of factory
automation efforts, usually to the point where human workers simply provide
oversight at a control panel or other human-machine interface (HMI).

Artificial intelligence
Rules-based software that performs tasks typically accomplished with human
intervention.

A guide to AI

Machine learning
Adaptive algorithms that use predictive models to perform tasks without explicit
instructions—automatically modifying algorithms with each completed task

Deep learning
Multiple adaptive algorithms, automation software, and programs that perform a
fixed repetitive task—such as extracting small details from raw images.
DevOps Metrics and Key Performance Indicators
1. Deployment Frequency
Deployment frequency denotes how often new features or capabilities are
launched. Frequency can be measured on a daily or weekly basis. Many
organizations prefer to track deployments daily, especially as they improve
efficiency.
Ideally, frequency metrics will either remain stable over time or see slight and
steady increases. Any sudden decrease in deployment frequency could indicate
bottlenecks within the existing workflow.
More deployments are typically better, but only up to a point. If high frequency
results in increased deployment time or a higher failure rate, it may be worth
holding off on deployment increases until existing issues can be resolved.
2. Change Volume
Deployment frequency means little if the majority of deployments are of little
consequence.
The actual value of deployments may be better reflected by change volume.
This DevOps KPI determines the extent to which code is changed versus
remaining static. Improvements in deployment frequency should not have a
significant impact on change volume.
3. Deployment Time
How long does it take to roll out deployments once they’ve been approved?
Naturally, deployments can occur with greater frequency if they’re quick to
implement. Dramatic increases in deployment time warrant further investigation,
especially if they are accompanied by reduced deployment volume. While short
deployment time is essential, it shouldn’t come at the cost of accuracy. Increased
error rates may suggest that deployments occur too quickly.
4. Failed Deployment Rate
Sometimes referred to as the mean time to failure, this metric determines how
often deployments prompt outages or other issues.
This number should be as low as possible. The failed deployment rate is often
referenced alongside the change volume. A low change volume alongside an
increasing failed deployment rate may suggest dysfunction somewhere in the
workflow.
5. Change Failure Rate
The change failure rate refers to the extent to which releases lead to unexpected
outages or other unplanned failures. A low change failure rate suggests that
deployments occur quickly and regularly. Conversely, a high change failure rate
suggests poor application stability, which can lead to negative end-user outcomes.
6. Time to Detection
A low change failure rate doesn’t always indicate that all is well with your
application.
While the ideal solution is to minimize or even eradicate failed changes, it’s
essential to catch failures quickly if they do occur. Time to detection KPIs can
determine whether current response efforts are adequate. High time to detection
could prompt bottlenecks capable of interrupting the entire workflow.
7. Mean Time to Recovery
Once failed deployments or changes are detected, how long does it take actually to
address the problem and get back on track?
Mean time to recovery (MTTR) is an essential metric that indicates your ability to
respond appropriately to identified issues. Prompt detection means little if it’s not
followed by an equally rapid recovery effort. MTTR is one of the best known and
commonly cited DevOps key performance indicator metrics.
8. Lead Time
Lead time measures how long it takes for a change to occur.
This metric may be tracked beginning with idea initiation and continuing through
deployment and production. Lead time offers valuable insight into the efficiency of
the entire development process. It also indicates the current ability to meet the
user base’s evolving demands. Long lead times suggest harmful bottlenecks, while
short lead times indicate that feedback is addressed promptly.
9. Defect Escape Rate
Every software deployment runs the risk of sparking new defects. These might not
be discovered until acceptance testing is completed. Worse yet, they could be found
by the end user.
Errors are a natural part of the development process and should be planned for
accordingly. The defect escape rate reflects this reality by acknowledging that
issues will arise and that they should be discovered as early as possible.
The defect escape rate tracks how often defects are uncovered in pre-production
versus during the production process. This figure can provide a valuable gauge of
the overarching quality of software releases.
10. Defect Volume
This metric relates to the escape rate highlighted above, but instead focuses on the
actual volume of defects. While some defects are to be expected, sudden increases
should spark concern. A high volume of defects for a particular application may
indicate issues with development or test data management.
11. Availability
Availability highlights the extent of downtime for a given application.
This can be measured as complete (read/write) or partial (read-only) availability.
Less downtime is nearly always better. That being said, some lapses in availability
may be required for scheduled maintenance. Track both planned downtime and
unplanned outages closely, keeping in mind that 100 percent availability might not
be realistic.
12. Service Level Agreement Compliance
To increase transparency, most companies operate according to service level
agreements. These highlight commitments between providers and clients. SLA
compliance KPIs provide the necessary accountability to ensure that SLAs or other
expectations are met.
13. Unplanned Work
How much time is dedicated to unexpected efforts? The unplanned work rate
(UWR) tracks this in relation to time spent on planned work. Ideally, the
unplanned work rate (UWR) will not exceed 25 percent.
A high UWR may reveal efforts wasted on unexpected errors that were likely not
detected early in the workflow. The UWR is sometimes examined alongside the
rework rate (RWR), which relates to the effort to address issues brought up in
tickets.
14. Customer Ticket Volume
As the defect escape rate KPI suggests, not all defects are disastrous. Ideally,
however, they will be caught early. This concept is best reflected in customer ticket
volume, which indicates how many alerts end users generate. Stable user volume
alongside increased ticket volume suggests issues in production or testing.
15. Cycle Time
Cycle time metrics provide a broad overview of application deployment.
This KPI tracks the entirety of the process, beginning with ideation and ending with
user feedback. Shorter cycles are generally preferable, but not at the expense of
discovering defects or abiding by SLAs.
DevOps vs Agile
DevOps and Agile are the two software development methodologies with similar
aims, getting the end-product as quickly and efficiently as possible. While many
organizations are hoping to employ these practices, there is often some confusion
between both methodologies.
Below are some essential differences between the DevOps and Agile:
Agile Infrastructure:
An Agile IT infrastructure is one that is designed to support rapid deployment
and provisioning, and incremental upgrades and improvements. It takes its
name from the development methodology made famous in the 2001 Manifesto for
Agile Software Development.
Need of Agile Infrastructure:
• Faster Deployment: Unlike the traditional way of project management, where a
sign-off on the project was only given when the project was nearly complete, agile
methodology starts rolling out the end product to the end user, stage by stage as
and when it is ready. Thus achieving faster deployment and continuous delivery,
feedback and improvement.
• Increased Flexibility: IT infrastructure is known for its conservative behavior
when it comes to change. With Agile Infrastructure, organisations get room to
makes changes and amendments as and when required, anytime during the project
tenure or even after it is over.
• Continuous Feedback: In the traditional ways of project management,
feedbacks use to roll in only after the project was rolled out, this would take
months and years to shape up a project to perfection. In fact, the feedbacks used
to come so late that the system had no more space to make any improvements,
thus making it a very rigid and time taking process. With Agile Infrastructure, the
implementation team is provided with feedbacks from the end user during the
project tenure which is very valuable in shaping the final product to perfection.
• Continuous Improvement: The faster Deployments in the method of agile
infrastructure allows the end user to use and review the product in phases, thus
they feed the implementation team with continuous feedback, which allows the
team to improve the product so that it meet the need of the end user.

Limitations of Agile Infrastructure

• It is a tedious task to estimate efforts for bigger and complex projects right at the
beginning of the implementation.

• Smaller release cycles may not be a very successful procedure while

implementing an infrastructure solution as it still deals with physical hardware and
connections.

• Agile method pays less importance to design and documentation as everything

happens on a real time basis.

• Infrastructure projects are very complicated involving both hardware and

software. There can be situations where limited changes can be done to the
hardware, thus making it difficult to start over again even if required.

• The clients are not always very clear about the final product that they expect out
of the exercise, which becomes a hindrance in the path of agility of the project.

• Agile works best in an experienced environment. To make sure of agile

infrastructure one has to find experienced resources for the project, which is not
always possible.
Transforming IT infrastructure organizations using agile:

Traditional IT infrastructure processes made sense in the past. But now that the
latest technology advances have eliminated the need for manual configuration work
and consumers expect to interact with companies digitally, it has become essential
for companies to modernize their IT infrastructure organizations, thereby
accelerating IT deployments and shortening time to market for technology projects.
Four shifts can enable IT infrastructure organizations to operate in a more agile and
efficient manner. The first of these shifts involves managing infrastructure much as
application developers manage code, by using software to configure environments
in a swift, reliable way. The other three are organizational: forming cross-functional
teams (or “squads”) of well-rounded infrastructure engineers that work using agile
methods, simplifying processes for delivering infrastructure service offerings, and
improving how infrastructure teams and development teams work together.

Using an agile transformation to modernize an IT infrastructure organization isn’t

easy, but it is worthwhile. In our experience, agile approaches can enable IT
infrastructure groups to boost their productivity by 25 to 30 percent in six to 18
months, depending on the size of the organization. The gains can increase further
as automated solutions are built and fully adopted. Additional benefits often include
improved infrastructure service delivery and shortened time to market for digital
products and features.

Principles for agile transformation

Despite the differences between their transformation approaches, companies

followed many principles. The principles applied in in four areas: technology,
organization and talent, processes, and collaboration with developers (exhibit).

Technology: Defining infrastructure with software:

One reason traditional infrastructure organizations operate slowly is that their

technology systems require teams to configure infrastructure manually for each
new application. To bring agility to the infrastructure function, companies can not
only eliminate manual work by building automated systems that allow infrastructure
to be defined by software but also provide “guardrails” that enable application-
development teams to manage more of their own operations safely. And while it’s
possible to build such systems with existing infrastructure, automation becomes
easier as a company moves more of its infrastructure onto modern platforms,
especially cloud platforms offering a wide array of enabling tools and technologies.
At the software-and-services company, even though the infrastructure team had
standardized much of the hardware and virtualization architecture, it still spent a lot
of time creating custom virtual-machine and operating-system configurations for
product-development teams. Solution engineers reviewed the needs of each
application with its developers and then set up the necessary environments, which
often involved performing many steps manually. As part of the company’s agile
transformation, agile infrastructure teams implemented automated solutions to
streamline the provisioning and configuration of servers. One agile team built and
maintained a centralized platform that automated the provisioning of servers and
could be accessed through self-service tools. Other agile infrastructure teams, each
aligned with specific software-as-a-service (SaaS) products, automated the
configuration of those servers for the products they supported, using a
configuration-management tool to define the servers’ configurations entirely in
code. This change reduced build times for environments from several months to
about ten minutes. After these solutions were implemented, whenever a cluster of
servers had to be updated or expanded, teams could make the necessary changes
rapidly, with minimal manual effort and risk of error.

Organization and talent: Building cross-functional teams

At traditional companies, infrastructure organizations have long been structured

around teams with narrowly defined responsibilities for specific technical functions
(for example, managing relational databases or operating systems) or stages of the
plan-build-run IT service life cycle. Neither this structure nor the specialization it
promotes is conducive to efficiency or agility, because multiple teams must typically
work on each service request. To become more agile, infrastructure organizations
can organize their staffs into small cross-functional teams focused on providing
well-defined services. They can also develop modern workforces of well-rounded
engineers who can learn new skills rapidly and work across multiple functional
domains to carry out the end-to-end delivery of infrastructure services, as we
describe below.

Organization and talent: Building cross-functional teams

At traditional companies, infrastructure organizations have long been structured

around teams with narrowly defined responsibilities for specific technical functions
(for example, managing relational databases or operating systems) or stages of the
plan-build-run IT service life cycle. Neither this structure nor the specialization it
promotes is conducive to efficiency or agility, because multiple teams must typically
work on each service request. To become more agile, infrastructure organizations
can organize their staffs into small cross-functional teams focused on providing
well-defined services. They can also develop modern workforces of well-rounded
engineers who can learn new skills rapidly and work across multiple functional
domains to carry out the end-to-end delivery of infrastructure services, as we
describe below.

CIOs and technology leaders should bear in mind that engineers in agile
infrastructure organizations typically need more diverse skill sets than application
developers do. For infrastructure, that makes agile transformations more
challenging. The infrastructure organization at the European financial-services
company found some of the well-rounded infrastructure engineers it needed by
carefully screening existing employees. The most capable ones were offered roles
on infrastructure squads charged with building the highly automated self-service
solutions described above.

At the software-and-services company, the leaders of the infrastructure group

chose to organize their staff into skill-focused “chapters” to help with capability
building, professional development, and standard setting. Chapter leaders
determined which new skill sets their areas needed and were asked to develop
training or hiring plans to meet those needs. For working purposes, the company
organized everyone from those chapters into two types of cross-functional agile
squads led by product owners who defined and prioritized the backlog of activities
that their squads would work on. Infrastructure squads focused on developing
highly automated foundational infrastructure solutions (such as server provisioning)
that other teams could use to set up, manage, and decommission infrastructure.
Product squads were aligned closely with specific SaaS product-development teams
and worked to engineer and automate hosting and operations for their applications,
leveraging services from infrastructure squads when available.

Processes: Simplifying and integrating activities to minimize delays

The traditional IT infrastructure organization’s functionally oriented structure

imposes a particular working style—specialized resources complete tasks in a
prescribed order, with many handoffs between groups. This working style causes
innumerable delays: every time a request is passed to a new group, it goes to the
bottom of that group’s task list, where it might languish for days. Frequently, tasks
are sent back to previous groups for clarification, increasing wait times even
further.

Companies can eliminate many of these delays by creating small cross-functional

teams as described in the previous section. Such teams can minimize or even
eliminate process handoffs by managing the end-to-end delivery of specific service
offerings. They should be empowered not only to deliver service offerings but also
to improve their delivery by streamlining processes and engineering fully
automated solutions.

The processes of the software-and-services company’s infrastructure group had

become increasingly complex as the company grew and added new customer-facing
products. That led to the use of project coordinators to help push service requests
through the organization. After the company grouped its infrastructure engineers
into agile squads, however, the waiting periods that had previously followed
handoffs among functional groups vanished. That change alone halved the amount
of time required to provide many core service offerings. The company’s squads also
redesigned common processes to simplify workflows or eliminate unnecessary
steps, such as certain approvals. The number of steps in virtual-server provisioning,
for example, was cut by more than two-thirds, and the remaining steps were then
largely automated through better engineering.
By contrast, the US-based financial services company mentioned earlier took a
different approach to compensate for the limited development skills of its
infrastructure organization. First, it set up cross-functional squads to simplify
processes without automation. The resulting productivity gains bought employees
enough time to learn more advanced engineering skills. Then they began planning
the development of automated capabilities to address common requests.

Collaboration with application development: Fostering understanding and

accountability

Traditional infrastructure organizations have minimal interaction with application-

development teams. Collaboration between the two camps is normally limited to
the initial setting up of systems for new applications and the resolution of critical
incidents. As a result, typical infrastructure engineers know too little about each of
the applications they support to help improve the stability of those applications.
Moreover, developers lack the awareness of operational issues they would need to
engineer robust, easy-to-support applications. Modern agile organizations, by
contrast, make a point of increasing the level of collaboration between their
application-development and infrastructure functions.

The European financial-service company described earlier exemplifies one

collaboration style: making developers accountable for operating their applications.
Involving developers in the incident-response and postoutage follow-up processes
for their applications makes them more aware of issues in their application code.
Involving developers in operations also encourages them to write code easy to
manage and support—they can be awakened in the middle of the night if incidents
occur.

The large software-and-services company demonstrates a contrasting approach. Its

infrastructure organization continued to support operations for application-
development teams but found a new way of doing so: closely aligning agile product
squads and application-development teams. The alignment greatly increased
coordination and collaboration. Many of the product squads were co-located, at
least in part, with the application-development teams they partnered with. Core
members of each product squad would attend some of the agile ceremonies of the
application-development teams. In addition, the close alignment helped
infrastructure engineers to gain familiarity with the applications they managed, so
they had a stronger attachment to the success of those applications, which could
now be better monitored and supported.
Parameter DevOps Agile

Definition DevOps is a practice of bringing Agile refers to the continuous

development and operation teams iterative approach, which focuses
together. on collaboration, customer
feedback, small, and rapid releases.

Purpose DevOps purpose is to manage end to The agile purpose is to manage

end engineering processes. complex projects.

Task It focuses on constant testing and It focuses on constant changes.

delivery.

Team size It has a large team size as it involves all It has a small team size. As smaller
the stack holders. is the team, the fewer people work
on it so that they can move faster.

Team skillset The DevOps divides and spreads the skill The Agile development emphasizes
set between development and the training all team members to have
operation team. a wide variety of similar and equal
skills.

Implementation DevOps is focused on collaboration, so it Agile can implement within a range

does not have any commonly accepted of tactical frameworks such
framework. as safe, scrum, and sprint.

Duration The ideal goal is to deliver the code to Agile development is managed in
production daily or every few hours. units of sprints. So this time is
much less than a month for each
sprint.

Target areas End to End business solution and fast Software development.
delivery.

Feedback Feedback comes from the internal team. In Agile, feedback is coming from
the customer.

Shift left It supports both variations left and right. It supports only shift left.
principle

Focus DevOps focuses on operational and Agile focuses on functional and

business readiness. non-functional readiness.

Importance In DevOps, developing, testing, and Developing software is inherent to

implementation all are equally Agile.
important.

Quality DevOps contributes to creating better The Agile produces better

quality with automation and early bug applications suites with the desired
removal. Developers need to follow requirements. It can quickly adapt
Coding and best Architectural practices according to the changes made on
to maintain quality standards. time during the project life.

Tools Puppet, Chef, AWS, Ansible, and team Bugzilla, Kanboard, JIRA are
City OpenStack are popular DevOps some popular Agile tools.
tools.

Automation Automation is the primary goal of Agile does not emphasize on the
DevOps. It works on the principle of automation.
Velocity :
Velocity is a metric for work done, which is often used in agile software
development.[1]
Measuring velocity is sometimes called velocity tracking. The velocity metric is used
for planning sprints and measuring team performance. The main idea behind
velocity is to help teams estimate how much work they can complete in a given
time period based on how quickly similar work was previously completed. Velocity is
relative measure.
One of the biggest advantages to DevOps is what is often called velocity: working
with both speed and direction. By breaking down barriers between IT and business,
this close and speedy collaboration can provide
When people can directly collaborate, they tend to hash out any potential issues
with a project much more quickly. Organizations the are separated by function may
find that development on a project moves much more slowly than hoped.

For example, selected business team members might meet with selected IT
members at the beginning of a project. They then each go their own way with
expectations that may change before their next meeting, which could be after
several weeks, months, or longer have passed.

The intersection of various departments as DevOps

On the other hand, employing DevOps allows for more collaborative functions
between teams. There can be employees from each group that meets daily or team
members from one group embedded within one or more other groups so that the
different functional groups are all working directly with one another each and every
day.

This allows for communication of any new needs or issues to happen right away,
where differences can be hashed out immediately, rather than waiting for a meeting
that could be derailed by one issue like this for the entire meeting duration and
being unable to address other needs and concerns during that precious time.
Development With Velocity
DevOps is often implemented when an organization uses the Agile method of
software development, which often leads to the need for the actual organizational
changes that lead to beginning to use DevOps practices.

Agile development is a method that encourages speed and flexibility in response to

an ever-changing set of requirements during software development. Instead of
needing to wait for new ideas, this flexibility allows development to continue with
little interruption or delay in the process as needs change. This ability to change
rapidly also increases the number of releases of a product. Thus, new releases and
updates happen at a much faster rate, which encourages continuous delivery of a
product.

The speed of Agile typically requires a toolset that allows for the automation of
certain processes so that speed is not hindered by processes that need to be
performed manually over and over again. Not only can that be tedious, but it can
use up the valuable time your developers or other IT staff could be using to further
enhance the product and deliver further releases. Automation allows for many of
the processes to be free of manual involvement, which frees up your staff for other
work.

When DevOps is employed alongside Agile development to support it, your velocity
will be increased even further and allow you to make your customers happier and
do so more quickly!

Total Velocity
While DevOps can be a challenge to get going as it requires a number of
organizational changes tailored to your specific business needs, it can be well worth
the effort needed to reorganize and regroup. The increased speed of delivery of
your products and updates can really help you, especially if it helps you to be first
to market on a new idea.

Not only will you get improved speed, but it can help your staff feel more like they
are getting along and are contributing to projects that make it to completion.
Seeing something they contributed to in action can be helpful in motivating staff to
find ways to streamline processes even further and thus enhance your velocity that
much more.

LEAN STARTUP:

Lean startup is a methodology for developing businesses and products that aims to
shorten product development cycles and rapidly discover if a proposed business
model is viable; this is achieved by adopting a combination of business-hypothesis-
driven experimentation, iterative product releases, and validated learning. Lean
startup emphasizes customer feedback over intuition and flexibility over planning.
This methodology enables recovery from failures more often than traditional ways
of product development
Lean manufacturing
Lean manufacturing systems consider as waste the expenditure of resources for any
goal other than the creation of value for the end customer, and continually seek
ways to eliminate such waste. In particular, such systems focus on:
 minimizing inventory throughout the assembly line,
 using Kanban cards to signal only when the necessary inputs to production are
needed, and in so doing, reduce assembly waste (inventory) and increase
productivity,
 identifying mistakes or imperfections during assembly as early as possible at
immediate quality control checkpoints to ensure that the least amount of time is
expended developing a faulty product,and
 maintaining close connections with suppliers in order to understand their
customers' desires.
Lean manufacturing was later applied to software as lean software development.
Customer development
The lean startup methodology is based on the customer
development methodology.Steve, Blank pointed out the pitfalls of a narrow
emphasis on product development; instead he argued that startups should focus on
what he called "customer development", which emphasizes "learning about
customers and their problems as early in the development process as possible".
Blank's customer development methodology proposed four steps:
1. Customer discovery tests hypotheses about the nature of the problem,
interest in the product or service solution, and business viability.
2. Customer validation tests the business viability through customer purchases
and in the process creates a "sales road map", a proven and repeatable sales
process. Customer discovery and customer validation corroborate the
business model.
3. Customer creation executes the business plan by scaling through customer
acquisition, creating user demand and directing it toward the company's
sales channels.
4. Company building formalizes and standardizes company departments and
operations.

Principles:
Minimum viable product:
A minimum viable product (MVP) is the "version of a new product which allows a
team to collect the maximum amount of validated learning about customers with
the least effort" (similar to a pilot experiment). The goal of an MVP is to test
fundamental business hypotheses (or leap-of-faith assumptions) and to help
entrepreneurs begin the learning process as quickly as possible
As an example, Ries noted that Zappos founder Nick Swinmurn wanted to test the
hypothesis that customers were ready and willing to buy shoes online. Instead of
building a website and a large database of footwear, Swinmurn approached local
shoe stores, took pictures of their inventory, posted the pictures online, bought the
shoes from the stores at full price after he'd made a sale, and then shipped them
directly to customers. Swinmurn deduced that customer demand was present, and
Zappos would eventually grow into a billion dollar business based on the model of
selling shoes online.
Continuous deployment (only for software development)
Continuous deployment, similar to continuous delivery, is a process "whereby all
code that is written for an application is immediately deployed into production,"
which results in a reduction of cycle times. Ries stated that some of the companies
he's worked with deploy new code into production as often as 50 times a day. The
phrase was coined by Timothy Fitz, one of Ries's colleagues and an early engineer
at IMVU.
Split testing
A split or A/B test is an experiment in which "different versions of a product are
offered to customers at the same time.The goal of a split test is to observe
differences in behavior between the two groups and to measure the impact of each
version on an actionable metric.
A/B testing is sometimes incorrectly performed in serial fashion, where a group of
users one week may see one version of the product while the next week users see
another. This undermines the statistical validity of the results, since external events
may influence user behavior in one time period but not the other. For example, a
split test of two ice cream flavors performed in serial during the summer and winter
would see a marked decrease in demand during the winter where that decrease is
mostly related to the weather and not to the flavor offer.
Another way to incorrectly A/B test is to assign users to one or another A/B version
of the product using any non-random method.
Actionable metrics
Actionable metrics can lead to informed business decisions and subsequent
action. These are in contrast to vanity metrics—measurements that give "the
rosiest picture possible" but do not accurately reflect the key drivers of a business.
Vanity metrics for one company may be actionable metrics for another. For
example, a company specializing in creating web based dashboards for financial
markets might view the number of web page views[ per person as a vanity metric
as their revenue is not based on number of page views. However, an online
magazine with advertising would view web page views as a key metric as page
views are directly correlated to revenue.
A typical example of a vanity metric is "the number of new users gained per day".
While a high number of users gained per day seems beneficial to any company, if
the cost of acquiring each user through expensive advertising campaigns is
significantly higher than the revenue gained per user, then gaining more users
could quickly lead to bankruptcy.
Pivot
A pivot is a "structured course correction designed to test a new fundamental
hypothesis about the product, strategy, and engine of growth. A notable example of
a company employing the pivot is Groupon; when the company first started, it was
an online activism platform called The Point. After receiving almost no traction, the
founders opened a WordPress blog and launched their first coupon promotion for a
pizzeria located in their building lobby. Although they only received 20 redemptions,
the founders realized that their idea was significant, and had successfully
empowered people to coordinate group action. Three years later, Group on would
grow into a billion dollar business.
Innovation accounting:
This topic focuses on how entrepreneurs can maintain accountability and maximize
outcomes by measuring progress, planning milestones, and prioritizing. The topic
was later expanded upon to include three levels of innovation accounting related to

the types of assumption s being validated.

Artefacts and actions in the Build-Measure-Learn loop

Build-Measure-Learn
The Build–Measure–Learn loop emphasizes speed as a critical ingredient to
customer development. A team or company's effectiveness is determined by its
ability to ideate, quickly build a minimum viable product of that idea, measure its
effectiveness in the market, and learn from that experiment. In other words, it is
a learning cycle of turning ideas into products, measuring customers' reactions and
behaviors against built products, and then deciding whether to persevere or pivot
the idea; this process repeats as many times as necessary. The process can also be
viewed as a test of hypotheses.
The phases of the loop are:
Ideas → Build → Product → Measure → Data → Learn.