U.S. patent application number 13/970671 was filed with the patent office on 2014-06-12 for providing information technology resiliency in a cloud-based services marketplace.
This patent application is currently assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION. The applicant listed for this patent is INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to Rahul P. Akolkar, Thomas E. Chefalas, Jim A. Laredo, Chang-Shing Perng, Anca Sailer, Frank A. Schaffa, Alla Segal, Ignacio Silva-Lepe, Tao Tao.
Application Number | 20140164184 13/970671 |
Document ID | / |
Family ID | 50882012 |
Filed Date | 2014-06-12 |
United States Patent
Application |
20140164184 |
Kind Code |
A1 |
Akolkar; Rahul P. ; et
al. |
June 12, 2014 |
PROVIDING INFORMATION TECHNOLOGY RESILIENCY IN A CLOUD-BASED
SERVICES MARKETPLACE
Abstract
A system for providing a cloud-based service includes a
processor and a computer readable storage medium that stores
instructions which, when executed, cause the processor to perform
operations including: 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, and identifying at least one service
provider who provides the cloud-based service in a manner that
satisfies the requirement of the customer. Another embodiment of a
system for providing a cloud-based service includes a
conversational interface for receiving information from a customer
of the cloud-based service, the information identifying a
requirement of the customer related to a resiliency of the service
and a resiliency analysis engine for identifying at least one
service provider who provides the cloud-based service in a manner
that satisfies the requirement of the customer.
Inventors: |
Akolkar; Rahul P.;
(Tuckahoe, NY) ; Chefalas; Thomas E.; (Somers,
NY) ; Laredo; Jim A.; (Katonah, NY) ; Perng;
Chang-Shing; (Golderns Bridge, NY) ; Sailer;
Anca; (Scarsdale, NY) ; Schaffa; Frank A.;
(Hartsdale, NY) ; Segal; Alla; (Mount Kisco,
NY) ; Silva-Lepe; Ignacio; (Putnarn Valley, NY)
; Tao; Tao; (Briarcliff Manor, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
INTERNATIONAL BUSINESS MACHINES CORPORATION |
Armonk |
NY |
US |
|
|
Assignee: |
INTERNATIONAL BUSINESS MACHINES
CORPORATION
Armonk
NY
|
Family ID: |
50882012 |
Appl. No.: |
13/970671 |
Filed: |
August 20, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13706884 |
Dec 6, 2012 |
|
|
|
13970671 |
|
|
|
|
Current U.S.
Class: |
705/26.61 |
Current CPC
Class: |
G06Q 30/0611 20130101;
G06Q 30/0627 20130101 |
Class at
Publication: |
705/26.61 |
International
Class: |
G06Q 30/06 20060101
G06Q030/06 |
Claims
1. A system for providing a cloud-based service, the system
comprising: a processor; and a computer readable storage medium
that stores instructions which, when executed, cause the processor
to perform operations comprising: 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; and identifying at
least one service provider who provides the cloud-based service in
a manner that satisfies the requirement of the customer.
2. The system of claim 1, wherein the requirement of the customer
is specified using natural language.
3. The system of claim 1, wherein the identifying comprises:
matching the requirement of the customer to a service descriptor
that describes a resiliency attribute of the at least one service
provider.
4. The system of claim 3, wherein the service descriptor is a
standardized representation of the resiliency attribute.
5. The system of claim 4, wherein the standardized representation
is indexed within an ontology-based organizational framework that
indexes a plurality of standardized representations describing
respective resiliency attributes of a plurality of different
service providers including the at least one service provider.
6. The system of claim 5, wherein each of the plurality of
standardized representations is associated with at least one
concept in the organizational framework.
7. The system of claim 6, wherein the at least one concept is one
of: a metric associated with the cloud-based service, a domain
associated with the cloud-based service, a function associated with
the cloud-based service, or a source of failure associated with the
cloud-based service.
8. The system of claim 7, wherein the metric is a measure of at
least one of: an availability of the cloud-based service, a
reliability of the cloud-based service, an integrity of the
cloud-based service, a maintainability of the cloud-based service,
or a confidentiality of the cloud-based service.
9. The system of claim 7, wherein the domain is at least one of: a
network domain, a systems domain, a middleware domain, a service
domain, or a business domain.
10. The system of claim 7, wherein the function is at least one of:
a monitoring function, an incident or error management function, a
security function, a governance function, or a compliance
function.
11. The system of claim 7, wherein the source of failure is at
least one of: a human, a machine, or a disaster.
12. The system of claim 3, wherein the matching comprises: querying
a database that stores service descriptors for a plurality of
service providers including the at least one service provider.
13. The system of claim 12, wherein the querying comprises:
excluding from consideration those of the plurality of service
providers whose service descriptors fail to match the requirement
of the customer; and selecting the at least one service provider
from among those of the plurality of service providers that are not
excluded.
14. The system of claim 13, wherein the querying further comprises:
selecting at least one alternative to the at least one service
provider; and generating a list in which the at least one service
provider and the at least one alternative are ranked according to a
metric.
15. The system of claim 14, wherein the metric assigns weight to a
plurality of criteria.
16. The system of claim 14, wherein the querying further comprises:
periodically repeating the querying, without prompting from the
customer, in order to update the list.
17. The system of claim 3, wherein service descriptor exactly
matches the requirement of the customer.
18. The system of claim 3, wherein service descriptor matches the
requirement of the customer within a specified tolerance.
19. A system for providing a cloud-based service, the system
comprising: a conversational interface for receiving information
from a customer of the cloud-based service, the information
identifying a requirement of the customer related to a resiliency
of the service; and a resiliency analysis engine for identifying at
least one service provider who provides the cloud-based service in
a manner that satisfies the requirement of the customer.
20. The system of claim 19, further comprising: a database for
storing a first model that represents the requirement of the
customer and for storing a plurality of service descriptors that
represent resiliency attributes of a plurality of service providers
including the at least one service provider.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 13/706,884, filed Dec. 6, 2012, which is
herein incorporated by reference in its entirety.
BACKGROUND OF THE INVENTION
[0002] The present invention relates generally to cloud computing
and relates more specifically to providing information technology
resiliency for cloud-based services.
[0003] 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).
[0004] 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'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's contract
expires.
SUMMARY OF THE INVENTION
[0005] A system for providing a cloud-based service includes a
processor and a computer readable storage medium that stores
instructions which, when executed, cause the processor to perform
operations including: 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, and identifying at least one service
provider who provides the cloud-based service in a manner that
satisfies the requirement of the customer.
[0006] Another embodiment of a system for providing a cloud-based
service includes a conversational interface for receiving
information from a customer of the cloud-based service, the
information identifying a requirement of the customer related to a
resiliency of the service and a resiliency analysis engine for
identifying at least one service provider who provides the
cloud-based service in a manner that satisfies the requirement of
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's resiliency needs and various service providers'
abilities to provide resiliency and then match the customer with
the service providers who can potentially meet the customer'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'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'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'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'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'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'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'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'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'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's
resiliency requirements and potential service providers/service
products as part of a model of the customer'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'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'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'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 terms may
be interchangeable.
* * * * *