Service Management-as-a-Service for Hybrid Cloud

Transcription

1 Sep Service Management-as-a-Service for Hybrid Cloud Rajesh Jaluka Distinguished Engineer Global Technology Services

2 Agenda Service Management Integration Challenges in Hybrid Cloud Environment Experiments to leverage Software-as-a-Service attributes to simplify integration Standards and decoupling to improve interoperability 2

3 Enterprise Data Center of the Future Yesterday SoftLayer Amazon Today Google Private Cloud Azure Isolated Tomorrow SoftLayer SoftLayer Salesforce Amazon SAP Google Private Cloud Private Cloud Azure Workday Azure Service Engage Azure Interconnected 3

4 Service Management Challenge: Today The components that come bundled with the cloud services are lightweight and easier to use It may not be easy to use your existing on-premises solutions with many cloud services e.g. current monitoring might be too heavy or not compatible with the IaaS services Monitoring solution from one IaaS provider may not work on another IaaS provider. Existing Datacenter Monitoring 1 Dashboard 1 Provider 1 Dashboard 3 Provider 2 Provider 3 Dashboard 5 Ticketing 5 4

5 Service Management Challenge: Configuration and Maintenance Increases your overhead of building and maintaining content (e.g. configuration, policies, automations, procedures) for multiple platforms. Configuring each has its own learning curve Requires implementing same rules and policies in multiple systems resulting in duplication 5

6 Service Management Challenge: Tomorrow If this is not managed, it will spiral into a hodgepodge of systems which will impact service quality At the same time a single tool is not desirable because enterprises want flexibility to take advantage of innovative capabilities some specialized tools may offer Provider 1 Provider 2 Provider 3 Provider 4 Provider 5 Provider 6 Provider 7 Provider 8 Dashboard 1 Monitoring 1 Dashboard 1 Monitoring 1 Dashboard 3 Dashboard 3 Dashboard 5 Dashboard 5 Dashboard 5 Dashboard 5 Ticketing 5 Ticketing 5 Ticketing 5 Ticketing 5 6

7 Hybrid Cloud Integration : Challenges A single tool may not be desirable because niche capabilities offer compelling business value. Integrating the components from various providers is expensive and time consuming. Without integration you end up with data scattered across multiple tools which impacts Service Level Management, Reporting, Change Management etc. Bottom line: Cannot avoid multiple tools and cannot avoid integrations 7

8 Pattern to Partially Mitigate Integration Complexity Reduce variability for each component to significantly reduce the integration overhead. e.g. strive for one tool each of monitoring, correlation, dashboard, and ticketing. These do not have to come from the same service provider. Select services that can run across variety of OS platforms and cloud deployment models. Existing Datacenter Provider 1 Provider 2 Provider 3 8

9 Pattern to Partially Mitigate Integration Complexity If variability of components cannot be avoided because they offer compelling value or it is not technically feasible. Then, integrate to a component that offers the best logical aggregation. E.g. integrating to the correlation service instead of ticketing and dashboard Existing Datacenter Monitoring 1 Provider 1 Provider 2 Provider 3 9

10 Challenge for Service Providers However, Service Providers have to deal with the variability from customer to customer. Monitoring 1 Monitoring 1 Monitoring 1 10

11 Static Integrations are Expensive Building and maintain integrations are not cheap and quick Changing platforms requires rewrite Addressing multiple permutations and combinations of the variations will require many integrations 11

12 Dynamic Composition with SaaS Could we dynamically assemble components to create these patterns with permutation and combination of our choice? Monitoring 1 1 Dashboard 1 2 Ticketing 2 3 Dashboard 3 Ticketing 3 4 Dashboard 4 Ticketing 4 5 Dashboard 5 Ticketing 5 Monitoring

13 Key Software-as-a-Service Characteristics Focus on modularity, composability and interoperability in your selection and design Security, privacy, audit and compliance Affordable Reliable: high availability, highly resilient (error handling, disaster recover), and easily upgradeable Scalable and Elastic: Consumable in an incremental fashion Modular: As existing application portfolios are replaced, organizations will combine multiple SaaS and BPaaS Composable: Based on open standards and easily integratable (provide APIs) Rate carded: simple pricing Ease of use: easy to sign up, easy to setup / configure, easy to use (intuitive user interface), Level of automation: up and running in minutes, always up to date, ease of migration Self-service: discover, learn, try, buy, activate, deactivate, modify through digital channel Interoperable and Portable: instead of locked-in with vendor specific formats Configurable: to adapt to customers enterprise / industry needs Hybrid Support: works with multi-vendor cloud and on-premises applications Cloud Service Brokerage support: policy, composition, comparison, aggregation 13

14 Modular: Versus Monolithic Many SaaS are primarily shrink-wrapped software that have been cloud enabled The components are tightly coupled and lack APIs at component level e.g. there are APIs to receive events but there may not be an API to show events from other sources in the dashboard Ensure you can get data in and out of each component via APIs. Look for any hardwired assumptions User interfaces are often littered with linkages e.g. Dashboard has hyperlink that only launches out to its own component The data models and APIs too have hardwired referential integrity checks e.g. entries in a correlation table must have a numeric eventid that exists in the event table Dashboard Monitoring Dashboard Ticketing Monitoring Ticketing RunBook Notification RunBook Notification 14

15 Modularity alone does not guarantee composability Software components can Modularity alone does not guarantee composability May have APIs Monitoring 1 Burden on the consuming application to call APIs Will need to keep polling the sending systems for events Polling can consume a lot of resources Polling may not provide the near real-time experience 15

16 Composability Unix Pipes All programs support standard input and standard out to get data in and out All programs work off a standard format (strings) No coding, only configuration parameters to alter how data should be interpreted and processed e.g. d to change the delimiter The programs down the pipe are not constantly polling programs up the pipe for data The program down the pipe are waiting and listening for that up the pipe to send data curl grep vmname cut -d' ' -f2 Not a pipe dream! Cloud-native is driving adoption of standards like Webhooks, REST, JSON 1. Monitoring calls back a URL and passes the JSON object 2. Mapping to translate JSON from sender to receiver 3. The does its processing Monitoring Ticketing 16

17 Interoperability: Standard Nomenclature for Data Monitoring Ticketing Need standards to describe the actionable data for various domains What information comprises alerts, events, incidents, notification Other data items can be simple name-value pairs This will eliminate the need to map and translate data Monitoring Ticketing 17

18 Product 3 Product 1 Product 2 Interoperability: Standard Nomenclature for Content Integration Runbook Configuration Software Automation Customization Content is tightly coupled to the software Configuring rules and policies may require tool specific UI Scripts to describe rules and policies use vendor specific syntax Each tool supports different language or has its own proprietary method to apply automation Automation Integration Configuration Software + Software Automation Software Software Runbook Customization Integration RunBooks Configuration Content Library Integration Runbook Configuration Software Automation Customization Some existing standards (e.g. BPEL) and automation products like Chef and Puppet can make RunBooks and Automation product independent Need standards to express policies and rules e.g. CPU GT 80% Backup Schedule 00 11,16 * * * /home/app1/data/incremental-backup 18