Aligning ALM and Cloud strategies - Download Center - Microsoft

31 Pages·2014·1.27 MB·English

Aligning ALM and Cloud strategies
The DevOps Opportunity
Author
Martijn Hoogendoorn, Architect, Applied Incubation, Microsoft
Intended audience
This paper is written for software architects, technical decision makers and companies that want to increase the quality
and maturity of their ALM processes.
Abstract
ALM is a field that is seeing rapid improvement in the quality of tools and the strategy for applying those tools to continuous
software development. We provide an overview of current technology and strategy that will enable teams to be successful in
creating solutions that are more stable and evolve faster through continuous feedback loops.
Acknowledgments
The author would like to thank the following people who contributed to, reviewed, and helped improve this white paper.
Contributors
Marc Mercuri, Senior Director, Applied Incubation, Microsoft
Jose Miguel Parrella, Field Marketing Manager, Commercial Software Initiative, Microsoft
Mark Simms, Principal Program Manager, Customer Advisory Team, Data Platform Group, Microsoft
Robert Standefer, Envisioning Architect, Enterprise Strategy Services, Microsoft
Patrick Butler Monterde, Architect, Applied Incubation, Microsoft
Reviewers
Violeta Arroyo, Senior Product Marketing Manager, Developer Tools, Marketing and Sales, Microsoft
Tina Botes, ALM Ranger, Senior Premier Field Engineer, Enterprise Services, Microsoft
Jeff Bramwell, ALM Ranger, Director, Enterprise Architecture, Farm Credit Services of America
Shawn Cicoria, ALM Ranger, Senior consultant, Enterprise Services, Microsoft
Dave Crook, ALM Ranger, Associate Consultant, Enterprise Services, Microsoft
Dick Dijkstra, Azure Technology Solution Professional, Enterprise and Partner Group, Microsoft
Richard Fennell, ALM Ranger, Director, Engineering, Black Marble Ltd.
Larry Guger, Senior Program Manager, Developer Division, Microsoft
Arno Harteveld, IP Development Architect, Enterprise Strategy Services, Microsoft
Mark Kottke, Architect, Applied Incubation, Microsoft
Dennis Mulder, Architect, Modern Apps Center of Excellence, Microsoft
Mark Nichols, Senior Consultant, Enterprise Services, Microsoft
William H. Salazar, ALM Ranger, Director, ALM practice, Neudesic
Willy-Peter Schaub, ALM Ranger, Senior Program Manager, Developer Division, Microsoft
Ray Stephenson, Director, Applied Incubation, Microsoft
Brian Seitz, IP Development Architect, Enterprise Strategy Services, Microsoft
Jason Wescott, Principal Program Manager, Trustworthy Computing, Microsoft
Page i
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of
publication.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter
in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document
does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such
references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the
products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough
coverage. For authoritative descriptions of these products, please consult their respective manufacturers.
© 2014 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express authorization of
Microsoft Corp. is strictly prohibited.
Microsoft and Windows are either registered trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Page ii
Table of contents
Introduction ......................................................................................................................................................................... 1
Business benefits ............................................................................................................................................................... 3
Components of an ALM strategy .................................................................................................................................. 4
Continuous delivery........................................................................................................................................................................ 4
Automation ................................................................................................................................................................................... 5
Continuous integration ............................................................................................................................................................ 6
Continuous deployment .......................................................................................................................................................... 6
Continuous improvement ....................................................................................................................................................... 7
Telemetry ............................................................................................................................................................................................... 7
DevOps ........................................................................................................................................................................................... 8
Modeling and fault injection testing ............................................................................................................................... 11
Modeling and design ..................................................................................................................................................................... 12
Technologies..................................................................................................................................................................... 14
Cloud computing as an enabler ............................................................................................................................................. 14
Infrastructure as a service (IaaS) ........................................................................................................................................ 14
Platform as a service (PaaS) ................................................................................................................................................ 14
Software as a service (SaaS) ................................................................................................................................................ 15
Hybrid .......................................................................................................................................................................................... 15
The Microsoft integrated approach ...................................................................................................................................... 15
Defining the modern application lifecycle .................................................................................................................... 16
Microsoft Tools and Technologies ................................................................................................................................... 16
Windows PowerShell ...................................................................................................................................................................... 16
Microsoft Build Engine .................................................................................................................................................................. 18
Visual Studio ...................................................................................................................................................................................... 19
Microsoft Project Server ............................................................................................................................................................... 20
System Center ................................................................................................................................................................................... 20
Azure Resource Manager ............................................................................................................................................................. 22
Application Insights ........................................................................................................................................................................ 23
Azure Automation Services ......................................................................................................................................................... 24
Enabling modern ALM with Microsoft technologies ............................................................................................. 25
Conclusion ......................................................................................................................................................................... 26

Page iii
Page iv
Introduction
A government site is launched and announced on every major news network. The publicity drives
significant traffic to the site. Despite being tested previously for up to 8 million users, the site starts to fail
with just a fraction of that number. Tempers flare, fingers are pointed, and developers insist nothing has
changed. In reality, a junior developer made a change that created a dependency on an external URL
shortening service with a lower SLA, did no additional testing, and deployed it directly from his laptop.
Despite all of the effort and planning for the launch, one junior developer transformed the site from being
designed to scale to being designed to fail.
The CEO of a hot Silicon Valley company is reading and enjoying a very complimentary article in a major
national newspaper. He hears a notification from his social media monitoring tool that there are a lot of
people talking about his company. He assumes it’s related to the article, but is disappointed to see that
it’s about an issue with the site. A developer had deployed an update to the production environment, but
had done so using a configuration file intended for their test environment. The result? Millions of users
having challenges because the site was now configured to use a test database instead of the one
intended for the product site.
These examples of real world issues happened on cloud-based platforms, but they weren’t the fault of the
cloud hosting providers. These failures resulted from breakdowns in the organizations’ application
lifecycle management (ALM). Although the cloud isn’t the cause of the issue, it does underscore the need
for ALM. The cloud provides democratic access to massive compute power and empowers the current
world of 24x7 always-on, always-connected consumers. These trends require that those organizations
without ALM processes adopt them, and those that have legacy processes revise them.
As organizations adopt or adapt ALM processes to conduct their business, they can look to successful
startups and consumer cloud services for insight. These organizations have pioneered approaches, some
in contrast to legacy enterprise norms, for delivering solutions in the cloud with agility and efficiency.
Automation is part of the foundation of these approaches. Today, software automation enables devices
and services, whether physical or virtual, to be configured, built, compiled, tested, and deployed in an
automated fashion. The result is an opportunity to accelerate many aspects of the ALM lifecycle, resulting
in increased speed of development and testing, reduced risk of human error, and faster time to market.
As a result, ALM has evolved to include the following processes and practices:
▪ Continuous delivery. Delivering business value on a continual basis by deploying high quality
solutions frequently.
− Continuous integration. Integrating different parts of the solution in a continuous fashion
ensures predictable delivery of a working product and enables you to quickly discover and correct
issues.
− Continuous deployment. Automating and streamlining the software build process to deploy
solutions automatically into the appropriate software environment each time a build succeeds.
− Continuous improvement. Learning from previous delivery cycles of a solution by receiving
actionable feedback enables an agile approach to changing market circumstances and staying in
tune with the needs of customers.
Page 1
The increased expectations of solutions put into production forces teams to be able to detect and resolve
issues in production quickly, measured by two KPIs1, called Mean Time To Detect2 (MTTD) and Mean Time
to Recovery3 (MTTR).
On top of having great tooling support to detect, analyze and resolve issues in production quickly and
reliably, the evolution of ALM processes that deliver solutions in cloud environments has also influenced
the way that architectural modeling is performed.
One area of particular importance to large scale software architectures, especially in the cloud era, is
resilience modeling and analysis. Planning and testing your solution to be both available and resilient to
failure. Both activities are key to delivering a great user experience and ensuring your solution will be able
to live up to its potential, even in the face of failure. Practicing resilience modeling and analysis support
business objectives by having a reduced functionality solution providing value between the moment of
failure and the point of full recovery.
In addition, new ALM processes require tight integration and coordination between IT operations and
software development teams. This requirement has resulted in the broad adoption of a new philosophy
called DevOps.
DevOps is an evolved way of delivering software solutions in which teams involved in delivering and
operating the solution work closely together to meet business goals. In this context, development teams
and IT operations integrate and work closely together throughout the lifecycle, from planning, through
development and release, up to and including operating the solution. This integrated approach is crucial
to long-term success because it promotes a shared thinking about business value and allows for
continuous feedback between the development and IT operations functions.
This paper highlights both considerations and opportunities for devising an ALM strategy in the cloud era.
The paper also reviews the technology options that are available, including those from Microsoft and the
open source community.

1 Wikipedia, Key Performance Indicator, IT Operations
2 KPI Library, Mean Time To Detect (MTTD)
3 Wikipedia, Mean Time To Recovery
Page 2
Business benefits
As their name implies, software developers have mostly been involved in developing software solutions.
The responsibility for the infrastructure that solutions were deployed on as well as the availability of the
solutions was the task of another organization, IT operations. This separation is fairly common and often
results in limited involvement of the IT operations team until very late in the project lifecycle. Because IT
operations personnel need to define and develop requirements for effectively operating the solution,
involving them late in the lifecycle is clearly not ideal and could create unnecessary delays and rework
costs.
By adapting or adopting approaches such as continuous delivery and practicing the DevOps philosophy,
development and IT operations activities can be streamlined, lowering the total cost of ownership (TCO),
decreasing time to market, reducing the scope of change, increasing customer satisfaction, and reducing
production risk by minimizing the Mean Time To Detect4 (MTTD) and Mean Time to Recovery5 (MTTR).
The increasing number of software platforms and infrastructure platforms that expose application
programming interfaces (APIs)6,7,8 provide the means to automate many aspects of ALM. Taking
advantage of the proliferation of APIs can provide a number of benefits, from speeding up development
and testing to reducing risk from human error.
With the introduction of cloud platforms, organizations are empowered to establish development and test
environments with reduced lead time and cost, while the cloud platform APIs provide additional value to
enable consistent provisioning of these environments. Enterprises can incorporate this capability into their
overall ALM strategy and see the benefit of increasing team productivity from project start to delivery. In
engagements with customers, Microsoft has observed that these capabilities and benefits often result in
increased team confidence in their solutions. Teams now have greater agility in terms of releasing new
versions of their services that are built atop cloud platforms.

4 KPI Library, Mean Time To Detect (MTTD)
5 Wikipedia, Mean Time To Recovery
6 www.programmableweb.com/.
7 Microsoft, Manage Microsoft Azure Active Directory by using Windows PowerShell
8 Wikipedia, definition of Application Programming Interface (API)
Page 3
Components of an ALM
strategy
A solid ALM strategy includes practices that help enable the organization to deliver higher quality
products at lower cost and with more agility.
Continuous delivery builds on the historical approach to ALM by streamlining the production process
while DevOps makes its way to center stage, helping to enable a faster pace of deployment and reducing
operational friction between teams.
Continuous delivery
Today it has become imperative for development teams to ensure they can deliver value to their
customers quickly and reliably,9 learning by releasing continuously in small increments. Continuous
delivery10 is an approach in which a number of techniques work together to ensure new features and fixes
are delivered in a timely and predictable fashion at low risk and with a minimal need for manual
intervention.
Continuous delivery helps ensure you are building the right solution as your stakeholders have insight
into what they are receiving at any time, which allows you to pivot your approach if necessary.
Fundamental aspects of continuous delivery are:
▪ Automation. Reduce costly and error-
prone manual intervention for building,
testing and deploying processes, enabling
consistency and increasing integrity and
efficiency throughout the lifecycle.
▪ Continuous integration11. Enable a
constant development feedback loop to
reduce integration efforts and help ensure Figure 1. Continuous value delivery
a stable solution.
▪ Continuous deployment12. Enable a deployment loop after each build to reduce the time to push
out enhancements and defect fixes as a way to provide more stable releases.

9 Forrester, The Top 10 IT Service Management Challenges For 2013 — But What Did You Achieve In 2012? Dec 2012
10 Jez Humble / David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
Automation, ISBN-13: 978-0321601919
11 Martin Fowler, Continuous Integration, May 2006
12 Eric Ries, Case Study: Continuous deployment makes releases non-events, Jan 2010
Page 4
▪ Continuous improvement. Collect usage telemetry that allows your teams to understand the next set
of investments that is new features, discoverability of features, critical technical debt or deprecate
unnecessary services or features.
Automation

Automation reduces the potential for human errors across the development process. It supports a
predictable and repeatable process of building and releasing a solution while increasing the speed at
which this can be achieved.
Because increasing numbers of APIs are being exposed by services, devices, and infrastructure, there are
many opportunities to take advantage of automation.
Infrastructure automation
Infrastructure automation delivers automatic provisioning and configuration of standardized
environments that consist of the various components of a specific solution, such as compute, storage, and
identity. This automation dramatically reduces lead time in infrastructure acquisition and provisioning for
the development team while building trust between developers and IT pros through ensuring the
development team adheres to corporate standards. If used to provision duplicates of solution
dependencies such as ERP or CRM instances, infrastructure automation can also remove the planning
efforts and associated lead time often involved with testing solution integration.
Deployment automation
Setting up the environment to automatically deploy the latest build on a given schedule or in a
continuous manner allows tests to be automated and enables project stakeholders to always see the
latest version of the solution in development. Deployment automation should ensure the environment
ends up in a state that reflects what is desired in production. It should include deploying all elements that
are part of the solution, such as databases of relevant data, configuration of external product
dependencies, and authentication.
Test automation13, 14
Given the available studies15 and anecdotal evidence16 about the cost of software defects and the
potential impact of these defects,17 testing is a necessary aspect of software development.

Tests enable the development team to continuously validate they are delivering the expected quality, help
them avoid regression defects, and ensure they continue to meet requirements.

13 Gartner, Best Practices in Agile: Accelerate Development with Automated Testing, May 2012 (subscription required)
14 Microsoft, Automating System Tests, Aug 2012
15 National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software
Testing, May 2002
16 Bloomberg, The Big Cost of Software Bugs, Aug 2012
17 National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software
Testing, Paragraph 1.4.1, May 2002
Page 5
By running tests (unit tests, module tests, integration tests, functional tests, and non-functional tests such
as load and performance tests) as part of an automated cycle, you ensure that tests can be executed
quickly and that they are repeatable. Running tests as part of a continuous cycle helps to find defects
earlier18 and fixed usually at significantly lower cost19,20 than when discovered later in the lifecycle.
Repetitive and complex task automation
As solution complexity and scale increases, managing systems in a manual fashion is no longer an option.
Automation of repetitive and complex tasks such as creating databases, loading reference data, and
setting permissions for folders allows for reduced human error and shorter delivery time while increasing
the stability of the solution development process.
All of these automation elements work together to ensure that each change within the solution is tested
before being deployed into production. This continuously repeating process increases the level of
confidence in the deployment process for both the development and operations team.
Continuous integration
Components that are developed by different members of the development team often have
dependencies on each other. Ensuring that they integrate correctly is vital to a successful result; if
development efforts grow too large, defects can occur that can be hard to triage and hinder project
progression.
As developers work on the features or changes to the solution they set out to implement, they do so
independently of others, taking the current code base as a starting point. As other developers commit
their changes to the repository, this code base over time no longer reflects the repository. The longer a
developer works in isolation, the bigger this disconnect becomes. When finally merging changes back into
the shared repository, this can be a time consuming task and pose a risk for the stability of the code base.
Continuous integration21 is the practice of merging all developer work into a shared repository at a
frequent pace. It enables teams to catch integration issues quickly and deliver working solutions of higher
quality more rapidly. Depending on the size of the project team, your organizational experience with
setting up continuous integration, and the amount of time allocated to enabling it, you could use a
phased approach in which build automation, unit test automation, deployment automation, and
integration test automation are introduced in an incremental manner.
Continuous deployment
Continuous deployment is a process by which software is deployed continuously, possibly even several
times throughout the day, in iterations measured in minutes as opposed to days, weeks, or months. Based

18 Martin Fowler, Continuous Integration, May 2006
19 National Institute of Standards and Technology, The Economic Impacts of Inadequate Infrastructure for Software
Testing, Table 1-5, May 2002
20 Barry Boehm, EQUITY Keynote Address, March 2007
21 MSDN – Build and Deploy Continuously
Page 6