Multi-Cloud Service Delivery and End-to-End Management

1,422 views
1,327 views

Published on

A discussion of the challenges of delivery a great user experience, and great operations experience, and a great developer experience in todays digital economy.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,422
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
57
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Multi-Cloud Service Delivery and End-to-End Management

  1. 1. Multi-CloudService Delivery &End-to-EndManagementReference ArchitectureWorldwide Communications andMedia Industry Version 1.1 15 Jan 2013
  2. 2. Multi-Cloud Service Delivery & End-to-End Management©2013 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information andviews expressed in this document, including URL and other Internet Web site references, may changewithout notice. You bear the risk of using it. Some examples are for illustration only and are fictitious.No real association is intended or inferred.This document describes how service providers and partners can implement the TM Forum SESManagement Solution design patterns on Microsoft cloud platforms going forward. Given this is anindustry standard work-in-progress; nothing is implied as to the degree to which these design patternsactually are or will be implemented by Microsoft products and services.This document does not provide you with any legal rights to any intellectual property in any Microsoftproduct. You may copy and use this document for your internal, reference purposes.Microsoft Communications and Media Industries 15 Jan 2013 Page 1
  3. 3. Multi-Cloud Service Delivery & End-to-End Management Table of ContentsTable of Figures ............................................................................................................................................. 3Foreword....................................................................................................................................................... 4Executive Summary....................................................................................................................................... 6Introduction ................................................................................................................................................ 10Software Enabled Services Management (SES) .......................................................................................... 14 Defining a Manageable Service....................................................................................................... 14 Defining a Simple Management Interface ...................................................................................... 14 Service Lifecycle Management ....................................................................................................... 16 API Inventory Management ............................................................................................................ 16Challenge of End-to-End Service Management .......................................................................................... 18Cloud Computing Resource Management .................................................................................................. 20 Challenges of Virtualization ............................................................................................................ 21 Challenges of Multi-Cloud............................................................................................................... 22 Cross-Industry and M2M Applicability............................................................................................ 26Cost of Excellence in Quality of Service ...................................................................................................... 28Value of a Service Broker ............................................................................................................................ 30 The Telco SDP .................................................................................................................................. 31 The ICT Service Delivery Broker ...................................................................................................... 32 API Management ............................................................................................................................ 33Implementing Multi-Cloud Service Management with Microsoft .............................................................. 38 APIs for Measuring Azure Performance by Application.................................................................. 40 Monitoring Pack for Windows Azure Applications ......................................................................... 40 Getting the Latest Monitoring Pack and Documentation ............................................................... 42The Multi-Cloud Developer Experience Catalyst ........................................................................................ 44Release History ........................................................................................................................................... 46References .................................................................................................................................................. 47Microsoft Communications and Media Industries 15 Jan 2013 Page 2
  4. 4. Multi-Cloud Service Delivery & End-to-End ManagementTable of FiguresFigure 1 – The Multi-Cloud Nature of Service Delivery ................................................................................ 6Figure 2 – Managing Services in a Virtualized Multi-Cloud Environment..................................................... 7Figure 3 – Four operations issues of multi-cloud........................................................................................ 12Figure 4 – Great User Experience, Great Operations Experience, Great Developer Experience ............... 13Figure 5 – TM Forum SES Interfaces ........................................................................................................... 14Figure 6 – Types of Service Interfaces ........................................................................................................ 15Figure 7 – TM Forum SES LMM Management Phases (Draft)..................................................................... 16Figure 8 – Programmable Web API Growth................................................................................................ 17Figure 9 – Complexity of managing syndicated services ............................................................................ 19Figure 10 – Example content streaming to mobile device ......................................................................... 20Figure 11 – Windows Azure virtualized resource layers. ............................................................................ 20Figure 12 – Three Resource Layers ............................................................................................................. 21Figure 13 – Role of an OSS .......................................................................................................................... 21Figure 14 – Visualizing the service delivery path ........................................................................................ 22Figure 15 – Visualizing service management .............................................................................................. 23Figure 16 – Exposing B2B management services ........................................................................................ 23Figure 17 – Visualizing B2B service management....................................................................................... 24Figure 18 – Another view of the SES Management Solution vision used in an ITU-T submission.............. 25Figure 19 – M2M Cross Industry Example of Multi-Cloud Service Delivery ............................................... 26Figure 20 – Components of Service Quality ................................................................................................ 29Figure 21 – Multi-Cloud Service Management ........................................................................................... 31Figure 22 – Functional and Management APIs ........................................................................................... 34Figure 23 – The Service Delivery Broker (SDB) as an API management system ......................................... 35Figure 24 – The SDB in a Services Orientated developer governance role................................................. 36Figure 25 – SMI as a Value Added Service .................................................................................................. 38Figure 26 – Flexible SMI deployment options............................................................................................. 39Figure 27 – TM Forum Multi-Cloud Developer Experience Catalyst........................................................... 44Microsoft Communications and Media Industries 15 Jan 2013 Page 3
  5. 5. Multi-Cloud Service Delivery & End-to-End ManagementForewordMicrosoft was a founding member of the TM Forum Service Delivery Framework (SDF) initiativelaunched in 2007 with the aim to identify and specify the standards required to enable networkinfrastructure providers, hosted service platform providers, application providers, service brokers orservice syndicators to efficiently work together to create and deliver coarse grained services frommultiple fine grain components and yet still be able to manage down to the fine grain service level.Later, as work progressed, the TM Forum renamed the project to Software Enabled Services (SES)Management.Microsoft has contributed extensively to the effort since the beginning. One core contribution was aconcept taken from a Microsoft solution known as the Connected Services Framework or CSF. CSFadvocated the concept of a “Well-Enabled Service”; a service that exposed a separate interface designedto perform management functions such as to report health and welfare. Today in the TM Forum, theWell-Enabled Service manifests itself as a Software Enabled Service; a service that exposes both aFunctional Interface (FI) and one or more Simple Management Interfaces (SMI).The Microsoft Reference Architecture for Multi-Cloud Service Delivery is complementary to the TMForum SES. Although the Microsoft reference architecture can be implemented without actuallyimplementing SES, the context for that architecture is best understood by understanding the TM ForumFrameworx and Software Enabled Services Management relevance to end-to-end management in Multi-Cloud Service Delivery. Accordingly, there are multiple references in this document to the TM ForumFrameworx and Software Enabled Services Management. Only readers from TM Forum membercompanies can download the referenced source documents from the TM Forum web site. Since the vastmajority of the intended audiences of this work are members of the TM Forum this should not be amajor issue.With the rapid growth of cloud computing, the consumerization of IT, the trend towards services andcontent created increasingly at the edge, the exponential growth of Web Services APIs, and increasinglymobile endpoints the original goals of the SDF initiative have never been more relevant. Microsoftcustomers, developers and partners will find that leveraging the concepts contained in the MicrosoftReference Architecture for Multi-Cloud Service Delivery and End-to-End Management can acceleratetheir Service Oriented Architecture implementations leveraging cloud, network, and enterpriseresources while delivering significantly better user experiences, better end-to-end operationsmanagement capabilities, and greatly improved developer efficiencies.Eric G. TroupCTO, World-Wide Communications and Media IndustriesMicrosoftMicrosoft Communications and Media Industries 15 Jan 2013 Page 4
  6. 6. Multi-Cloud Service Delivery & End-to-End ManagementIndustry Comments“From a pure operations perspective, the goal is to ensure we are delivering an outstanding End-to-End Customer Experience. As we move to virtualize resources in the core and mobilize on the edge,this is becoming a dynamic, complex equation with many moving parts. This is true within a singleenvironment, let alone across an Eco-System of Cloud Environments that must not only understandhow to interact seamlessly to deliver service, but also what is required to understand the End-to-End Service Path through the arrays of networks, compute infrastructure, and applications in orderto ensure an outstanding Customer Service Experience and act quickly if this is experience is sub-par. This paper provides an excellent overview of the landscape and captures many of the salientpoints for us to reflect upon in this journey to a new delivery and operational landscape.”Mark Francis, VP AT&T“Embracing service-orientation principles and TM Forum SES SMI, the Multi-Cloud Service DeliveryReference Architecture is an excellent showcase that presents PT/SAPO Service Delivery Brokerrelevance in support of hybrid, multi-vendor and multi-platform cloud environments, where it iscrucial to guarantee services reliability, interoperability and end-to-end manageability”.António Cruz, Programador PT Communicações, S.A."Although the industry does not yet fully appreciate the challenges and costs of operating in amulti-cloud environment, minimizing integration and operating costs will be a critical success factor.The emergence of an industry standard reference architecture to simplify multi-cloud servicemanagement is a priority for the TM Forum and we congratulate Microsoft for their initiative inproducing this paper as a strong contribution to meeting industry needs."Keith Willetts, Chairman TM ForumMicrosoft Communications and Media Industries 15 Jan 2013 Page 5
  7. 7. Multi-Cloud Service Delivery & End-to-End Management Executive SummaryBusiness and consumer services delivered in today’s digital economy are increasingly dependent uponresources distributed across a diverse ecosystem of stakeholders. Content Owners, CommunicationsService Providers (CSPs), Multiple System Operators (MSOs), Cloud Providers, Business and ConsumerUsers and of course Developers are all interdependent. As evident in Figure 1, the processes of creatingcontent / services, service delivery and of managing the overall experience end-to-end in this multi-service provider / multi-cloud environment has become challenging.Service Providers today are dealing with four major trends: A. Multiple devices from a variety of manufacturers. B. Complex developer ecosystems C. Expediential Growth of Service APIs D. Reality of Multi-Cloud Service DeliveryTo address these issues the TM Forum developed theSoftware Enabled Services (SES)1 Management Solution. Itdefines the concept of an SES Service that exposes both a Figure 1 – The Multi-Cloud Nature of Service DeliveryFunctional Interface as well as an explicit interface for themanagement of a service or a service composition.The SES Management Solution is not particularly concerned with what the service does via theFunctional Interface but does expand upon the manageability aspects especially in these two areas: 1. The Simple Management Interface2 (SMI) defines a design pattern for an API that reveals how to manage any given service from a Provisioning, Assurance and Usage/Charging perspective. 2. The Service Lifecycle Management (SLM) defines ITILv3 2011 aligned best practices and requirements for establishing a role based software/services factory and a Lifecycle Management Meta Data model.There are two principal differences with cloud computing that make more difficult the problem ofmanaging resources associated with cloud services. One difference is the virtualization at the elasticcompute and elastic network layers as well as the sheer scale of that virtualization. The other differenceis that multiple clouds and multiple enterprise domains are increasingly involved in the delivery of cloudservices further complicating resource management.1 The term “SDF” and “SES” will be used interchangeably in this paper. Early TM Forum documents used the term“SDF” or Service Delivery Framework and later TM Forum documents use the newer “SES” term. When a drawingis pulled from a TM Forum document the term SDF or SES may appear depending upon the date of those docs. Noattempt is made to refactor the terminology to the newer term.2 Simple Management Interface was the term adopted with the launch of the TM Forum Digital Services Initiativein December 2012. The term had progressed from “Simple Management Interface” to “SES ManagementInterface”. “Simple Management Interface” will be term used going forward.Microsoft Communications and Media Industries 15 Jan 2013 Page 6
  8. 8. Multi-Cloud Service Delivery & End-to-End ManagementTo address this problem, the Microsoft Multi-Cloud Service Delivery and End-to-End ManagementReference Architecture defines how what the TM Forum SES Management Solution calls ManagementSupport Systems (MSS) can coordinate the SMI aspects of an application or service with the associatedstate, health and welfare of underlying cloud and network resources.As illustrated in Figure 2 below, Management Support Systems can maintain the relationship betweenan application instance and the specific virtualized resources supporting that instance. This enablesrelevant telemetry from that service and associated underlying compute and network resource layers tobe relayed to an OSS and used to update a Service Model dashboard.Figure 2 – Managing Services in a Virtualized Multi-Cloud EnvironmentFurthermore, the SMI can be exposed as B2B Simple Management Interfaces to enable the managementof service mashups that span multiple service providers. Leveraging this capability enables complexservice ordering and provisioning as well as customer dashboards to accurately display the status of aservice including underlying component services not under the direct control of the local serviceprovider or customer.An Information and Communications Technology (ICT) Service Delivery Broker can be extremely usefulto help manage service creation and delivery in this environment. The envisioned ICT SDB is somewhatdifferent from traditional telecom SDPs that will continue to play an important role. An ICT SDB is well-suited to address the broader needs of all cloud stakeholders and is not specifically focused on telecomservice provider requirements per se.Microsoft Communications and Media Industries 15 Jan 2013 Page 7
  9. 9. Multi-Cloud Service Delivery & End-to-End ManagementThe ICT Service Delivery Broker can provide a set of reusable core capabilities (services) to govern andspeed development processes as well as to support runtime operations. Some of the reusable servicessuch an SDB can provide include: • common transports, • bindings and protocol mediation, • support for all needed message patterns, • common tasks such as security & access control, • event processing engine, • routings, • performance / traffic monitoring, • mechanisms for real time visibility into performance and usage including Dashboards.This use of an ICT SDB also enables the reference architecture to deliver three key value propositions: 1. A Great User Experience – Users are able to access the business application or see the content in the manner they expect. 2. A Great Developer Experience – Developers are able to more quickly create applications in a consistent manner that can be easily incorporated into SOA Service Compositions that are readily manageable from a QoS and SLA viewpoint. 3. A Great Operations Experience – Operators are able to provide a great user experience because they have the information necessary to measure what is going on, quickly assess root causes and impacts, and react to problems in a proactive manner.Microsoft cloud platforms provide the necessary features and APIs to enable developers to createservices and applications that expose Simple Management Interfaces as outlined by the TM Forum SESManagement Solution. • On-Premise Cloud - Microsoft Windows Server with Hyper-V together with System Center enable the creation and deployment of manageable mission critical business and consumer applications. • Off-Premise Cloud – Microsoft Windows Azure also provides the necessary APIs that can be used to create and expose Simple Management Interfaces for any service hosted on Windows Azure. In addition, there is a Monitoring Pack for Windows Azure Applications and a Monitoring Pack for SQL Azure for System Center to help manage cloud and hybrid cloud hosted business applications and consumer services end-to-end.Links to information on how to actually use these capabilities are listed in the in section “ImplementingTM Forum SES Management with Microsoft”.The TM Forum SES Management Solution documents are listed under “References”.Microsoft Communications and Media Industries 15 Jan 2013 Page 8
  10. 10. Multi-Cloud Service Delivery & End-to-End ManagementMicrosoft Communications and Media Industries 15 Jan 2013 Page 9
  11. 11. Multi-Cloud Service Delivery & End-to-End ManagementIntroductionThe nature of service delivery is changing. For many years, communications service providers (CSP) andcable operators (MSO) have approached service delivery with the assumption that the network wasfundamentally central to the delivery of services and that CSPs and MSOs would continue to largelycontrol service creation and delivery end-to-end. The complex nature of large multi-layered networkscomposed of elements distributed over a wide geography required communications service providers todevelop highly specialized capabilities to deliver voice and then data services over those networks.The operations and maintenance requirements of network resources and telecom services have, untilrecently, remained very different than those of IT data center resources and their applications. Thenetwork side of service delivery management gradually became organized around concepts like ServiceDelivery Platforms3 designed to optimize service creation and real-time delivery processes. The serviceprovider’s IT infrastructures (BSS/OSS4) needed to run the business gradually became organized aroundthe TM Forum Frameworx5 reference enterprise architecture. The underlying IT software and computeresource management processes became organized in accordance with the Information TechnologyInfrastructure Library or ITIL6.The concept of Service Oriented Architectures (SOA) has existed for many years. The TM ForumFrameworx for instance, defines key business functions, logically groups them into proposedapplications, offers common data models, and suggests contracts between components. Keith Willetts,Chairman of the TM Forum, states in his new book, Unzipping the Digital World; “Frameworx is built ona services oriented design and uses standard, reusable, generic blocks that can be assembled in uniqueways to gain the advantages of standardization while still allowing customization and enablingdifferentiation and competition at the service level”.7However, implementing solutions based upon frameworks takes discipline. Often the cost ofimplementing a framework based solution requires extensive cooperation between organizationsbeyond the current boundaries of individual projects and their budgets. As a result, many IT projects,including implementations of Business Support Systems and Operations Support Systems (BSS/OSS),often took expedient shortcuts to get projects delivered on time and at budget. Ultimately, the CSPsended up with complex, inflexible, and often redundant BSS/OSS organized around silos of products orgroupings of technologies. These implementations loosely conformed to the TM Forum Frameworx andcurtained SOA concepts but they did not actually deliver the agility and cost effectiveness needed tokeep pace with an accelerating rate of change. A consequence of this is that the traditional telecom3 Service Delivery Platforms (SDP): A platform that supports development, deployment, and runtime of serviceswithin a particular domain. Typically provides governance and tooling in support service lifecycle management,service deployment accelerators, marketplaces, and/or runtime management capabilities.4 BSS/OSS: Business Support Systems / Operations Support Systems.5 TM Forum Frameworx, see http://www.tmforum.org/TMForumFrameworx/1911/Home.html6 Information Technology Infrastructure Library, see http://www.itil-officialsite.com/7 Unzipping the Digital World, Keith Willetts, page 267.Microsoft Communications and Media Industries 15 Jan 2013 Page 10
  12. 12. Multi-Cloud Service Delivery & End-to-End Managementoperators as we know them may be “losing their voice”8 as the digital world rapidly expands into muchbroader ecosystems of digital service providers and stakeholders.Over the years, standards evolved that enabled telecom voice and data services to work seamlessly overmultiple service providers’ infrastructures. Originally, a mobile user was able to receive service onlywhen physically connected to their service provider’s network. Today, mobile users are scarcely awareof the network they are actually connected to. Both the business issues of charging and billing as well asthe technical issues associated with roaming wireless voice and data services were successfullyaddressed. The need for very fast negotiation and coordination between service providers resulted inthe evolution of special command and control networks, such as SS7/CC7 (Signaling System 7/CommonChannel Signaling 7) for voice and IMS (IP Multimedia Subsystem) for IP Voice and Data. Differences inglobal standards were resolved. The CSPs developed very effective capabilities for Provisioning,Assurance, and Charging/Billing of network infrastructures and associated services end-to-end. Tosupport both wholesale and retail operations involving multiple service providers, they also developedthe service provider to service provider B2B interfaces necessary to support provisioning, serviceassurance, and charging/billing processes spanning two or more service providers.While the introduction of web services began to break down some of the barriers between the IT andnetwork worlds, it is cloud computing that is completely disrupting the former status quo. The cloudpulls together a number of disrupters accelerating the convergence of IT and Telecom. Some of thesekey disrupters include: 1. Maturity of web services standards 2. The adoption of IP and SIP in telecom and cable networks 3. Growth of mobile devices routinely connected to 3G/4G/LTE or WiFi networks 4. Increasingly ubiquitous and higher speed broadband 5. Proliferation of cloud platforms for IaaS, PaaS, and SaaSWhile SOA and virtualization has contributed to the transformation of monolithic “applications” into“services” hosted on virtualized compute and network infrastructures, cloud computing creates thereality that the majority of services available for composition and consumption are not all containedwithin the boundaries of any one company or enterprise. First, applications began to be built followingstandards, and then those applications began to be exposed as “coarse-grained” services. Later servicesbegan to be further broken down into “fine grained” service components. With costs coming down andmore new entrants appearing, the industry is moving closer to the commodization of services.As indicated in Figure 3 below, service providers today are dealing with four major trends: A. Multiple devices from a variety of manufacturers: Service providers are faced with the reality of having to support an array of mobile devices from different manufacturers, using several different Operating Systems, having several different form factors, catering to the needs of8 Unzipping the Digital World, Keith Willetts, Page 31.Microsoft Communications and Media Industries 15 Jan 2013 Page 11
  13. 13. Multi-Cloud Service Delivery & End-to-End Management businesses and consumers. There are feature phones, smart phones, PCs/Slates/iPads, game consoles, and TVs. Some are connected via dedicated facilities such as IPTV or DOCSIS. Others are connected via WiFi or cellular broadband services such as 3G/4G or LTE. The “Consumerization of IT” is often mentioned as a contributing factor. B. Complex developer ecosystems: Applications are core to the generation of revenue for entire value chains. Each mobile device platform comes with unique application development support requirements. The backend platforms for hosted services also have unique application development and runtime support requirements. Enterprise IT Professional developers have certain requirements related to conformance with best practices and standards for technology use, identity management, security, and privacy. Conversely, the growing community of 3rd party developers empowered by the widespread availability of cloud computing platforms and having different needs including requiring support for more lightweight standards (e.g., OAuth) also must be catered to. Figure 3 – Four operations issues of multi-cloud C. Expediential Growth of Service APIs: Cloud computing has contributed to expediential growth in the number of published APIs and Service End Points. Efficient application development requires effective mechanisms to create, catalog and publish, maintain, and consume these APIs. The dependencies that are created within applications that rely on the incremental bits of functionality must be understood. D. Reality of Multi-Cloud Service Delivery: Virtually every service has other services upon which it depends or creates dependencies has soon as it is consumed. It is very rare today to find 100% of the resources living in a “walled garden”. This collection of services typically resides in multiple different service domains and a service owner may not, in fact, be able to directly control prerequisite services. Service delivery today requires multiple clouds and multiple service domains to work together in harmony throughout the entire lifecycle of that service.Microsoft Communications and Media Industries 15 Jan 2013 Page 12
  14. 14. Multi-Cloud Service Delivery & End-to-End ManagementThe Microsoft Reference Architecture for Multi-Cloud Service Delivery and End-to-End Management isdesigned to help Service Providers address these challenges. Leveraging industry standards, thereference architecture blends capabilities from Microsoft to help deliver three key value propositions: 1. A Great User Experience: The perceived real value associated with the user experience is critical to gaining and maintaining users willing to pay for a service. Whatever the service or content the user is consuming, that experience must meet certain expectations of the customer. This is true for both business users and the consumers. The reference architecture provides tools to measure performance against established standards and methodology to iterate towards better user experiences. 2. A Great Developer Experience: The developer community must be provided the tools and guidance needed to build the types of applications needed to deliver great experiences. In many cases, the experience cannot just be a “best effort”. Each service must be buildable in an efficient manner that facilitates combining into more complex service compositions. Major integration efforts must become progressively less necessary at this level. Therefore, developers need governance, documentation, tooling, and wizards to guide them in the development of services that are much easier to manage individually and combine into service compositions / mashups that are also manageable and end-to-end. Figure 4 – Great User Experience, Great Operations Experience, Great Developer Experience A Great Operations Experience: All of the stakeholders in the service delivery process need to be able to manage their services even though they rely on components hosted by different services providers in different clouds. The ability to readily manage services that span multiple clouds and resource domains is critical to achieving revenue objectives. Service providers and their partners need transparency and visibility across value chains in order to have the confidence to leverage efficient multi-cloud ecosystems to deliver core value added services to businesses and consumers.Microsoft Communications and Media Industries 15 Jan 2013 Page 13
  15. 15. Multi-Cloud Service Delivery & End-to-End ManagementSoftware Enabled Services Management (SES)The Software Enabled Services Management Solution is defined in detail in a series of documents fromthe TM Forum. The list is available in the References section.SES Management solution has two key elements:The Simple Management Interface (SMI) is an API that reveals how to manage any given service. Itdefines for developers a key design pattern for including management capabilities in a service as theydesign and build it. It enables service providers to manage each service or composition of services in anefficient manner.The Service Lifecycle Management (SLM) defines best practices and requirements for establishing a rolebased software/services factory and a Lifecycle Management Meta Data model. Aligned to ITILv3 2011Service Lifecycle Management Governance, this architectural component aids in the management ofAPIs through their lifecycle impacting both service creation and runtime processes. Defining a Manageable Service It is important to first understand what is meant in this reference architecture by a “Service” and a “Software Enabled Service” or SES. Without getting into a long discussion about the definition of a service, let us define the following terms: Service - a value provided by performing one or more functions on behalf of the service requester typically via an API. Software Enabled Service9 - a service that explicitly provides both a Functional Interface part to the API and one or more Simple Management Interface parts to the API. The implementation is flexible. The SES API could be two separate APIs; (e.g., one WSDL for the FI plus one or more for SMI), or one API (e.g., one WSDL for both the FI and SMI) with specific parts for each purpose. Defining a Simple Management Interface A Simple Management Interface is an API, Figure 5 – TM Forum SES Interfaces or a part of an API, that provides management capabilities for a service. TM Forum TR139 defined the SMI as “…the set of capabilities exposed by an SDF Service through which it can be9 TMF 061 “Service Delivery Framework Reference Architecture” Figure 3 - Pattern of an SDF Service v1.2; page 14.Microsoft Communications and Media Industries 15 Jan 2013 Page 14
  16. 16. Multi-Cloud Service Delivery & End-to-End Management managed.”10 TMF617 states “The SES Management Solution proposes a hook to allow consistent access to the software components for OA&M tasks. This consistent access is achieved by incorporating the … SES SMI in addition to the Functional Interface as part of software component creation. ”11 The exact operations supported by an SMI are determined by the functionality needed for the service itself. Some could leverage TM Forum TIP/MTOSI/IP Sphere specifications however, these heavier options may not be appropriate for all service types. An SMI may be implemented as a part of the service itself or it may be implemented by an OSS component that will provide a management capability on its behalf. The TM Forum SDF/SES documentation uses the terms Management Support System (MSS) to refer to any BSS or OSS that performs the SMI function on behalf of a service. Later in this paper we will discuss Service Delivery Brokers (SDB). It is also possible for an SDB to emulate a Service’s Management Interface; to expose a virtualized SMI making it available through a mediation component such as a message broker, ESB or gateway. Through mediation, the SMI will then appear to its consumers as if it was originally designed as part of the service enabler. This can be necessary because it is not always possible to change the underlying service enablers or simply because an SMI capability needs to be composed by assembling a composition of different services. A building block service that is intended to be combined with other services to create a service mashup or SOA “service composition”12 is depicted below. The service API exposes a Functional Interface and one or more Simple Management Interfaces address the following concerns: • A FI is used to construct service compositions. • A Provisioning SMI enables configuration and state management. It is used to define end-to-end provisioning processes. • An Assurance SMI exposes the interface from which to collect specified fault and performance events/data from which QoS and SLA performance can be derived. • A Billing or Charging SMI Figure 6 – Types of Service Interfaces can expose usage / charging events that can10 TM Forum TR139, “Service Delivery Framework Overview”, Page 16.11 TMF 617, “Software Enabled Services Management Interface Information Agreement”, Page 14.12 See (http://www.soaglossary.com/service_composition.php for discussion of this SOA term.Microsoft Communications and Media Industries 15 Jan 2013 Page 15
  17. 17. Multi-Cloud Service Delivery & End-to-End Management be used for wholesale or retail billing purposes and settlement. Service Lifecycle Management In addition to the concept of a consistent design pattern for an SMI, the SES Management Solution acknowledges the need for a consistent approach to service lifecycle management. This includes representative definitions for the phases a service passes through from concept to retirement as well as a Lifecycle Management Metadata (LMM) model. The LMM can hold all the data about a service throughout its lifecycle. The SES Service Lifecycle Management definition consists of three parts: • Management Dependencies of the Service – Resources that are prerequisites for the service to function. • Management Phase of the Service – ITILv3 2011 aligned lifecycle phases. • Additional information about the SMI of a SES – Placeholder for additional information but otherwise undefined. The most well-defined of these three parts is the Management Phases of the Service. Adjacent is an extract from TMF61813 that shows the following proposed phases (TM Forum, 2010): • Concept • Design • Deploy • Operate Figure 7 – TM Forum SES LMM Management Phases (Draft) • Retire API Inventory Management Cloud computing enables many different entities, from large businesses to individual developers, to host and publish and ever increasing number of APIs. The proliferation of APIs creates requirements for API inventory management control.13 TMF618, “Software Enabled Services Lifecycle Management Metadata Information Agreement” Figure 5-4, Page19.Microsoft Communications and Media Industries 15 Jan 2013 Page 16
  18. 18. Multi-Cloud Service Delivery & End-to-End Management It has been recognized for several years that simply building Web Services APIs and making them available are not sufficient from either a technical or business perspective. In a services orientation world, the service needs to be Figure 8 – Programmable Web API Growth the focus, not the message. A systematic approach is required to guide the creation of APIs according to a set of common guidelines. A management system is required to perform common functions that can be consistently applied across all APIs. These include: • Service Versioning • Service Policy • Service Abstraction • Service Routing and Transport • Service Management As will become apparent, the massive amount of data generated through the use of APIs becomes a critical component to a much larger Business Analytics process. As the invocation of web services becomes more and more critical to the business, telemetry about the API traffic, management systems, and the underlying virtualized cloud infrastructures become major sources of operational data that must be monitored in near real-time or real-time to meet the needs of the business groups, developer communities, and operations management.Microsoft Communications and Media Industries 15 Jan 2013 Page 17
  19. 19. Multi-Cloud Service Delivery & End-to-End ManagementChallenge of End-to-End Service ManagementService delivery today often requires two or more service providers working together efficiently. Thereality today is that no service provider owns all the services that make up total value being delivered toa customer. There are several reasons for this. One important driver is associated with corecompetencies and the economics of delivering services at scale. Different types of service providershave unique capabilities they can deliver at such scale that it is not economically feasible to duplicateand to maintain a similar capability locally on an ongoing basis. Customers, however, often wantsolutions that require including at least one competency outside of the core competency of the primaryservice provider. Meeting customer requirements can be achieved most economically by combining thebest services exposed by several different providers into new value added service chain.As traditional revenues sources erode, Communication Service Providers are actively seeking to replacetraditional services with newer next generation network services combined with new cloud hostedservices. This converged delivery over networks of content enabled by custom applications is a commontheme. To drive this business, CSPs are recruiting developers to build applications that will leveragetelecom network capabilities via a Service Exposure Layer. These 3rd party applications can include aservice logic component, possibly hosted on a cloud infrastructure, accessed via a client applicationmarketed via the appropriate Application Store or via an HTML5 web browser user interface.In many cases these applications invoke services hosted on other environments. The services may, inturn, implement one or more calls to other services supported by underlying wholesale businessrelationships between several service providers.It is extremely important to understand that the challenges of end-to-end service management existregardless of whether the business relationships follow a formal Service Syndication model or an Over-the-Top (OTT) model. Let’s examine a use case where a customer, such as an enterprise IT department,has a problem with Office 365 Lync VoIP quality. If they contact their local partner by calling into thepartner CSP’s CRM system, that CRM agent ideally should have the capability to see the health andwelfare of the service end-to-end. This means visibility into Microsoft resource management systems aswell as the CSPs resource management systems. If the customer calls into Microsoft support, then theMicrosoft support person should have visibility into the health and welfare of Microsoft Lync, itsunderlying cloud infrastructure, as well as the local service provider’s network resource managementsystems relevant to this service.In the hypothetical Service Syndication example at Figure 9, Microsoft is providing Office 365 asSoftware as a Service (SaaS) to a CSP that is bundling it with other services and reselling a package tobusiness customers. Although Microsoft runs a massive global data network and CDN, it does not ownthe carrier’s core network or the access networks: the Backhaul, WiFi, 3G/4G /LTE and enterprise LAN/WAN infrastructures that actually connect the cloud and network services to end user devices such asWindows 8 PCs and Windows Phones. Communications Service Providers supply these capabilities. AMicrosoft Communications and Media Industries 15 Jan 2013 Page 18
  20. 20. Multi-Cloud Service Delivery & End-to-End Managementlocal service provider might provide an IP or IP MPLS network service to provide an optimized VOIPexperience for an enterprise customer’s employees using Microsoft Lync.Figure 9 – Complexity of managing syndicated servicesThere are two types of connection paths in play: 1. Service Delivery Path - that used by the Functional Interfaces of the services to deliver the combined service value to the customer; in this case Lync plus MPLS that combine to create a hypothetical Premium Office 365 bundle. A user making a Lync VOIP call exercises these interfaces. 2. Service Management Path(s) – All of the logical management paths depicted above that perform Operations and Maintenance functions such as Provisioning, Service Assurance and Charging / Billing of the relevant services to this bundle.The delivery path for the service, via their Functional Interfaces, is fairly obvious. The TM Forum SESManagement Solution does not consider them in the scope of its work. The real challenge and the focusof the TM Forum SES Management is an efficient implementation of all the management functionsdepicted by the colored lines between the CRM portal and the Administrative, Provisioning, ServiceAssurance, and Charging functions for each component that makes up a complete service. Given theproliferation of new service APIs enabled by the growth in cloud computing, particularly PaaS and SaaS,the implementation of the management functions cannot require a major system integration effort witheach new service deployment. That simply will not scale and would become unmanageable.Microsoft Communications and Media Industries 15 Jan 2013 Page 19
  21. 21. Multi-Cloud Service Delivery & End-to-End ManagementCloud Computing Resource ManagementThere are two principal differences with cloud computing that make more difficult the problem ofmanaging resources associated with cloud services. One difference is the virtualization at the elasticcompute and elastic network layers. The other difference is that multiple clouds and multiple enterprisedomains are increasingly involved in the delivery of cloud services further complicating RM.In the example below, a content provider sends content to another cloud service where the asset istransformed and streamed by Azure MediaServices14 to mobile devices over a differentnetwork. There are at least three differentparticipants in this service delivery scenario.Each of the services operates within theconfines of separate enterprise domains.End-to-End visibility can be difficult giventhat the management capabilities for eachcomponent, to the extent they exist at all,are hidden behind multiple firewalls.The situation is actually more complicatedthan indicated in the above drawing. As Figure 10 – Example content streaming to mobile devicedepicted in the Figure 11 below, eachindividual service is actually dependent upon at least three layers of resources. From just a serviceassurance point of view, the health and welfare of each service is an aggregation of the health andwelfare of a stack of technology. The resources at each layer are likely virtualized and may change overtime. A developer building a service can implement an SMI for their service / application. However, theywill need assistance from a Management Support System (MSS) and associated Infrastructure Support Systems (ISS) if they want to implement an SMI that also takes into account the underlying Virtualized Compute and Virtualized Network resources upon which each instance of their service depends. Cloud service and application management entails supporting the management of virtual and physical computing, storage, and networkFigure 11 – Windows Azure virtualized resource layers. resources. Effective Cloud resource managementis a core technical issue of cloud computing. Difficulties encountered when dealing with this issue is alimiting factor to mainstream adoption of cloud computing.14 For information on Azure Media Service please seehttp://www.windowsazure.com/en-us/home/features/media-servicesMicrosoft Communications and Media Industries 15 Jan 2013 Page 20
  22. 22. Multi-Cloud Service Delivery & End-to-End Management Challenges of Virtualization Cloud applications rely upon virtualized compute and virtualized network resources that can both dynamically change their configurations in response to external policies and load conditions. It is understood that there are both physical resources and logical resources involved. It is useful to look at cloud resource management from the point of view of the lifecycle management of a cloud service. Each service must be acted upon by traditional business processes associated with Provisioning/Configuration, Service Assurance, and Charging/Billing/Settlement as it passes through it lifecycle. In the simpler case of an application that resides on a single cloud infrastructure, it becomes dependent upon two distinct layers of virtualized resources. The dotted lines depict the active coordinated relationship that must be maintained between resources at each layer. There must be a mechanism provided by a Management Support System and Infrastructure Support Systems to maintain awareness as to which logical and physical resources are actually relevant to a specific instance of a specific application at any given point in time. Although the elastic cloud infrastructure provided by IaaS and PaaS can configure additional resources to handle changing application demands, there are additional requirements for dynamically reconfiguring Figure 12 – Three Resource Layers underlying network configurations and routings in response to changing resource allocations at the cloud compute resource layer. This can mean dynamically rearranging the data center network to achieve the fewest possible number of hops between any two particularly active application nodes at any given point in time. This issue arises within the internal network fabric of large cloud datacenters, between two clouds especially the interconnecting networks in hybrid cloud scenarios, and externally across transport networks and CDNs. Another issue that arises is the division of responsibility between an internal cloud virtualization management layer (IaaS and PaaS) and an external OSS. Although the cloud virtualization layer can typically manage its own physical and logical resource allocations for supported applications, an Figure 13 – Role of an OSS external OSS may be required to dynamically reallocate resources in a coordinated fashion across all three layers or to track and have knowledge of those changing relationships.Microsoft Communications and Media Industries 15 Jan 2013 Page 21
  23. 23. Multi-Cloud Service Delivery & End-to-End Management The capability of an MSS/ISS do both manage resource allocations and track their instantaneous state enables an Operations Support System, such as Microsoft System Center 2012, to provide the information necessary to display a dashboard of the health and welfare of a given service and all of the underlying relevant resources at any given point in time. From a resource management Quality of Service (QoS) point of view, Service Assurance systems need to be receiving relevant telemetry in real-time from the service, cloud compute, and network resources actually involved in delivering a particular instance of a service. Challenges of Multi-Cloud Up until now this discussion has been about the management of resources within the service, cloud, and network resource layers vertically within one logical cloud resource stack. However, actual cloud service delivery scenarios typically involve coordination across multiple clouds each with its own MSS silo, and at least some services residing in completely different enterprise service domains. Figure 14 – Visualizing the service delivery path In the Figure 14 above, a cloud service provider is delivering streaming content to user using a mobile device attached to a wireless network. In order for the service to work, all of the prerequisite services of both the Cloud Service Provider and the Communications Service Provider must function properly. In many cases they do but it is often just a “best effort”. However, if the consumer is not getting a good experience, who do they call? When either the Communications Service Provider or the Cloud Service Provider becomes aware of a problem, what tools do they have at their disposal to quickly resolve the problem in an effective manner? With the addition of a Management Support System that can keep track of the health and welfare of a service as well as the specific underlying virtualized compute and virtualized network resources associated with it, each service provider becomes able to collect fault, performance, and charging events. As part of implementing the business processes described inMicrosoft Communications and Media Industries 15 Jan 2013 Page 22
  24. 24. Multi-Cloud Service Delivery & End-to-End Management the TM Forum Business Process Framework, each service provider can implement event analysis and business analytics to display a dashboard showing the current state of each service, the underlying services upon which it is dependent or even the services that it impacts. However, Figure 15 – Visualizing service management each service provider is still restricted to a view of only the services they control and monitor. They cannot see the status of the service end-to-end from the user’s or consumer’s point of view. To support multi-cloud end-to-end service management, management capabilities must also be exposed as Service Provider to Service Provider / B2B interfaces. These service/resource management interfaces need to be able to expose the capability to manage the relevant underlying resources in a coordinated manner transparent to whatever external systems are interacting with the service/resource management interfaces. In the adjacent figure, one or more MSS (typically a BSS/OSS in a telecom environment) are depicted providing the needed management interfaces. Some SMI could be exposed directly from the service. For example, an SMI might expose an administrative interface to perform configurations very unique to that service such as to assign users to a collaboration service like Microsoft Office Lync service or assign users to a Dynamics CRM Online implementation. Alternatively, certain SMI could be Figure 16 – Exposing B2B provided by an MSS that provides management functions on management services behalf of a cloud application. Here again, Microsoft System Center 2012 is suitable for this role.Microsoft Communications and Media Industries 15 Jan 2013 Page 23
  25. 25. Multi-Cloud Service Delivery & End-to-End Management Figure 17 below illustrates what becomes possible when the SMI interfaces are exposed to other service providers to enable end-to-end service management across a multi-cloud, multi- Figure 17 – Visualizing B2B service management enterprise domain scenario. Leveraging this new information, it becomes possible for the service composition process to proceed now along four parallel paths: 1. Functional Interface to realize the core value achieved from the service composition itself. 2. Provisioning to define the end-to-end provisioning processes and sequence. 3. Service Assurance to define and populate a service model with Fault and Performance event data used to measure QoS and monitor SLA conformance. 4. Usage events for Policy evaluation, Settlement, and Billing purposes. Each of the above dashboards can now incorporate the information available from the relevant SMIs. The SMI are not just one-way interfaces. The “The provisioning interfaces Cloud Service Provider is able to maintain information described become very important on the status of the Communications Service Provider’s in a true Service Syndication services that content streaming is ultimately dependent scenario. Using a standard and upon. The Communications Service Provider is able to reusable SMI for provisioning maintain status of the SaaS component that is eliminates the need for a custom streaming to their customer over a wireless network. integration effort to launch a new All stakeholders are now able to subscribe to and service syndication partner.” collect event information from the services that are relevant to the end user’s experience. In fact, Management as a Service becomes a new potential type of premium service. The provisioning interfaces described become very important in a true Service Syndication scenario. Using a standard and reusable SMI for provisioning eliminates the need for a custom integration effort to launch a new service syndication partner.Microsoft Communications and Media Industries 15 Jan 2013 Page 24
  26. 26. Multi-Cloud Service Delivery & End-to-End Management For the Service Assurance SMI, the ultimate test of whether the correct metrics are being collected and evaluated or not is simply whether the dashboards accurately display the status of the composite service. If the dashboards are green and the customer has a complaint then the metrics being collected are missing something important and need to be adjusted to more Figure 18 – Another view of the SES Management Solution vision used in an ITU-T submission. accurately reflect reality from a customer’s viewpoint. The Simple Management Interface (SMI) design template makes it feasible to iterate on this until dashboards sufficiently reflect customer reality. Figure 18 above provides another view of the multi-cloud service management reference architecture. Note how the Functional Interfaces are logically connect to create a service composition and the Simple Management Interfaces communicate with Management Support Systems / Operations Support Systems to provide the visibility necessary to enable the service provider to have a great operations experience even with a complex multi-cloud application.Microsoft Communications and Media Industries 15 Jan 2013 Page 25
  27. 27. Multi-Cloud Service Delivery & End-to-End Management Cross-Industry and M2M Applicability The telecommunications industry has developed expertise in managing distributed service creation and delivery over virtualized telecom network resources. Extensive work has been done by various telecom industry standards organizations to define a common framework to facilitate management of network elements and service overlays. This reference architecture describes a way to now apply this evolved expertise to the broader set of management issues associated with multi-cloud service and resource management. However, the cloud ecosystem is not telecommunications network centric. The reference architecture can be used to leverage the expertise of the telecommunications service providers in the broader use case of multi-cloud resource management in a Web 2.0 world across multiple industry verticals. The TM Forum SES Management Solution and this Multi-Cloud Service Delivery and End-to-End Management Reference Architecture is only concerned with the design pattern of having Functional Interfaces and Simple Management Interfaces associated with each service. While the pattern leverages best practices learned by the telecommunications industry managing widely distributed mission critical networks, it is not concerned with the ultimate business purpose of those services. Because of this abstraction, the reference architecture is equally useful when used to implement SOA best practices in any industry vertical such as Healthcare, Retail, Manufacturing, Financial, Logistics, Public Sector and Defense. Figure 19 – M2M Cross Industry Example of Multi-Cloud Service Delivery The Machine to Machine (M2M) use case helps illustrate the applicability of the Multi-Cloud Service Delivery and End-to-End Management Reference Architecture to multiple industry scenarios. A Windows Phone can easily become a device in a M2M scenario context. A Line of Business Application (LOB) running on the device interacts with sensors such as GPS, RFID or NFC etc. and communicates specific events to an industry specific cloud hosted LOB application as represented in the top “Applications” band of Figure 19.Microsoft Communications and Media Industries 15 Jan 2013 Page 26
  28. 28. Multi-Cloud Service Delivery & End-to-End Management Any of these scenarios would become significantly more practical if it were possible to manage that application across the M2M / Multi-Cloud environment and achieve a meaningful capability for end-to-end management. Note however that regardless of the industry vertical involved, the communications “cloud” with its exposed services is one of the critical components and prerequisite for successful service operation.Microsoft Communications and Media Industries 15 Jan 2013 Page 27
  29. 29. Multi-Cloud Service Delivery & End-to-End ManagementCost of Excellence in Quality of ServiceEvery customer initiated contact is a costly event. To minimize their occurrence, service providerslearned to harden their infrastructures and services to minimize failures sufficiently to meet customerexpectations. This is a primary reason why certain components are built to 99.995% reliability standardsor better. This was driven by economic necessity and is a reality of a network or cloud service deliverybusiness. Thus the lesson learned by the CSPs needs to be applied by cloud service providers as wellbefore mission critical line of business applications move in serious fashion to cloud computing.When there is a customer contact, the customer service agent ideally should have all of the appropriateinformation immediately accessible and actionable. This might include Service Order History, Trouble /Performance / SLA History, and Billing information. The goal is for the agent to be able to handle duringthe initial contact any questions concerning billing, service configuration, faults, or performance. Thisincludes being able to see via service dashboards and event lists what has transpired and to drill down toobtain greater details on any significant item. The agent should also be able to initiate an order for newor changed service configurations as a possible outcome to the customer initiated contact.A self-service portal needs to provide sufficient information and capabilities to preclude the generationof a customer initiated call into a work center. Particularly when it comes to meeting the needs of theservice developer building, deploying, or maintaining a service leveraging cloud computing resources, aself-service portal should successfully guide the developer through all business and technicalinteractions with the cloud. This includes the process of setting up an account, consuming service APIs,building an application that will work reliably, deploying the application to the cloud, configuring cloudresources efficiently, and being able to visualize usage and performance via dashboards.There are two primary measures that determine the success of service delivery businesses in thecommunications and media industries: 1. Customer Satisfaction – Will they be satisfied with product/service and if there is a problem, will they be satisfied with Customer Service? If an agent demonstrates credible knowledge about a service and of any service problems and conveys a sense of decisive and effective action, customer satisfaction will remain high and customer churn will be suppressed. Agents must have the proper information and tools in front of them to be effective. Alternatively, a self- service portal must be able to convey the same information enabling the user to find the answers they seek. 2. Operational Expense – How many steps are necessary to address typical issues? If approximately 80% of problems can be handled effectively at the first point of contact, whether a self-service portal or an agent, then the OpEx incurred handling problems is minimized and the profitability of the service is protected. However, if the agent does not have useful tools in front of them and can only create a trouble ticket and pass that off to another work center for action, then Operational Expense could skyrocket making the service in question unprofitable. This isMicrosoft Communications and Media Industries 15 Jan 2013 Page 28
  30. 30. Multi-Cloud Service Delivery & End-to-End Management especially true for transient problems that are difficult to replicate. If the error is not capture in real-time by recording the event along with actionable fault and performance data permitting root cause analysis, the expenses of handling trouble reports and acting on them after the fact may exceed revenues. Figure 20 – Components of Service QualityMicrosoft Communications and Media Industries 15 Jan 2013 Page 29
  31. 31. Multi-Cloud Service Delivery & End-to-End ManagementValue of a Service BrokerThis section is not intended to be a comprehensive overview of Service Brokers or Service DeliveryPlatforms. The intent of this section is restricted to explaining certain key aspects of a Service DeliveryPlatform particularly relevant from a Multi-Cloud Service Delivery Framework or Software EnabledServices Management point of view. When the focus is on exposing a services layer and managing anintegration surface that spans multiple platforms or clouds, the term Cloud Service Broker or ServiceDelivery Broker is used to differentiate from the somewhat overused term of SDP.The concept of a Service Delivery Platform is relatively simple provided the services are all containedwithin one well-defined boundary; a Windows Phone Application Store or an SDP for one set offunctions in a mobile operator’s network. However, once service providers begin to meld togetherservices from multiple domains, problems abound. Setting aside service interoperability for a moment,the other major issue has to do with lifecycle management and the details of operations andmaintenance (Fulfillment, Assurance, and Billing) of the services and their components. If all theservices are contained within one service provider’s domain, then presumably, all of the services arealready managed by an established set of BSS/OSS15. As a result, the SDP itself has a relatively minimalrole to play in end-to-end service management. However, new issues begin to crop up with a servicebundle consisting of discrete services from multiple domains. These issues become more interestingwhen the services from different domains will be actually integrated together in a loosely coupledservice mash-up.For years the telecommunications industry has attempted to manage complexity with rigorous enforcedsets of rules for on-boarding services onto a Service Delivery Platform. The so-called “walled garden”approach required services to be built to very specific standards and to become certified especially onhow they interact with other services and the network before being allowed to operate. This particulartype of certifying was sometimes referred to as “on boarding” a service onto the SDP.The concept of a Service Delivery Framework (SDF) was defined that could enable a community ofservice providers each managing their own domain of services, to collaborate and deliver manageableservices controlled by local SDPs and associated BSS/OSS for management functions. The core focus ofthis work was on the ability to manage the resulting services end-to-end.The question then arises “what is different” about the Service Delivery Platform envisioned by the SESManagement Solution from conventional telecom SDPs? The following discussion explains thatdifference.15 Business Support Systems / Operations Support Systems. The enterprise applications that a CommunicationsService Provider or Cable Operator typically employs to manage all business processes from initial order throughBilling.Microsoft Communications and Media Industries 15 Jan 2013 Page 30
  32. 32. Multi-Cloud Service Delivery & End-to-End Management The Telco SDP There have been a number of attempts by CSPs and their telecom network centric suppliers to leverage telecom network SDPs to manage a broader array of services exposed via APIs. These telecom led efforts have had limited success. The reasons continued to be debated. However, one can speculate that the telecom centric SDPs tend to be too highly specialized around the needs of telecom/mobile network services. These telecom-centric SDPs implement and enforce specialized standard often very complex interfaces as well as methods and procedures that do not appear relevant to the broader Web 2.0 services marketplace and cloud computing in general. In Figure 21 below, services are depicted as existing in three distinct reference categories. Granted, this is an over simplification but it provides a way to explain some key concepts. Each Figure 21 – Multi-Cloud Service Management column represents a major silo of application development. Although the technical details, platforms and tools tend to be different for each silo, each silo loosely adheres to the following architectural concepts: • Fine grained service creation and management using tools often unique to that silo. • Coarse grained service abstractions typically via SOAP and Web Services interfaces. At the far right is the telecom network environment. This is where telecom SS7 / IP Multimedia Subsystem (IMS) lives and Service Delivery Platforms excel at creating and implementing services that require real-time event processing as well as policy, charging, and rules functions in the course of setting up connections and delivering services.Microsoft Communications and Media Industries 15 Jan 2013 Page 31
  33. 33. Multi-Cloud Service Delivery & End-to-End Management In the middle column is the enterprise IT technology stack. In this domain, IT professionals design and implement mission critical Line of Business (LOB) applications appropriate for their industry. Each industry, such as Public Sector, Financial Services, Healthcare, Manufacturing, Retail, Communications and Media have their own interpretations of an Enterprise IT Reference Architecture that in turn typically leverages best practices ( such as from ITIL and TOGAF) for management and governance. For example, the communication industry’s reference architecture is the TM Forum Frameworx. Many older legacy mainframe, client/server, enterprise service bus environments live in this space as well as newer service oriented implementations. Finally on the left side is the Web 2.0 cloud service developer. Admittedly, an IT Professional implementing enterprise service oriented architecture solutions could also be represented by this section of the drawing. However, the intent is to emphasize newer Web 2.0 renditions of services and service compositions. The bulk of 3rd party developers being recruited into various developer ecosystems live in this space. The trend here is towards lighter weight interfaces such as REST using JSON. If the enterprise in question is a telecom or cable company, then the BSS/OSS of that organization lives in that center column. If that center column enterprise some other industry such as a financial enterprise, then the industry reference architecture for a financial institution would replace the “BSS/OSS” reference architecture depicted in the center silo. The ICT16 Service Delivery Broker Given that the concept of a Service Delivery Platform evolved first in the telecom industry, it is not surprising that many telecoms attempted to extend those SDPs to also govern the creation, deployment and operation of web services. This was greatly accelerated with the original vision of IMS and its notion of an application layer hosting services governed by underlying IMS control functions for policy, charging and rules. There have been several attempts at expanding telecom/network services centric SDP environments to assume overall lifecycle management and runtime control over a broader array of services including those being abstracted by the Enterprise IT and Web/Cloud developers. What evolved instead during the last ten years was the concept of Converged Service Delivery for the Information Communications Technology industry as a whole. In addition to the traditional Communications Service Provider (CSP) and Cable Operators (MSO), new types of service providers offering internet web hosting, cloud services, and the social network platforms expanded the requirements for service lifecycle management and runtime from a telecom network centric topic to much broader ICT topic. The growth of the internet and later cloud computing caused the telecom industry to no longer be the dominate force in service creation16 ICT – “Information and Communications Technology”Microsoft Communications and Media Industries 15 Jan 2013 Page 32
  34. 34. Multi-Cloud Service Delivery & End-to-End Management and delivery. Furthermore, the evolution of services orientation approach to architecture contributed additional needs to accelerate and manage more effectively at the Integration Framework layer. The requirements of an SDP still exist. However, solutions now need to appeal to the broader needs of the ICT industry as a whole. This ICT Service Delivery Broker can provide a set of reusable core capabilities (services) to both speed development processes and to support runtime operations. Some of the reusable services such an SDB can provide include: • transports, • bindings and protocol mediation, • support for all needed message patterns, • common tasks such as security & access control, • event processing engine, • routings, • performance / traffic monitoring, • mechanisms for real time visibility into performance and usage including Dashboards. API Management APIs are becoming the critical common currency of service creation and delivery. Developers have been creating interfaces to applications and services for years. However in the absence of the structure that a service delivery broker can provide, these APIs provide only a limited capability for application integration, assume or favor a specific programing language, contain programing techniques that are not best practice from an industry level (example non W3C compliant code generation) and often require significant system integration efforts to implement. When an organization truly adopts a service orientation there is a very significant material impact on how APIs are built and how they are used. APIs developed without a true services orientation have a tendency to be coarse grained providing a limited exposure to the underlying fine grained features. Often much of the actual work flow in applications happens outside of these coarse grained interfaces. Therefore, there tends to be a fewer number of APIs that are only used for a limited subset of use cases. For instance, a function might be exposed externally via a JAVA API but internal users of that service use different, more feature rich interfaces. When a true services orientation is adopted, the same APIs become used by both internal and external users. Policy and rules evaluation processes become reusable supporting services invoked in conjunction with the use of a service creating policy-based use governance enabling secure reusability. As the number of internal only APIs is reduced, the number of published reusable service APIs can expand greatly. This leads to a new requirement of being able to manage efficiently a growing catalog of services throughout their lifecycle.Microsoft Communications and Media Industries 15 Jan 2013 Page 33
  35. 35. Multi-Cloud Service Delivery & End-to-End Management In Figure 22 below we have identified two sets of APIs: • Functional Interfaces • Management interfaces Adding Simple Management Interfaces in addition of the existing functional interfaces contributes additional numbers of APIs that need to be managed just within one service provider. If there are only two services involved in either an intra-service provider or inter-service provider integration, it is easy to imagine how the functional interfaces can be integrated Figure 22 – Functional and Management APIs together to create a combined service offering and how each of the Simple Management Interfaces could be combined to define end-to-end management. Difficulties arise when the number of services becomes very large. Custom point-to-point integration can get the job done as long as there are not frequent changes. However, when the APIs number in the thousands, when there are frequent updates and version control becomes an issue, or when the number of service provider domains expands into many to many relationships, a much more systematic approach is needed for API Service Lifecycle Management, Integration, and Runtime operations. The prospect of M2M should drive home the point that a much more efficient and reliable means of service lifecycle and operations management is required.Microsoft Communications and Media Industries 15 Jan 2013 Page 34
  36. 36. Multi-Cloud Service Delivery & End-to-End Management A broker is one mechanism that addresses these operational problems. A service delivery broker or cloud service broker does this by providing some of the core functions defined in the Figure 23 – The Service Delivery Broker (SDB) as an API management system TM Forum Integration Framework as reusable services. Furthermore, by facilitating the process of creating and integrating management functions exposed by each Simple Management Interface, a broker can reduce the need for custom integration that would otherwise be required to effectively manage these new service compositions. An SDB can provide the following API management functions: • Service API Catalog Functions • ITILv3 2011 Aligned Service Lifecycle Management and Metadata Model Management • Tools to Implement standard Simple Management Interfaces • Wizards to support a true services orientation • Contract first development methodology and Governance • Runtime Management Operations Depending upon the service in question, the broker could be involved in helping to manage the lifecycle management of services APIs, the runtime management of the Service APIs, or both. Depending upon the context of the service, and the design decisions of the service provider or enterprise implementing enterprise service oriented architecture, the broker could accommodate the allocation of specific functions to different resources. For instance, in the case of a set of cloud services that are largely hosted web services, the broker could provide certain necessary policy, charging, and rules based functions directly. Alternatively, some functions could instead be handled by a dedicated billing BSS/OSS application. Alternatively, in the case of certain services leveraging telecom service exposure layer, it may well be optimal to leverage the IMS Policy, Charging, and Rules Function (PCRF) in the network.Microsoft Communications and Media Industries 15 Jan 2013 Page 35
  37. 37. Multi-Cloud Service Delivery & End-to-End Management This approach enables the reference architecture to provide three key value propositions mentioned in the introduction: 1. A Great User Experience 2. A Great Developer Experience 3. A Great Operations Experience In Figure 24, there are two cloud stacks depicted on the Telecom Operator side. One depicts the Telecom Cloud infrastructures that virtually all CSPs and MSOs are implementing. The other stack is the telecom network itself. The telecom network (voice/data, core transport, backhaul, access) is just another cloud running over a virtualized stack of resources exposing services for consumption by developers in service compositions. Figure 24 – The SDB in a Services Orientated developer governance role Several important points need to be clarified at this point: 1. Service APIs can be created independent of a Service Broker: Most service APIs being exposed today are in fact created independently of the governance provided by a Service Delivery Broker. They may be created out of fine grained services by a lower level Service Delivery Platform and exposed as coarse grained services as discussed in Figure 21. However, the wide inconsistency today in the application of standards as these services are exposed results in a significant amount of custom integration work when combining these service APIs into more complex offerings. 2. Many Service Delivery Brokers: Figure 24 is not meant to imply there should be one “all-controlling” über Service Delivery Broker. In reality, there will be many SDBs in operation. An SDB enables one view into a universe of Service APIs. It is likely that most service providers will want to have a Cloud / Service Delivery Broker to support theirMicrosoft Communications and Media Industries 15 Jan 2013 Page 36
  38. 38. Multi-Cloud Service Delivery & End-to-End Management localized developer ecosystem and to support their version of a service marketplace. Enterprises are beginning to discover they too can use this type of Service Delivery Broker to guide a true service orientation across their enterprise architecture. 3. SDB as a Service: Some stakeholders may be interested in leveraging a “Service Delivery Broker as a Service” offering. A service provider could gain the benefits of managing their own view into a set of service APIs without incurring the cost and expense of implementing their own Broker. An enterprise can use a cloud hosted SDB as a core part of their services orientation governance. 4. SDB as a mediator between other Service Domains: A particular service may become exposed from two or more service brokers. The broker a developer or enterprise chooses to use will depend upon the value that particular broker brings to the development, runtime management, and service monetization process versus a different broker offering the similar services. A well-executed SDB can deliver up to a 50% reduction in service creation and integration costs for an enterprise or service provider / operator. SDB as a Service with global reach could help create consistent service creation and runtime environments very efficiently. This is having two impacts: • There is a trend towards lightweight APIs that work consistently across multiple cloud and service domains. For instance REST Web Services using JSON. • How well any given SDB is executed and helps operators achieve significant operational efficiencies and drive service monetization will likely determine which SDB implementations will become most prevalent in the future.Microsoft Communications and Media Industries 15 Jan 2013 Page 37
  39. 39. Multi-Cloud Service Delivery & End-to-End ManagementImplementing Multi-Cloud Service Management with MicrosoftIn this section we will consider how one can build manageable services on either a Microsoft On-Premises Cloud or Public Cloud employing the techniques outline by the TM Forum Software EnabledServices Management Solution.The core Microsoft components relevant to this discussion are:On-Premises Private/Public Cloud: • System Center 2012 • Windows Server 2008 R2 or Windows Server 2012. • SQL ServerOff-Premises Public Cloud: • Windows Azure • SQL AzureIn order to offer an SLA (Service Level Agreement) on a service that depends upon the performance ofseveral underlying component services, each of those component services must be manageable. It is not sufficient to be able to measure the health and welfare of just the service itself. True management of an individual cloud service means managing the entire technology stack including the relevant parts of the virtualized compute layer and virtualized network layer. The Microsoft cloud platform can offer the developer a “chassis” on which to deploy a service that can be managed as envisioned by the TM Forum SES Management Solution. Figure 25 – SMI as a Value Added Service Certain aspects of servicemanagement are unique to the service itself. The SMI associated with these application specificmanagement functions may need to be implemented by the developer as a function within the serviceitself. For example, a service may require specific users to be authorized to use that service or toperform functions within the confines of a predefined role. However, other management functions mayneed the assistance of an Operations Support System (OSS), such as System Center 2012, that is awareMicrosoft Communications and Media Industries 15 Jan 2013 Page 38
  40. 40. Multi-Cloud Service Delivery & End-to-End Managementof the relationship between a given service instance and the virtualized resources supporting it. InFigure 26, a developer seeking to build a service that will be published in a service catalog can plan onFigure 26 – Flexible SMI deployment optionsleveraging the capability of Microsoft Cloud platforms to expose interfaces necessary to deploy andmanage that service and to report on the health and welfare of the underlying resources supporting thatservice. Leveraging the concept of Concurrent Contracts,17 the developer may need to allow for thepossibility of having more than one contract available for the same service.17 For a discussion of Concurrent Contracts see: http://www.soapatterns.org/concurrent_contracts.phpMicrosoft Communications and Media Industries 15 Jan 2013 Page 39

×