Abstract:
A method for providing a cloud-based service includes receiving information from a customer of the service over a conversational interface, the information identifying a requirement of the customer related to a resiliency of the service, and identifying a service provider who provides the service in a manner that satisfies the requirement. A method for building a knowledge base of cloud-based service providers includes receiving information from a service provider, the information specifying at least one resiliency attribute of the service provider, matching the information to a standardized service descriptor, wherein the service descriptor is indexed within an ontology-based organizational framework that indexes a plurality of service descriptors, and storing the service descriptor for the service provider.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    The present invention relates generally to cloud computing and relates more specifically to providing information technology resiliency for cloud-based services. 
         [0002]    Cloud computing is the use of computing resources (e.g., hardware and software) that are delivered as a service over a network (e.g., the Internet). For instance, an enterprise (e.g., a business or other organization) may move a portion of its information technology (IT) infrastructure to “the cloud” as a means of simplifying maintenance of the IT infrastructure and providing resiliency (i.e., availability of data in the face of infrastructure outage). 
         [0003]    Conventionally, the burden is on the customer to provision their cloud-based services for resiliency. For instance, many cloud-based service providers require customers to complete a risk analysis checklist in order to help the service providers meet the customer&#39;s resiliency needs. However, many customers do not actually know how to specify their resiliency needs. Moreover, even if the customer is able to accurately specify its resiliency needs, the service provider may not support the resiliency level required or may exit from the marketplace before the customer&#39;s contract expires. 
       SUMMARY OF THE INVENTION 
       [0004]    A method for providing a cloud-based service includes receiving information from a customer of the cloud-based service over a conversational interface, where the information identifies a requirement of the customer related to a resiliency of the service, and identifying at least one service provider who provides the cloud-based service in a manner that satisfies the requirement of the customer. 
         [0005]    A method for building a knowledge base of cloud-based service providers includes receiving information from a cloud-based service provider, wherein the information specifies at least one resiliency attribute of the cloud-based service provider, matching the information to a standardized service descriptor, wherein the standardized service descriptor is indexed within an ontology-based organizational framework that indexes a plurality of standardized service descriptors, and storing the standardized service descriptor for the cloud-based service provider. 
         [0006]    A method for providing a cloud-based service includes receiving information from a customer of the cloud-based service over a conversational interface, the information identifying a requirement of the customer related to a resiliency of the service, generating a first model that represents the requirement of the customer, receiving information from a cloud-based service provider, wherein the information specifies at least one resiliency attribute of the cloud-based service provider, generating a second model that represents the at least one resiliency attribute, wherein the second model is indexed within an ontology-based organizational framework that indexes a plurality of models associated with a plurality of cloud-based service providers, matching the first model to the second model when the at least one resiliency attribute indicates that the cloud-based service provider is capable of satisfying the requirement of the customer, and forwarding information about the cloud-based service provider to the customer. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
           [0008]      FIG. 1  is a block diagram depicting one example of a network within which embodiments of the present invention may be deployed; 
           [0009]      FIG. 2  is a flow diagram illustrating one embodiment of a method for providing information technology resiliency in a cloud-based services marketplace; 
           [0010]      FIG. 3  is a flow diagram illustrating another embodiment of a method for providing information technology resiliency in a cloud-based services marketplace; and 
           [0011]      FIG. 4  is a high-level block diagram of the resiliency analysis method that is implemented using a general purpose computing device. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    In one embodiment, the invention is a method and apparatus for providing information technology (IT) in a cloud-based services marketplace. Embodiments of the invention shift the burden of provisioning for resiliency from the customer to the service marketplace. In particular, embodiments of the invention model a customer&#39;s resiliency needs and various service providers&#39; abilities to provide resiliency and then match the customer with the service providers who can potentially meet the customer&#39;s resiliency needs. 
         [0013]      FIG. 1  is a block diagram depicting one example of a network  100  within which embodiments of the present invention may be deployed. The network  100  may be any type of communications network, such as for example, an Internet Protocol (IP) network (e.g., an IP Multimedia Subsystem (IMS) network, an asynchronous transfer mode (ATM) network, a wireless network, a cellular network, a long term evolution (LTE) network, and the like). An “IP network” is broadly defined as a network that uses Internet Protocol to exchange data packets. Additional exemplary IP networks include Voice over IP (VoIP) networks, Service over IP (SoIP) networks, and the like. 
         [0014]    In one embodiment, the network  100  may comprise a core network  102 . The core network  102  may be in communication with one or more access networks  120  and  122 . The access networks  120  and  122  may include a wireless access network (e.g., a WiFi network and the like), a cellular access network, a cable access network, a wired access network and the like. In one embodiment, the access networks  120  and  122  may all be different types of access networks, may all be the same type of access network, or some access networks may be the same type of access network and other may be different types of access networks. The core network  102  and the access networks  120  and  122  may be operated by different service providers, the same service provider or a combination thereof. 
         [0015]    In one embodiment, the core network  102  may include an application server (AS)  104  and a database (DB)  106 . Although only a single AS  104  and a single DB  106  are illustrated, it should be noted that any number of application servers  104  or databases  106  may be deployed. For instance, the core network  102  may comprise a portion of a cloud environment in which services and applications are supported in a highly distributed manner. 
         [0016]    In one embodiment, the AS  104  may comprise a general purpose computer as illustrated in  FIG. 4  and discussed below. In one embodiment, the AS  104  may perform the methods and algorithms discussed below related to providing information technology (IT) resiliency in a cloud-based services marketplace. For instance, the AS  104  may comprise a datacenter that supports cloud-based services (e.g., data provisioning or other IT-related services). In one embodiment, the AS  104  includes a dynamic conversational user interface for interacting with service providers and customers in the network  100 . 
         [0017]    In one embodiment, the DB  106  stores data relating to the cloud-based services supported by the AS  104  and relating to customers of the cloud-based services; thus, in one embodiment, the DB  106  functions as a service knowledge base. For instance, the DB  106  may store standardized resiliency specification descriptions (service descriptors) and resiliency models for service providers and customers. This information may be stored in encrypted form in order to protect any information that is deemed to be sensitive. Although only one DB  106  is illustrated, the network  100  may include multiple databases. For instance, separate databases may be maintained for storing the customer and service provider resiliency models. 
         [0018]    In one embodiment, the access network  120  may be in communication with one or more user endpoint devices (also referred to as “endpoint devices” or “UE”)  108  and  110 . In one embodiment, the access network  122  may be in communication with one or more user endpoint devices  112  and  114 . 
         [0019]    In one embodiment, the user endpoint devices  108 ,  110 ,  112  and  114  may be any type of endpoint device that is, capable of accessing services from a cloud-based service provider, such as a desktop computer or a mobile endpoint device such as a cellular telephone, a smart phone, a tablet computer, a laptop computer, a netbook, an ultrabook, a portable media device (e.g., an MP3 player), a gaming console, a portable gaming device, and the like. It should be noted that although only four user endpoint devices are illustrated in  FIG. 1 , any number of user endpoint devices may be deployed. In one embodiment, any of the user endpoint devices may have one or more sensors integrated therein. These sensors may include, for example, location sensors, environmental sensors, acoustic sensors, position sensors, optical sensors, pressure sensors, proximity sensors, and the like. The AS  104  may subscribe to the outputs of these sensors. 
         [0020]    It should be noted that the network  100  has been simplified. For example, the network  100  may include other network elements (not shown) such as border elements, routers, switches, policy servers, security devices, a content distribution network (CDN) and the like. 
         [0021]      FIG. 2  is a flow diagram illustrating one embodiment of a method  200  for providing information technology resiliency in a cloud-based services marketplace. In particular, the method  200  generates a standardized service descriptor for a cloud-based service provider. As discussed in further detail below, the service descriptor may be used to match the service provider with customers who required a level of resiliency that the service provider is capable of providing. The method  200  may be executed, for example, by the AS  104  illustrated in  FIG. 1 . As such, reference is made in the discussion of the method  200  to various components of the network  100  illustrated in  FIG. 1 . 
         [0022]    The method  200  begins in step  202 . In step  204 , the AS  104  sends a message to a cloud-based service provider (e.g., to a user endpoint device  108 - 114  operated by the service provider). The message seeks the service provider&#39;s resiliency attributes. The resiliency attributes may be defined in terms of one or more metrics, domains, functions, or sources of failure. The metrics may include, for example, typical service-level agreement key performance indicators such as: the service&#39;s availability, reliability, integrity, maintainability, or confidentiality. The domains may include, for example, typical realms of administrative authority, such as: network, systems, middleware, service, or business. The functions may include, for example, typical types of cloud-based services, such as: monitoring, incident/error management, security, governance, or compliance. The sources of failure may include, for example, typical broad sources of service errors, such as: human, machine, or disaster. 
         [0023]    In step  206 , the AS  104  receives a response from the service provider. The response includes at least some of the resiliency attributes that the AS  104  solicited in step  204 . 
         [0024]    In step  208 , the AS  104  matches the resiliency attributes to at least one service descriptor. In one embodiment, this matching involves querying the DB  106  for existing service descriptors that most closely match the resiliency attributes provided by the service provider. 
         [0025]    In step  210 , the AS  104  determines whether the service descriptor for the service provider can be finalized. In one embodiment, this involves determining whether enough is known about the service provider&#39;s resiliency attributes to identify the service descriptor that best represents the service provider. In one embodiment, the AS  104  is considered to have enough information to finalize the service descriptor if all of the resiliency attributes can be mapped to information technology artifacts. The more information that is provided up-front (e.g., in the first iteration of step  206 ), the more automated the process can be. If the AS  104  concludes in step  210  that more information about the service provider&#39;s resiliency attributes is required, then the method  200  returns to step  204  and the AS  104  proceeds as described above (e.g., by sending a further request to the service provider). 
         [0026]    Alternatively, if the AS  104  concludes in step  210  that no further information is needed in order to finalize the service descriptor for the service provider, then the method  200  proceeds to step  212 . In step  212 , the AS  104  stores or associates the service descriptor that best matches the service provider&#39;s resiliency attributes with the service provider. In one embodiment, this association is stored in the DB  106 . 
         [0027]    The method  200  ends in step  214 . 
         [0028]    In one embodiment, service descriptors include tags that assist the AS  104  in matching the service descriptors to service-provider-specified resiliency attributes. Similar service descriptors can be grouped together to form service-provider-side resiliency models. In one embodiment, the models are ontology-based. In particular, resiliency attributes can be indexed within in an organizational framework that represents knowledge about the service providers. For instance, specific resiliency attributes may be represented as concepts within the general domain of service provider resiliency, and the relationships between those concepts can be further illustrated. As discussed above, the general domain of service provider resiliency may include concepts (resiliency attributes) such as metrics, domains, functions, and sources of failure. Any of these concepts may be related to others of the concepts and may further include sub-concepts (e.g., the metrics concept might include sub-concepts such as availability, reliability, integrity, maintainability, or confidentiality). 
         [0029]    As discussed above, modeling resiliency on the service-provider-side is one part of the present solution; further embodiments of the invention also model customer-side resiliency requirements so that customers and service providers can be matched effectively. 
         [0030]      FIG. 3  is a flow diagram illustrating another embodiment of a method  300  for providing information technology resiliency in a cloud-based services marketplace. In particular, the method  300  models a cloud-based service customer&#39;s resiliency requirements and identifies service providers or service products that meet these resiliency requirements. The method  300  may be executed, for example, by the AS  104  illustrated in  FIG. 1 . As such, reference is made in the discussion of the method  300  to various components of the network  100  illustrated in  FIG. 1 . 
         [0031]    The method  300  begins in step  302 . In step  304 , the AS  104  sends a message to a cloud-based service customer (e.g., to a user endpoint device  108 - 114  operated by the customer). The message seeks the customer&#39;s resiliency requirements. The resiliency requirements may be defined in terms of one or more metrics, domains, functions, or sources of failure. The metrics may include, for example, typical service-level agreement key performance indicators such as: the service&#39;s availability, reliability, integrity, maintainability, or confidentiality. The domains may include, for example, typical realms of administrative authority, such as: network, systems, middleware, service, or business. The functions may include, for example, typical types of cloud-based services, such as: monitoring, incident/error management, security, governance, or compliance. The sources of failure may include, for example, typical broad sources of service errors, such as: human, machine, or disaster. 
         [0032]    In step  306 , the AS  104  receives a response from the customer. The response includes at least some of the resiliency requirements that the AS  104  solicited in step  304 . In one embodiment, the messages exchanged in steps  304  and  306  are sent and received over a dynamic, conversational user interface. The conversational user interface allows the customer to specify his or her resiliency requirements in a conversational manner, using natural language. Thus, the customer is not necessarily required to have an in-depth understanding of the cloud-based service infrastructure in order to convey his or her resiliency requirements. 
         [0033]    In step  308 , the AS  104  matches the resiliency requirements to at least one service descriptor representing a service provider or service product. In one embodiment, this matching involves querying the DB  106  for existing service descriptors that most closely match the resiliency requirements provided by the service provider. The degree of the match required (e.g., exact match, match within a specified tolerance, etc.) may be specified by the customer. In one particular embodiment, unsatisfactory or non-matching service descriptors are first excluded from consideration, and the remaining service descriptors are then analyzed in order to determine which service descriptors most closely match the stated requirements. 
         [0034]    In step  310 , the AS  104  determines whether at least one service descriptor matching the resiliency requirements has been found. In one embodiment, multiple potentially matching service descriptors may be found. If the AS  104  concludes in step  310  that no matching service descriptors have been found, then the method  300  returns to step  304  and the AS  104  proceeds as described above (e.g., by sending a further request to the customer). As an alternative, the AS  104  may also propose alternative resiliency requirements or service providers or service products that most closely meet the customer&#39;s resiliency requirements. 
         [0035]    Alternatively, if the AS  104  concludes in step  310  that at least one service descriptor matching the resiliency requirements has been found, then the method  300  proceeds to step  312 . In step  312 , the AS  104  forwards information about the service providers or service products whose service descriptors match the resiliency requirements to the customer. The AS  104  also stores the customer&#39;s resiliency requirements and potential service providers/service products as part of a model of the customer&#39;s resiliency needs. In one embodiment, this model is stored in the DB  106 . 
         [0036]    The method  300  ends in step  314 . 
         [0037]    The model of the customer&#39;s resiliency needs may be continuously updated by the AS  104  in substantially real time using a method substantially similar to the method  300 . However, rather than send a message directly to the customer to solicit the resiliency needs (e.g., as in step  304 ), the AS  104  may build a new query for further service matching based on the current resiliency service to which the customer subscribes and/or any stored resiliency requirements. In one embodiment, the suitability of a service provider or service product as a failover alternative is based at least in part on a consideration of core marketplace functionality. In a further embodiment, the suitability is based at least in part on a consideration of stand-alone services. These steps may be implemented, for example, on a periodic basis (e.g., every x hours) or on an event-driven basis (e.g., a new service descriptor is added to the DB  106 ) to maintain an up-to-date list of failover alternatives. 
         [0038]    New matches (or a limited number of the top matches) identified by the new query may be stored as failover alternatives in the model of the customer&#39;s resiliency needs. In one embodiment, the failover alternatives are maintained as a ranked list. The ranking may be based on a calculated metric that assigns weights to various customer model criteria (e.g., cost, budget, etc.), number and/or type of resiliency requirements met, deployment timeline, and/or other criteria. In another embodiment, customer resiliency requirements are represented in a tree-like graph structure in which the root nodes of the tree represent business rules, and the remainder of the nodes represents the information technology stack. In this case, a graph matching algorithm can be employed to provide the ranking (e.g., based on the degree of similarity among potential matching services). 
         [0039]    Thus, in the event that the customer suffers a service failure, a failover may be identified from the model of the customer&#39;s resiliency needs. For instance, the failover may be a current service to which the customer explicitly subscribes as a failover, or it may be a failover stored in a list of identified alternatives as described above. 
         [0040]      FIG. 4  is a high-level block diagram of the resiliency analysis method that is implemented using a general purpose computing device  400 . The general purpose computing device  400  may comprise, for example, the application server  104  illustrated in  FIG. 1 . In one embodiment, a general purpose computing device  400  comprises a processor  402 , a memory  404 , a resiliency analysis module  405  and various input/output (I/O) devices  406  such as a display, a keyboard, a mouse, a stylus, a microphone or transducer, a wireless network access card, an Ethernet interface, and the like. In one embodiment, at least one I/O device is a storage device (e.g., a disk drive, an optical disk drive, a floppy disk drive). It should be understood that the resiliency analysis module  405  can be implemented as a physical device or subsystem that is coupled to a processor through a communication channel. 
         [0041]    Alternatively, the resiliency analysis module  405  can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices  406 ) and operated by the processor  402  in the memory  404  of the general purpose computing device  400 . Thus, in one embodiment, the resiliency analysis module  405  for providing information technology (IT) in a cloud-based services marketplace, as described herein with reference to the preceding figures, can be stored on a tangible computer readable storage medium or device (e.g., RAM, magnetic or optical drive or diskette, and the like). 
         [0042]    It should be noted that although not explicitly specified, one or more steps of the methods described herein may include a storing, displaying and/or outputting step as required for a particular application. In other words, any data, records, fields, and/or intermediate results discussed in the methods can be stored, displayed, and/or outputted to another device as required for a particular application. Furthermore, steps or blocks in the accompanying figures that recite a determining operation or involve a decision, do not necessarily require that both branches of the determining operation be practiced. In other words, one of the branches of the determining operation can be deemed as an optional step. 
         [0043]    While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. Various embodiments presented herein, or portions thereof, may be combined to create further embodiments. Furthermore, terms such as top, side, bottom, front, back, and the like are relative or positional terms and are used with respect to the exemplary embodiments illustrated in the figures, and as such these terns may be interchangeable.