Comspark 2018 Presentation - The Extinction of legacy IT
•Download as PPTX, PDF•
0 likes•37 views
Presentation deck delivered at comSpark Cincinnati 2018 on the extinction of legacy IT (or modernization of IT needed for digital transformation)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Comspark 2018 Presentation - The Extinction of legacy IT
Similar to Comspark 2018 Presentation - The Extinction of legacy IT (20)
Recently uploaded
Recently uploaded (20)
Comspark 2018 Presentation - The Extinction of legacy IT
- 3. Digital Disruption and the 4th Industrial Revolution 1780s 1870s 1970s 2015+
- 4. 86% of CEOs consider digital as their #1 priority 86% 69% 58% 39% 28% Technological advances Demographic shifts Shift in global economic power Resource scarcity & climate change Urbanization TRENDS THAT WILL TRANSFORM BUSINESS OVER THE NEXT 5 YEARS Source: PwC CEO Survey 2016
- 5. Leading the digital transformation charge You have an unprecedented opportunity to lead digital transformation for your organization. Digital companies generate $100M more in operating income each year By 2017-18, 30% of businesses will have begun monetizing their information assets $100M 30%
- 6. Started with notion that the value of cloud services (speed, agility, innovation, cost, security) is often negatively impacted by existing/legacy enterprise IT processes and practices (Legacy doesn’t work) (William Stanley) “Jevon’s Paradox” applies to Cloud Demand as it did to coal in the 1800’s- Increases in efficiency/lower cost of a given resource drives greater demand (not less) as new and innovative uses evolve and become available (Innovation) Organizations who detect “Control” and “Transparency” in cloud leverage cloud more as they connect the benefits and value of cloud to its transparency and control (> Control than on-prem)
- 7. Faster business innovation through adoption of cloud services+ Innovation Efficient use of public cloud scale Business agility and reduced time-to- market through efficient DevOps teams - Cost + Speed/Agility + ControlSecure, predictable and flexible service delivery and operations capability
- 8. Characteristic Legacy IT Modern IT DNA Intermediation Disintermediation Service Delivery Wave Based Continuous-Iteration Based Lifecycle N-1 and older N, N+1 etc. Service Stability Design for Success (HA/Redundant) Design for Failure (Resilient) Delegation Levels IT Silos (Technical, Lifecycle) End-to-end Services, Applications Processes In documents, optimized, manual, redesigned Self-Service, Knowledge, Low friction, automated, leaned Automation Isolated, manually initiated, limited Systemic, triggered, automation, pervasive Monitoring Element, fault focused Service, end-to-end capability focused Failure response KPI Time to restore service Time to detect + identify + remediate and eliminate Configuration / Asset Management Discovered / Manual Prescribed / Declarative, Automated Self Service Portal based App-aligned, Artificial Intelligence augmented Support Service Desk, Contact Center, Ticketing Customer experience, AI and telemetry insight infused
- 9. Past Long application cycles Monolithic apps Servers and VMs Less data Desktop Distinct infrastructure and operations teams Today Rapid innovation Loosely-coupled apps, microservices, and containers Serverless Big Data Mobile Service-focused DevOps teams CaaS Container Platform On-Premises Infrastructure Platform PaaS Application Platform FaaS Serverless Platform IaaS Infrastructure Platform “lift & shift”
- 13. Shorten cycle times and deliver value faster Improve quality and availability Optimize resources and eliminate waste Deliver innovation with digital-era velocity
- 15. Source: 2017 State of DevOps Report presented by Puppet and DORA
- 16. “DevOps is development and operations collaboration” “DevOps is treating your infrastructure as code” “DevOps is using automation” “Kanban for Ops?” “DevOps is feature switches” “DevOps is small deployments”
- 17. ++ ++ ++
- 19. Customer Focused
- 23. and for the complete lifecycle Data Internal or external data including security and privacy Application Custom Application or Consumer Off the Shelf (COTS) Application Infrastructure From the marketplace or a deployment template managed by central IT responsible for application Team Autonomy and Enterprise Alignment
- 24. Team Autonomy and Enterprise Alignment
- 25. Team Autonomy and Enterprise Alignment
- 26. Traditional (Pre-DevOps) Product Management Development (including specialist skills like database) Testing Deployment and Support DevOps Product Management Engineering Ops Feature Team Customer 1 min Team Autonomy and Enterprise Alignment
- 29. Customer Focused Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource
- 30. Infrastructure as Flexible Resource
- 34. Zero business disconnect (led by, integral to) Loosely Coupled (4) Systemic automation (2) “Vertical” service delivery and operations (3) “forever” current (no upgrade burden) True pay per use “Instant” and “infinite” capacity Compliant Continuous service availability Business value (< TTM, < Cost, > Agility, > Flexibility, > Reliability) have solved using which require facilitated by resulting in 1. Implement in parallel to existing organization (Multi Speed Mode) 2. Requires HR involvement / career development and talent management 3. Biz(Dev)Ops, which requires executive/management buy in 4. Requires application assessment / modernization. Start with “Adaptive Applications / Beat the Competition”. 5. Requires Adoption and Change Management Cultural change Shift Left in governance (architecture, audit, service management, etc..)
- 35. Web SiteDatabase Virtual Machine Storage RESOURCE GROUP Deploy, manage, and monitor all resources as a group, vs individually. Deploy resources throughout the lifecycle in a consistent state (no manual changes) vs varying state (manual and per environment varying changes/deployment) RESOURCEGROUP RESOURCEGROUP RESOURCEGROUP RESOURCEGROUP Manage resource through declarative templates rather than scripts Deploy resource in correct order using defined dependencies between resources vs dependencies maintained in a separate db or discovered afterwards Apply platform integrated role based access control to resources in a resource group vs enterprise wide admin access to all resources RESOURCEGROUP RESOURCEGROUP Apply tags to resources e.g. to clarify billing by viewing costs for a group of resources sharing the same tag vs central IT budget covering all resources #tag1 #tag1#tag2 #tag2
Editor's Notes
- OLD WORLD Information scarce Static hierarchies Siloed productivity Customers Focus on planning ahead Transactional Systems NEW WORLD Information abundant Dynamic networks Collective value creation Brand Ambassadors Experiment, learn and respond Systems of Intelligence
- It's therefore not a big surprise that technology is the #1 priority for CEOs. In a recent survey, 86% believed technology would transform their business more than any other global trend in the next 5 years. Digital Transformation is a hot and rapidly evolving topic. CxOs now realize that Digital Transformation is inevitable and mandatory, with 86% of CEOs considering digital transformation their number one priority. However, without a doubt, many enterprises struggle with how to do it and where to begin. Enterprise companies frequently have complex infrastructures, support multiple platforms and have different types of data as well as customized applications. Many have employees that are spread across different geographies, cultures and languages. There are a lot of moving parts to consider. Transition: Microsoft is no exception – the digital transformation has been a journey for us. One we have started on years ago, allowing us to now share our experience and innovation and providing some perspective as to how our leadership has embraced it.
- 90% of recorded data has been generated in the last 2 years
- Microsoft’s own IT organization asked itself; What would it look like if Microsoft business units procured cloud services directly from cloud providers (Azure Office 365)? What services would business units still be willing to pay for? Resulted in the transformation of MSIT to Core Services Engineering. Go look at their public website- they have become brokers of innovation for Microsoft rather than being traditional IT organization. William Stanley Jevons FRS (/ˈdʒɛvənz/;[2] 1 September 1835 – 13 August 1882) was an English economist and logician. It was for The Coal Question (1865), in which he called attention to the gradual exhaustion of the UK's coal supplies, that he received public recognition, in which he put forth what is now known as the Jevons paradox, i.e. that increases in energy production efficiency leads to more not less consumption.
- The reason for businesses to use public cloud services are: innovation, cost and agility. Public cloud services take several forms, with Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and now Containers as a Service (CaaS) managed by Kubernetes. Often a combination of services are utilized to minimize cost, provide agility, and provide innovation as part of a digital transformation initiative. As microservices architecture are becoming increasingly adopted, the trend to supporting multiple operating systems and languages is increasing. The Microsoft DevOps story will support nearly any combination of processes and tools in the marketplace. Present the 3 items in the center as the focus of what Businesses want, then discuss left to right on the slide. Cultural transformation for the organization and buy in at all levels will be crucial for success. Remember “Culture eats strategy for breakfast.” See https://enterprise.microsoft.com/en-gb/articles/digital-transformation/creating-the-right-company-culture-for-digital-transformation/ from the UK team for a good point of view. Ask the customer what their point of view is. This slide is a great opportunity to engage.
- Legacy Apps Monolithic - Built as a single unit with few separate services or components. Any services which are used tend to be custom built for the App. Tightly Coupled - Tend to have internal and external dependences that impact both reliability and development agility. Long Delivery Cycle - Slow to test, deploy, and scale. Making iteration difficult. IT Dependent - Dependent on long lead time bare metal provided by IT. With complicated patching and update process. Internet Apps Service Oriented - Build modularly using packaged middleware, common services, and service oriented architectures (SOAs). Loosely Coupled - Technology like messaging stacks and queues used to disintermediate apps. Management and diagnostic tools integrated into Apps. Agile Delivery - Dependency management and disintermediation allows software to be built incrementally. Shortening delivery times from years to months. Virtualized - Software hosted on virtualized infrastructure that reduces IT dependencies, improves delivery time, and simplifies update process. Cloud Apps Cloud Based Service - Applications built using application programming interfaces (APIs), software as a service (SaaS) Services, and independently scaling Microservices. With custom code only needed for core business logic. Distributed - Applications use cloud services and APIs, further disintermediating tiers. Often making use of on demand services that are not instantiated when not in use. DevOps - Continuous Integration, Continuous deployment, and Testing in Production used to shorten delivery and scale times from months to days or hours. Platform Based - Applications written to platform as a service (PaaS) or infrastructure as a service (IaaS) based cloud platforms. Reducing scale times to minutes or even seconds and simplifying the patching and deployment process. Acronyms CaaS: containers as a service FaaS: framework as a service VM: virtual machine
- Azure Functions and AWS Lamda is what people think of when people are talking about Serverless computing. But there are lots of services that are “Serverless” Event driven Per Request Execution – paying for transaction vs. reserve capacity. Underlying containers (not docker) strive for stateless architecture. Options in these serverless that allow you to manage state. Azure Functions (if you have multiple functions) easy to scale out. Focus on writing code – DevOps focus on Dev, Ops gets reduced.. Monitoring focus. On-demand scale ~ variable costs vs. fixed cost. Does functions equate to a microservice? Function represents a task vs. a microservice as an app.
- Engage with customer. Discuss existing challenges. This slide is intended to discuss some of the challenges the IT organization is currently facing which hampers the focus on delivering business value quickly, reliably and cost effectively. Infrastructure typically built using building blocks and stacks that evolve over time, individual applications deployed / configured using these building blocks. Result: fragmented intertwined infrastructure that is hard to keep up to date (lifecycle management). Once deployed, the configuration changes can be or are made in production environments (for example: by Technical Application Support) without going through development, test, accept cycles and without updating deployment documentation/scripts. Applications are often using shared resources where there is no clear ownership; this makes lifecycle management hard. Some Virtual Machines just keep running because IT just doesn’t know if and who are using them anymore. Disaster Recovery (DR) is often based on complete site outage. This makes DR testing hard. Business Units often want to run their own DR tests for each Business Domain/Process. Long running wave-based projects are needed to design and implement infrastructure that fulfill the functional and non-functional application specific requirements. Sizing is often based on peak performance needed, once sealing is reached scale up is often the only way to increase performance. Changes required on shared infrastructure (e.g. storage, network) often cause required down time, this makes it hard to schedule these changes in slots that the business allows this downtime. Therefore a lot of the microcode, firmware and software is running out of support and isn’t patched fast enough potentially resulting in an unstable, unsecure environment. This slide as an opportunity to discuss the differences between the Snowflake and Phoenix-style provisioning models in IT. It allows the speaker to bring in customer examples of the challenges outlined and will make the conversation flow more naturally. Read this article for reference in advance: https://devops.stackexchange.com/questions/49/what-are-the-pro-and-cons-of-snowflakes-servers-phoenix-servers-and-immutable-s
- Engage with customer. Discuss existing challenges. Some good questions to ask: How often do you deploy software to production? Is deployment a relative routine event? List the challenges as individual points and then draw the conclusion that increased collaboration in all areas (from governance to release) will break down barriers and produce quick cycles and stable increments.
- What are the main areas IT can improve upon in order to deliver more business value Agility Quality Costs Optimization Flexibility and Innovation
- Source: 2017 State of DevOps Report presented by Puppet and DORA 2017: Over the past six years and more than 27,000 DevOps survey responses, with companies of ALL sizes and verticals. Employees in high-performing teams were 2.2x more likely to recommend their organization as a great place to work. (2016 – employee Net Promoter Score) 2017 key findings: Transformational leaders share five common characteristics that significantly shape an organization's culture and practices, leading to high performance. The characteristics of transformational leadership — vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition — are highly correlated with IT performance. High-performing teams continue to achieve both faster throughput and improved stability. Automation is a huge boon to organizations. DevOps applies to all organizations. Loosely coupled architectures and teams are the strongest predictor of continuous delivery. Lean product management drives higher organizational performance.
- DevOps has different meanings to different roles in an organization. Some feel that it is a buzz word; others are more informed. Our intent is to share with you what being more agile and responsive means to your role, what has to change, what remains consistent. Ask the audience this same question and note responses.
- Microsoft has been on a multi-year DevOps journey and we would like to share some of our experiences During our DevOps journey we learned about five key habits. We’ll talk about each one in more details. Most of these are Agile++, such as being customer focused, having team autonomy and enterprise alignment, and shift left. Then we have a set of habits that are particular to a DevOps mindset, such as production first, and infrastructure as flexible resource.
- There are a services of hidden slides for each the topics below. Reference as needed Listen to your customers: Leverage a variety of tools to capture the voice of your customer. Examples are Microsoft Teams, UserVoice, stackoverflow Enterprise, and Slack. Collect application telemetry: Leverage native cloud services like Azure Application Insights and its powerful search and query analytics tools. Identify and measure KPI’s which are important for customers: Using the data, we track key performance indicators, or KPI. We track our engineering process VELOCITY. We want to keep the lead and cycle times to push a feature or fix an issue as short as possible, and the collection and analysis of telemetry as efficient as possible. We don’t track things like original estimate, lines of code, capacity, and number of bugs found. It adds no value to your customer. Develop dashboard to keep stack holders and teams informed. Develop customer focused hypothesis to maximize learning and value: (We believe {customer/business segment} want {product/feature/service} because {value proposition}) Continuously practice build, measure, learn. Every hypothesis has a delivery cycle and is validated as PROVEN, DISPROVEN, OR INCONCLUSIVE. Key is to run and learn from as many experiments as quickly as possible, to maximize learning and influence the value you’re delivering. Fine tune customer experience with feature flags: We ship features every 3-weeks and bug-fixes daily, sometimes multiple times a day, in production. We use feature flags, which are if-else statements, to progressively expose, enable or disable features, in production for everyone or selected users.
- There are a services of hidden slides for each the topics below. Reference as needed Live Site Incidents (LSI): Applications running in production are constantly monitored and when problems are detected or reported, an incident response team for the application is contacted. If needed the on-call DRI team for the application is contacted. The DRI will team will often have both the Dev and Ops on-call team for the application notified. Data is gathered to identify the root cause of the issue, and a mitigation developed. If this an issue with the application code, a priority bug is created by LSI team, and application team will develop and deploy a solution for the issue in an upcoming sprint. DRI = Directly Responsible Individual Be Transparent: Any Live Site issues, root causes, and solutions are documented and made available to impacted customers. Transparency is not easy, but it builds empathy and trust! Alerting is the key to fast detection: Work to make every alert actionable and have it represent a real issue with the application. Work to have zero false alerts, and enable alert auto-notification of DRIs. You don’t want alerts to be like a neighbors car alarm being triggered with every passing car or squirrel – you will ignore them. Completely automate all deployments: All scripts are checked into source control, no one-time commands are run manually, if you need to run a command, create a script, check it into source control and incorporate into your release script. Every infrastructure and application is the same from pre-production, canary, and production. The only changes are configuration so the appropriate data is accessed. Everything is orchestrated with your release management tool (i.e.; VSTS) Track deployments in production: Every deployment (canary, ring1, global) is tracked and monitored in the release management tool. A ringed deployment model helps issues be detected in an earlier deployment ring, where it is easier to resolve. Circuit breakers to limit impact: Design your application so you can manage service dependency failure, latency tolerance, and fault tolerance logic. Security mindset: Bring people in to perform penetration testing of your application and systems. The Red team are the attackers, and the Blue team are the defenders. Be proactive, learning, and sharing the lessons learned.
- Right, next we’ll have a look at Team Autonomy and Enterprise alignment.
- This slide illustrates the different parts which needs to be united. People: Both Developers and Operations should work together in one team Process: All processes through the complete lifecycle should be performed by the DevOps team Tools: The team should be responsible for the complete stack from infrastructure, to application to data
- Silos; Cause disconnects and mismatches Interfere with Feedback loops Create labor pools of functional specialists Disjointed silos make meaningful SLOs and shared responsibility almost impossible Siloed labor pools, disconnected processes and tools, and slow feedback loops tend to consume all available capacity Struggling to keep up with demand and unable to protect capacity Queues; How do we cover for our cross-silo disconnects and mismatches? Request queues are an expensive way to manage work. We all know what happens… Hot potato Tickets/queues reinforce siloed behaviors and obfuscate the value stream Longer cycle time, more variability, more overhead, lower quality, and more snowflakes consume available capacity Toil; “Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” -Vivek Rau Google Engineering work builds enduring value, creative, iterative Increases with scale whereas engineering enables scale Can be automated – Engineering requires human creativity Queues and Ticketing leads to low trust. Add up the total number of approval requests and …subtract the info radiators (“I need to be in the loop”) …subtract the CYAs (“Prove you followed the process”) …subtract the too removed to judge (“mostly guessing”) How many are you left with? How many were the right call? How many got rejected? Netflix model – cross-functional teams. Google model – Development Team(s) with SRE
- The cultural transformation needed for DevOps is frequent point where organizations struggle in their DevOps journey. This section has slides to present to the customer. You can decide if you need the details after conversation with the customer. https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/digital-blog/five-cultural-changes-you-need-for-devops-to-work
- Understand that the shift to unite people and process is a big culture shift for many organizations. This is not to be taken lightly. This cultural transformation is a key success factor for DevOps adoption and requires management support at all levels. Microsoft can assist in this transformational journey. See https://cio.economictimes.indiatimes.com/news/corporate-news/gartner-highlights-5-key-steps-to-delivering-an-agile-io-culture/47014075 for some good talking points. Developers: Are responsible for deployments (including testing) and have responsibility for their code in production. Operations: Have to improve the environment and redeploy constantly as well as automating everything through code.
- Let’s look at another new term that has emerged with DevOps … Shift Left. https://docs.microsoft.com/en-us/azure/devops/devops-at-microsoft/shift-left-make-testing-fast-reliable Understanding How to Shift Left (https://devops.com/devops-shift-left-avoid-failure/) The term “shift left” refers to a practice in software development in which teams focus on quality, work on problem prevention instead of detection, and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle—or, worse, in production.
- Bug Cap: One important metric we keep an eye on is the bug cap. It’s based on the number of engineers and you’re allowed 5 defects per engineer. So, if you have 10 engineers in your team, your bug cap is 50. Simple. If you go above the bug cap you go into bug jail and you're not allowed to go into any feature work next sprint. You've got to pay down your defect debt. Shift left from integration to unit tests: Over a period of many sprints, we SHIFTED LEFT, pivoting to simpler tests that anyone could run, anywhere, even in production. We want the tests to be FAST, RELIABLE, and run them with every pull request. Pull requests (PR) are point of code review and testing: PRs enforce code review, L0+L1 tests, various validation scanning, and approvals. For VSTS team, every pull requests triggers more than 70,000 tests, which run in less than 7 minutes. No more “who broke the build” ceremonies and awards – you can break your PR but you’ll never break “the” build again Release flow branching structure: Master branch is the VSTS team’s single source of truth. There are bug, topic, and release branches off main. When the team is ready to deploy, for example M121, we create a new release branch (M121) Hotfixes for live site incidents are created in the main branch and cherry picked into release branches (M121 for example). This ensures that a bug fix is not lost in a future releases. The master branch is always healthy, protected by the pull request process.
- Finally, let’s talk about infrastructure as flexible resource. It’s our next area of maturity where we’re getting better right now.
- The following slides are currently hidden, use as needed to explain concepts. From VMs to Azure DevTest Labs: Gone are the days you drag several laptops, external drives, and a bag of dongles between home, office, and demos at your customer. We have moved everybody’s developer workstation to the cloud. Get you environment in minutes, not weeks as you wait for equipment, a lot more power and scalability, and most importantly consistency. Multiple data centers with incremental roll out: VSTS team moved from a monolithic code base to a service-oriented architecture, allowing us to do data centers with incremental roll outs. We have shared platform services, such as account, identity, profile, and licensing, and regional scale units in Azure There are also have a few services out in containers so far. VMs – PaaS web and worker roles and moving to Containers App tiers – serve web UI, web service endpoints Job agents – background processing like scheduled builds, clean up, commit processing, etc. DB – only metadata in SQL Azure, multi-tenant Blob – file data in Azure Storage Deployment rings allow limited testing in production, so if problems are found, the impact is limited. Health check runs after each ring is deployed Today VSTS has four rings with outer rings having multiple scale units in them Each service has scale units organized in rings Architecture modernization: VSTS team deploys to both on-premises (TFS product) and cloud (VSTS) The team is slowing moving to containers to raise redundancy and scalability, and lower cost. If this was a new application, the team would consider platform as a service, service fabric, azure functions, and ship the same code to the cloud and on-prem.
- Startups have option of being “Born in cloud” Established commercial and governments have to address legacy… Leave current environment as is.. Run new environment to establish new normal. When we leave the new normal is not focusing on modernizing applications – but focusing on business functions in the cloud. There are things you can do in the cloud that you cannot do on-premises. Risk Profiling for customers with High Risk Debits – Data Lake – build on new functions. Can’t do in old environment. Born in the Cloud Organizational Structure Organizational structure that facilitates autonomy to maintain speed, agility while maintaining control Distinction between service provider, service broker and service consumer Born in the Cloud Architecture - Use of modern Solution- , Application Architecture and Deployment patterns (Publish/Subscribe, Event driven, Loosely Coupled, Micro Services, Severless computing, AI, ML etc..) Born in the Cloud Tooling - Use of tooling that’s in sync with the vendors cloud platform and is fully integrated into the platform (vs bolted on) Born in the Cloud Controls Security Control Framework that’s Born In the Cloud which separates why, what and how Controls that are in sync with the vendors cloud platform and is fully integrated into the platform (vs bolted on) Born in the Cloud Deployment Mechanism Infrastructure as code (deploy infrastructure (networks, virtual machines, load balancers, and connection topology) through code using a descriptive model) Zero Touch (Relentless Automation of Development, Deployment and Operations / No manual interventions ) Re-use of certified services (aka products/features) Use of cloud native tooling only Loosely coupled architecture Born in the Cloud Processes Implementation Process implementation which provides a clear separation of Service Consumer and Service Provider accountabilities/responsibilities to facilitate autonomy of Platform and Workload DevOps teams
- Maarten to share – the HOW Microsoft’s experience showed that for getting the true value of Cloud capabilities, this means a big shift in way of working, compared to current IT organization. We consider these Cloud principles crucial: This also means: Do NOT try to expand the current Datacenter tools & modus operandus to the Azure platform. Consider the Azure platform as a new virtual Datacenter, with a new (Dev and Ops) organization, new tools and processes. It should interface and integrate with the current IT organization and landscape on a high-level (loosely coupled).
- Two ways
- Talkline: Do you recognize these issues (explain one or two and get an answer by asking someone specific) These issues have common causes that need to be solved structurally (not just fixing a direct cause) We’ve come up with MSM principles that when used will drive changes and platform capabilities The changes needs/requires buy in amongst those affected, research and our own experience show that this is best achieved using a ripple effect (stone in water). Start simple, proof value, create buy in, scale/replicate The most important benefit is the last box in this column…. focus on providing autonomous service delivery and operations to business units Customer Issues Complicated Disaster Recovery. It’s not modular. Common Causes In flight (manual) patching and updates. Leads to service disruption. Service Provider based capacity mgmt. (vs Service Consumer / Demand) Infrastructure redundancy (vs service resiliency) In flight configuration changes (vs part of release) Tightly integrated (vs loosely coupled) Site redundancy (vs service resiliency) MSM Principles Business Led service delivery and operations(zero business disconnect) Change Select / Configure (cloud) services (no building/customization upfront) Platform Capabilities Rolling upgrade windows (without service disruption) Automated stateless scaling (based on demand) Self service / Mgmt. API (subscription, deployment, usage and de-subscription) Resource manager & providers (to virtualize automation) Service fabric/micro services (facilitate loosely coupled modular applications) df