1. DevOps Offerings Datacenter Operations
Andrew Weiss
Kathleen Wilson

2. Trying to adopt Agile and DevOps using old techniques
DevOps Challenges
Trying to adopt Agile and DevOps using old techniques
No clear roles and responsibilities for staff
Organizational resistance to the cultural shift
Lack of automation
Inability to collaborate Development and Operations

3. DevOps Offerings Overview
11/11/2018

4. DevOps Engagement Scenarios
DevOps Envisioning Workshop (IT-BDM)
2 Days
DevOps Jumpstart
4-6 weeks
The DevOps workshop provides an overview on what needs to be considered when making the shift to adopt DevOps as a culture. This workshop will focus on cultural shift needed to adopt DevOps. Key DevOps terms will be shared and the outcome of this workshop is to define the Customer’s current challenges around adopting DevOps and provide a roadmap on how to adopt DevOps, leveraging our Devops Jumpstart.
This workshop will cover:
What is DevOps?
Challenges that Operations and Developers currently face
Gaps to address before moving to a DevOps culture
Management of Change
Appropriate Audience – IT BDM, Service Owners, TDM Administrators
Outcomes
Understand what is DevOps, it is not tools but a cultural shift
Current state of Operations and Development
Next steps and a follow-on statement of work for DevOps Jumpstart
The DevOps Jumpstart provides prescriptive guidance on how to adopt a DevOps culture. This Jumpstart will define the processes, policies and roles needed to commence the cultural shift needed to adopt DevOps. Develop and deliver the Operations Framework for the Management of a hybrid Azure environment. Integrating the people, process and technology to manage and maintain your Cloud based Service.
Define the operational processes, roles and responsibilities necessary for DevOps
Share a DevOps focused change and release management process
Share a Release Readiness review checklist
Guidance for Developers to support Operations during releases
Polices to support DevOps
Guidance for weekly DevOps review meetings
Monitoring guidance**
Introduce the concept of Service Support and lifecycle management
Standard change definitions for DevOps
Appropriate Audience – – IT BDM, Service Owners, TDM Administrators
Outcomes
Knowledge transfer, management capabilities to support a DevOps culture
Technology hrs
Visual Studio online environment
Unit testing, knowledge transfer
ALM – “Agile”
How to manage features, bugs, tasks
Integration possibilities for “Open Source” – possibility a whitepaper

5. What is DevOps?
DevOps represents a shift in the way business, IT, and development groups do their work and think about operations
It extends agility to operations teams through people, process, and technology
Fosters friction-free collaboration
Brings operations teams into the mix that agile organizations have with their business and Dev/Test teams
Fosters/encourages new ideas and seeing failure as a valuable learning opportunity
DevOps is a philosophy that represents a shift in the way business, IT, and development groups do their work and think about operations
It is a way to extend agility to operations teams through changes in people, process, and technology
DevOps is primarily about friction-free collaboration
Supports strong application test practices, faster application releases, fewer critical issues in production, better insight into what is happening in all environments
Agile movement that covers aspects of the business, test and development, and operations
Brings operations teams into the mix that agile organizations have with their business and dev/test teams
It is also about fostering/encouraging new ideas and seeing failure as a valuable learning opportunity
11/11/2018

6. Not a single product, process or solution
What DevOps is not
Not a single product, process or solution
It is not merely agile but rather enables agile
Not a rebranding of existing teams
Does not mean you need to create new “DevOps teams”
DevOps does not represent a takeover and re- engineering by management
Not a buzzword or a trend
It is not a silver bullet
DevOps is not a single product, process or solution
DevOps does not merely equal agile but rather enables agile
DevOps does not refer to a rebranding of existing teams
DevOps does not infer a requirement to create new “DevOps teams”
DevOps does not represent a takeover and re-engineering by management
The word “DevOps” itself is not a buzzword or a trend
DevOps is not a silver bullet
11/11/2018

7. Guidance Links
DevOps Culture kavis-enterprise-devops-challenges-bringing-change/ Phoenix Project – Gene Kim book/ Microsoft DevOps blog
11/11/2018

8. DevOps Envisioning Workshop

9. Pre-Engagement Assessment Need to know where the Customer is
Assessment is Key
Pre-Engagement Assessment
Need to know where the Customer is
Need to know ALM
Core concepts of Cloud computing
Azure is a good pull through What tools support DevOps
** this is new for everyone, you need to drive the conversation with the Customer and get them sharing their challenges

10. DevOps Envisioning Workshop
Assessment of Customer’s current state
Knowledge Transfer on Microsoft’s vision for DevOps
Understand the challenges in adopting a DevOps culture
Define a future state for DevOps
DevOps Envisioning Workshop
Workshop Goals

11. Agenda for the 2 days Microsoft practices & guidelines for DevOps
1. What is DevOps?
Share Microsoft’s vision of DevOps
2. DevOps Guidance
Microsoft practices & guidelines for DevOps
3. Organizational Impact
What is the impact for an IT organization adopting DevOps
4. Current State Identifying the current state of DevOps
5. Future State
Envisioning and scoping of the future state of DevOps.
3. DevOps Guidance
Microsoft practices & guidelines for DevOps
11/11/2018

12. DevOps Jumpstart
11/11/2018

13. DevOps Jumpstart 5 week engagement 2 skill sets needed to deliver
IT Service Management role
DevOps/AppDev role/Infrastructure role
Focus is on starting small, one Service/Application for DevOps

14. DevOps Jumpstart Goal
The goal of the Jumpstart is provide prescriptive guidance on how to integrate the people, process and technology needs to adopt a DevOps culture

15. Jumpstart Phases People Process Technology Service Map DevOps RACI
DevOps Role Guidance
DevOps Process Guidance
ALM Process Guidance
DevOps Release Readiness Review
Visual Studio Online – guidance
Application Monitoring with SCOM 2012 R2 & Application Insights
Delegation Model
People
Process
Technology
11/11/2018

16. Service Mapping
A graphical representation of a service, its dependencies, and the settings needed for the service to function Facilitates decision making Business impact analysis Understand who is responsible for what?
Settings
Software
11/11/2018

17. DevOps RACI
Provides a clear overview of the DevOps Roles and responsibilities Tasks are built out to support the DevOps lifecycle to accommodate the activities needed to perform DevOps
11/11/2018

18. Role Mapping Guidance for DevOps
Cloud
Architect
Operations
Manager
Service Delivery
Reliability Manager
Service
Tenant
Owner
Workload
Service Consumer
Role Mapping Guidance for DevOps
End User
Application Lifecycle - DevOps
Developer
Deployer
Tester
Operator
Author
business analyst / SME
product owner
Developer Lead
Program Manager
Release Manager
QA Lead
Platform
Platform Admin
Fabric Mgmt
Admin
Fabric
Fabric Admin
This slide share the existing Cloud OS roles and how existing roles can leveraged for DevOps. New roles have been introduced due to the changes in accountabilities and responsibilities as describes in the previous part of the slide deck. The next slides will explain this in more detail.
Cloud Architect:
Manages roadmap for supporting cloud technologies.
Determines impact and approach for non-standard changes or new functionality within the private cloud.
Accountable for cloud architecture and used principles that creates the private cloud.
Reliability Manager:
Accountable demand & supply at cloud level for elastic use of fabric and shared resources.
Manages monitors and thresholds regarding availability, capacity, security and compliancy.
Manages relations with third parties regarding support and demand
Accountable for right implementation security and compliancy policies.
Operations Manager:
Coordinates and handles incidents.
Manages data model within CMDB and runbooks within orchestration.
Accountable for the service operations within the Fabric.
Creates, tests or coordinates the creation of new runbooks, service requests and scripts.
Identifies new operational runbooks.
Manages monitors and thresholds regarding health and configuration.
Service Manager:
Accountable for service delivery towards the different tenants.
Primary contact point for Service Consumer organization.
Monitors and communicates pay-per-use costs to tenants owners.
Manages and communicates Service Level Agreement (as part of the Service Description) and monitors service levels.
Manages and communicates Service Description towards tenants.
Entry point for information and non-standard requests.
Tenant Owner:
Responsible for creating workloads within the tenant and managing workload owners to them.
Budget Owner for entire tenant and so responsible for approving quota within the Tenant.
Accountable for a tenant. A tenant can be business unit or external customer.
Workload Owner:
Manages quota for workload.
Manages users within the workload (see next slides).
Accountable for a workload, application or service within a Tenant.
Approves changes within production environment.
Manages Service Catalog for workload.
Developer:
Develops and changes application(s) within the workload.
Tester:
Tests functionality, modules, performance, etc for application(s) within a workload.
Author:
Share, test & deploy (custom) resources within development environment.
Package software builds from the developers into one or multiple service templates.
Extends available Service Provider resources (building blocks) for within workload.
Manages Service Accounts for applications.
Deployer:
Provisions service template(s) from workload resources into test environment.
Provisions workload service(s) from service catalog into acceptance and production environment.
Updates running workload instance(s) in acceptance and production environment.
Operator:
Performs day-to-day operations for workload application(s).
Manages monitoring for workload application(s).
Platform Administrator
Accountable delivering building blocks for tenants to use.
Responsible for creating and maintaining support conditions and cookbooks.
Responsible for creating and maintaining service templates or virtual machine templates for Service Consumer organization.
Accountable for life cycle management of building block (Win OS, SQL, SharePoint, etc.).
Responsible for patching according to service description.
Supports operations manager with incidents and changes.
Ensures health and performance of provisioned building blocks according to the service description.
Fabric Administrator
Accountable for subdividing the cloud fabric into virtual machine management clouds, which are logical groupings of cloud resources that can be assigned classifications, hypervisor capabilities, capacity limitations, scalability and optimization configurations, based on requirements managed by the cloud architect, service manager and reliability manager.
Accountable for administrating the cloud fabric, so the interconnected system of hardware, storage, and network to support and maintain the cloud fabric.
Plans for facility & hardware failures and maintenance.
Ensures optimal health and performance of the cloud fabric.
Accountable for patch management fabric.
Supports operations manager with incidents and changes
Fabric Management Administrator
Accountable for user management within the cloud solution.
Accountable for administrating the fabric management tooling, which consists of monitoring, provisioning, orchestration, identity, security, registration and back-up & recovery capabilities.
Accountable for back-ups and recoveries according to service description.
Accountable for patch management within the fabric management (and workloads if necessary)
Ensures optimal health and performance of the fabric management
11/11/2018

19. DevOps Processes
Processes are required to develop and operate the different services according the agreed service levels. DevOps processes are highly automated integrating technology, functionality and ITSM activities. The process flows include phases, actors, activities and future automation capabilities
11/11/2018

20. ALM Process – DevOps approach
Focus on Business Value.
Business hypothesis
Define
Build QA
Release
Measure & Evaluate
Continuous Integration.
1 to 3
months
Automated Release Pipeline.
Integrated Operations Management.
This slide presents the core characteristics of a modern ALM process combining benefits of the Continuous Delivery process and DevOps mindset.
The following elements could be adapted to reflect the customer future state :
Name and duration of each phases and cycle
Focus on Business Value
The DevOps organizational mindset aims at focusing all cross-team collaborative ALM activities on providing value to the customer by either:
Shortening Time To Market
Increasing Market Shares or Revenue
Insuring regulatory compliance
Continuous Integration
It constitutes the foundational capability of the modern ALM Define & Build phases, by which new small-size defined feature derived from prioritized business hypothesis, as coded by developer and integrated into a central code trunk are automatically built as binaries and unit-tested in short cycle, maintaining the source code basis in an integrated state with a known level of source code technical quality.
Automated Release Pipeline
Subsequent steps of the modern ALM QA & Release activities will promote those newly built features as Minimum Valuable Products (MVPs) that can be quickly and progressively shipped to production through a coordinated cross-team release process with a good level of confidence on its functional and non-functional correctness, with minimized manual intervention and service interruption.
Integrated Operations Management
Those MVPs are then monitored and evaluated in the ultimate proof environment of production: giving rise to new actionable operation backlog in the event of malfunction as well as experimented knowledge of its true value.

21. DevOps Release Readiness Review
In order to build an organization of trust, it is recommended to perform a release readiness review to ensure that Development and Operations can trust the velocity of change needed for Dev Ops and the appropriate due diligence on each release is performed
11/11/2018

22. Visual Studio Online Guidance
How to leverage Visual Studio online to perform DevOps and manage releases. Microsoft will provide prescriptive guidance on how to use Visual Studio Online
11/11/2018

23. Application Monitoring
11/11/2018

24. Delegation Model
The delegation model provides a clear overview how DevOps roles will be integrated into the tools used for ALM & DevOps. The delegation model aligns the RACI output into the tools and responsibilities per role.
11/11/2018

25. Thank you

26. Contact Kathleen Wilson Architect WW Datacenter COE +1 289 305 9290
© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows operating system, Windows PowerShell command-line interface, and Windows Server operating system are trademarks of the Microsoft group of companies. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. 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 provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION