DE202016008047U1 - High-level language for specifying configurations of cloud-based deployments - Google Patents

Abstract

A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, causing the processors to perform operations comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class modeling a corresponding data or function component of the cloud-based implementation using a group of configurable class parameters and the respective class definition of each class representing a requested state of the data or functional components modeled by the class; Deriving a plurality of application programming interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Storing respective class definitions of a plurality of specification-language core classes, each core class corresponding to a modular component of a cloud-based environment, wherein each core class may be augmented with additional class parameters to configure the respective modular component; Storing a mapping between each of the core classes and a respective set of API calls, the respective set of API calls for configuring the modular component associated with the core class according to the class parameters of the core class; and storing a plurality of protocols for modifying the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition derived from the core class.

Description

BACKGROUND

This specification generally refers to cloud computing.

Cloud computing is a computing model designed to provide convenient on-demand network access to a shared pool of computing resources (eg, networks, servers, storage, applications, and services) that is fast, dynamic, and with minimal manual overhead and human interactions with the service providers and can be issued.

A few common cloud-based service models include software (eg, commercially available software applications) as a service (SaaS), a platform (eg, hosting environment of software applications, such as virtual machines or application frameworks). as a service (PaaS) and infrastructure (eg computing power, storage, database, networking services, etc.) as a service (IaaS). Before a cloud-based service is made available to a cloud service customer, several aspects of the service are configured according to a configuration specification so that when the service is provided, it meets the customer's needs and usage requirements.

Under protection and subject to the utility model are, according to the provisions of the utility model law, only devices as defined in the appended claims, but no method. Wherever in the description, if appropriate, reference is made to methods, these references are merely illustrative of the device or devices set forth in the appended claims.

SUMMARY

This specification describes technologies related to the use and management of cloud computing environments.

In general, another innovative aspect of the described subject matter in this specification may be performed in methods that include the following actions: Obtaining a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and an instantiation of respective class definitions of one or more Classes, each class models a respective cloud-based deployment data or functional component using a set of configurable class parameters, and the respective class definition of each class represents a requested state of the modeled data or functional component by the class; Deriving a plurality of application program interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; and causing the plurality of API calls to be executed to configure the cloud-based deployment.

These and other embodiments may each include one or more of the following additional features. The one or more classes contain at least one existing base class and at least one custom class extending from the existing base class, wherein the customized class inherits respective class parameters from the existing base class, and the custom class changes a value of at least one of the class parameters has been inherited from the existing base class, or it contains at least one new class parameter that does not exist in the existing base class. The modeled data or functional component through each class is one of a virtual device supporting a cloud-based environment, a service used in the cloud-based environment, a running software role by an installed application in the cloud-based environment, a data packet containing data to be used during deployment or operation of the cloud-based environment, or a combination of one or more of them. The specification language supports a dependency between class definitions, and a definition dependency between a first class and a second class represents a deployment dependency between respective components modeled by the first and second classes. The specification language supports connectivity between class definitions, and a value map that associates an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first and second classes. Identifying, based on the respective class definitions of the one or more classes, a plurality of data and functional components modeled by the one or more classes, and one or more dependency and connectivity relationships existing between the plurality of data or functional components; Deriving a block diagram of a cloud-based environment based on the identified plurality of Data and functional components and the identified dependency and connectivity relationships; and presenting trigger events for dynamically reconfiguring the cloud-based environment in the block diagram. Identifying a plurality of cloud-based deployments, each performed according to a respective configuration specification written in the specification language; Identify at least one base class whose class definition is used in multiple of the plurality of cloud-based deployments; Monitoring a respective performance of each of the multiple ones on the plurality of cloud-based deployments; and calculating a quality measure of the at least one base class based on the aggregate performance of the multiple of the plurality of cloud-based deployments. Storing respective class definitions of a plurality of specification-language core classes, each core class of a modular component corresponding to a cloud-based environment, each core class being expandable with additional class parameters to configure the respective modular component; Storing a mapping between each of the core classes and a respective set of API calls, the respective set of API calls for configuring the modular component in conjunction with the core class according to the class parameter of the core class; and storing a plurality of protocols for changing the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition derived from the core class. Deriving the plurality of API calls for configuring the cloud-based deployment further comprises: deriving the plurality of API calls based on the respective groups of API calls associated with one or more of the plurality of core classes, one or more of the classes derived from the configuration specification, and based on the plurality of protocols for changing the respective groups of API calls. The plurality of protocols further include rules for specifying an order of the groups of API calls according to dependency and connectivity ratios specified in class definitions written according to the specification language.

In general, another innovative aspect of the described subject matter in this specification may be embodied in methods including the following actions: obtaining a respective definition template from each of a plurality of definition providers, the respective definition template including one or more class definitions written in a specification language and each class definition is modeled and extendable a data or function component of a cloud-based deployment using a set of configurable class parameters, at least one new class definition by a modification to one or more of the group of configurable class parameters, or an addition of one or more new ones To create class parameters; and providing a user interface representing the obtained class definitions of the plurality of definition providers for reviewing and selecting a plurality of definition users.

These and other embodiments may each include one or more of the following additional features. Obtaining a plurality of different configuration specifications written in the specification language, the plurality of different configuration specifications each for configuring a different cloud-based provision, and including a different class definition extending from an equal one of the obtained class definitions of the plurality of definition providers; and configuring each of the different cloud-based deployments based on at least the same of the obtained class definitions and the different class definition that extends therefrom in the different configuration specification of the different cloud-based deployment. For each of the obtained class definitions: monitoring use of the class definition in a plurality of configuration specifications that have been used to configure a plurality of cloud-based deployments; and recording, for each use of the class definition in the plurality of configuration specifications, to credit a definition provider of the class definition and debiting a definition user in connection with the usage. The use of the class definition includes an instantiation of the class definition in each configuration specification that was used to perform each cloud-based deployment. The use of the class definition includes an extension of the class definition to create a new class definition that is instantiated in a particular configuration specification used to perform each cloud-based deployment. Obtaining a software template from a software vendor, the software template including a software application to be deployed in a cloud-based environment, and a plurality of different configuration specifications each for providing the software application in the cloud-based environment in a different manner ; and providing the plurality of different configuration specifications for review and selection by a software user. Getting a selection one of the plurality of different configuration specifications from the software user; Providing the software application in the cloud-based environment according to the selected different configuration specification; and recording a charge to the software user and a credit to the software vendor based on a respective price associated with the selected different configuration specification.

In general, another innovative aspect of the described subject matter in this specification may be embodied in methods including the following actions: providing a plurality of class definitions for selection, each class definition defining a respective data or functional component of a cloud-based environment using a set of configurable class parameters modeling, each class definition supports instantiation and adoption of the class definition in a cloud-based deployment configuration specification; Deriving respective performance metrics in association with each of the plurality of class definitions based on aggregate performance of multiple cloud-based deployments, the multiple cloud-based deployments performed according to respective configuration specifications that require instantiation of the class definition or new class definition derived from the class definition; and using the respective performance metrics in conjunction with each of the plurality of class definitions in ordering the plurality of class definitions.

These and other embodiments may each include one or more of the following additional features. Categorizing the plurality of class definitions based on the respective data or functional components of the cloud-based environment modeled by the plurality of class definitions; and ordering the plurality of class definitions in the respective categories of the class definitions. Providing the plurality of class definitions for selection further comprises: providing the respective performance metrics with each of the plurality of class definitions for review by the user in a selection user interface. For each of the plurality of class definitions: identifying a plurality of cloud-based deployments performed in accordance with respective configuration specifications that required instantiation of the class definition or at least one new class definition derived from the class definition; Monitoring respective services from the plurality of cloud-based deployments; and connecting the respective services from the plurality of deployments with the class definition. Deriving respective performance metrics associated with each of the plurality of class definitions based on aggregate performance of multiple cloud based deployments further comprises: for each of the plurality of class definitions: identifying one or more data or functional components in the plurality of cloud based deployments according to the class definition defined or a new class definition derived from the class definition; Identifying one or more performance metrics in association with the identified one or more data or functional components; and deriving the respective performance metrics in association with the class definition by aggregating the one or more performance metrics. The performance measurements include one or more measurements of latency, reliability, scalability availability, or security. For each of the plurality of class definitions: tracking a respective count of cloud-based deployments configured at least in part according to the class definition; and using the respective counts in conjunction with the plurality of class definitions in ordering the plurality of class definitions. For each of the plurality of class definitions: tracking a respective count of detected issues in cloud-based deployments configured at least in part according to the class definition; and tracking a number of changes required to resolve the identified issues in the cloud-based deployments configured at least in part according to the class definition; and using the respective counts of the problems and the number of changes required in connection with the plurality of class definitions in ordering the plurality of class definitions. The respective numbers of required changes associated with the plurality of class definitions are used to calculate respective weights given to the respective performance measurements in association with the plurality of class definitions in ordering the plurality of class definitions.

Particular embodiments of the described subject matter in this specification may be implemented to carry out one or more of the following advantages.

A parent object-oriented specification language allows configurable components of a cloud-based deployment to be modeled by a class definition that contains a set of configurable class parameters. The object-oriented specification language supports extending an existing base class definition to create new class definitions, and supports inheriting class parameters from the existing one Base class definition by the new class definitions. An administrative user of a cloud-based service may customize a cloud-based deployment based on used class definitions when configuring one or more generic deployments, such as: By modifying class parameter values of the class definitions, varying relationships between the classes and supplementing existing class parameters with new class parameters.

The object-oriented specification language makes multiple abstraction layers possible on the different types of cloud service components that are configurable. For example, the parent object-oriented specification language supports not only class definitions that model hardware and virtual resources, but also software roles and service roles that are served by software applications and services in a cloud-based deployment. In addition, the object-oriented specification language provides a syntax for specifying a dependency and connectivity between classes. Cloud components involving multiple subcomponents and complex structures may be modeled by class definitions that refer to multiple types of base classes and specify respective relationships between the base classes.

A configuration specification can be based on existing class definitions to configure some aspects of cloud provisioning at a high level of abstraction, while other aspects are customized on a more granular level using newly derived class definitions. An administrative user of a cloud-based service is able to control the level of customization for a cloud-based deployment by choosing an appropriate set of class definitions to include and instantiate in the cloud-based deployment configuration specification.

In addition, the object-oriented specification language allows many class definitions to model common or specialized cloud service components to be created and stored. These stored class definitions can be augmented or reused in configuration specifications of future deployments by different Cloud Service customers. This reuse of class definitions in specification configurations can improve the speed and efficiency of the deployment process.

Because class definitions can be reused and shared among many cloud service customers, efforts to develop appropriate configuration specifications for the same or similar purposes need not be duplicated by cloud service customers. A marketplace for sharing reusable class definitions may be developed so that a cloud service customer may choose to buy or license the use of existing class definitions developed and provided by other cloud service customers for a fee. In addition, software applications may be provided with different types of configuration specifications (i.e., "config-wrapped" software solutions) that are appropriate for different usage requirements and organizational infrastructures of cloud customers.

When a configuration specification of a cloud-based deployment is written in the object-oriented specification language, the cloud service provider can parse the configuration specification to identify the class definitions involved in configuring each data or function component of the cloud-based deployment. Further, if the deployment is performed according to the configuration specification, the cloud service provider may also identify the underlying software or virtual resources associated with each of the data or functional components of the deployment. Therefore, the object-oriented specification language allows the cloud service provider to monitor the performance of the cloud-based deployment data and function components, and to connect the performance to the class definitions used to configure each of the data and function components. Thus, the cloud service provider may provide guidance to the cloud service customer as to which portions of the configuration specification need to be changed to improve the performance of the deployment.

In some implementations, the cloud service provider may generate a block diagram for cloud-based deployment based on the configuration specification. The performance of the various components of the deployment can be visually illustrated in the block diagram. Several reconfiguration triggers specified in the configuration specification can also be shown in the block diagram. This visual representation allows a cloud-based deployment administrator to quickly and appropriately set the configuration parameters of the deployment.

The object-oriented specification language allows class definitions to be reused in multiple configuration specifications and potentially by multiple cloud service customers can be. The cloud service provider may track the performance of multiple cloud-based deployments configured using configuration specifications involving reused class definitions. For each reused class definition, the cloud service provider can rate the quality of the class definition based on the aggregate performance of the multiple deployments configured using the class definition. In a marketplace for sharing reusable class definitions, ordering or quality scores of the class definitions may be provided based on the quality of the class definitions. These ordering or quality scores help cloud service customers better choose the class definitions for reuse in their own cloud-based deployments. Ranking or quality scores can also help reusable class definitions providers improve their class definitions.

The details of one or more embodiments of the described subject matter in this specification are set forth in the accompanying drawings and the description below. Other features, aspects and advantages of the subject matter will become apparent from the description, drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

1 illustrates an example cloud computing environment.

2A shows an example of a conventional configuration specification for a cloud-based deployment.

2 B FIG. 12 illustrates a resulting topology of the cloud-based deployment that, according to the configuration specification shown in FIG 2A is configured.

3A FIG. 10 is an exemplary written configuration specification in an exemplary object-oriented specification language.

3B is an exemplary module containing reusable class definitions written in the example object-oriented specification language.

3C FIG. 10 is an example configuration specification illustrating the reusable class definitions shown in FIG 3B used.

4 Figure 10 is a block diagram of an example cloud service manager of an example cloud service provider.

5 FIG. 10 is a block diagram illustrating a topology of an exemplary cloud-based deployment that is maintained in accordance with the configuration specification shown in FIG 3C is configured.

6 FIG. 10 is a flowchart of an example process for processing a written configuration specification in an object-oriented specification language.

7 FIG. 10 is a flowchart of an example process for deriving a block diagram showing a cloud-based deployment topology based on the cloud-based deployment configuration specification.

8th Figure 10 is a flow diagram of an example process for monitoring cloud-based deployment performance and connecting the performance to class definitions used in configuring the cloud-based deployments.

9 FIG. 10 is a flow chart of an example process for assessing the quality of a reused class definition based on aggregate performance of multiple cloud-based deployments that have been configured based at least in part on the reused class definition.

10 Figure 10 is a flow chart of an example process for deriving API calls to configure a cloud-based deployment based on class definitions used in a configuration specification.

11 FIG. 10 is a flow chart of an example process for providing a reusable class definition sharing platform.

12 FIG. 10 is a flowchart of an example process for configuring multiple different cloud-based deployments based on different configuration specifications, all of which use at least one common reusable class definition.

13 FIG. 10 is a flowchart of an example process for loading definition users and credit to definition providers based on use of the reusable class definitions provided by the definition providers.

14 FIG. 10 is a flowchart of an example process for providing a platform for selling "configuration wrapped" software solutions.

15 FIG. 10 is a flow chart of an example process for loading software users and crediting software providers based on the selection of configuration-wrapped software solutions by software users.

16 FIG. 10 is a flowchart of an example process for using aggregated performance metrics from multiple cloud-based deployments in ordering reusable class definitions used in configuring the multiple cloud-based deployments.

17 FIG. 10 is a flow chart of an example process for categorizing reusable class definitions and ordering the reusable class definitions within their respective categories.

18 Figure 10 is a flow chart of an example process for connecting multiple cloud-based deployments to a class definition used to configure the multiple cloud-based deployments.

19 FIG. 10 is a flow chart of an example process for deriving performance measurements associated with a reused class definition based on aggregate performance of multiple deployments.

20 FIG. 10 is a flow chart of an example process for using multiple factors in ordering reusable class definitions.

Similar reference numbers and labels in the various drawings indicate similar elements.

DETAILED DESCRIPTION

In a cloud computing environment, cloud service customers (e.g., end users or enterprises) gain access to software, platform, and / or infrastructure services over one or more networks (eg, the Internet). The cloud service customers are able to scale up and down the service level (eg, in terms of service type, quality and quantity) as needed, e.g. By configuring user interfaces provided by the cloud service providers and / or by program-defined configuration specifications stored at the cloud service providers. Accordingly, cloud service providers pool resources and serve their customers through a multi-tenant model where physical and virtual resources are allocated and reassigned, configured, and reconfigured according to customer needs. The locations of the physical resources underlying the cloud infrastructure are not exposed to the cloud service customers and can change dynamically.

1 is a block diagram illustrating an exemplary cloud computing environment 100 illustrated. In the exemplary cloud computing environment 100 communicate to cloud service customers (eg 102 . 102b . 102c ) with a cloud service provider 104 using a customer device over one or more networks 106 , The cloud service customers include end users of software applications provided by the cloud service provider 104 be provided, such. For example, in a model "Software as a Service" (SaaS). The cloud service customer may also include enterprise customers who provide platform and / or infrastructure services from the cloud service provider 104 obtained, such. In the "Platform as a Service" (PaaS) and / or "Infrastructure as a Service" (IaaS) models. The software application services, platform services, and infrastructure services provided by the cloud service provider 104 be provided internally or by third party service developers 108 and the cloud service customer through the cloud service provider 104 provided. A cloud service customer may have more than one type of service from the cloud service provider 104 use.

In one example, the cloud service provider 104 conceptually structured in multiple layers. The lowest layer is the firmware and hardware layer 110 , on the other layers of the cloud service provider 104 are constructed. The firmware and hardware layer 110 contains generically contributing nodes (eg, data centers, computers, and storage devices) geographically distributed over the Internet and the physical resources to implement the upper layers of the cloud service provider 104 provide.

About the firmware and hardware layer 110 is the software kernel layer 112 , The software kernel layer 112 contains the operating system 111 and / or the virtual machine manager 113 who hosts the cloud infrastructure services provided by the cloud service provider 104 to be provided. The software kernel layer 112 controls and communicates with the underlying firmware and hardware layer 110 via one or more hardware / firmware application programming interfaces (APIs). The APIs at the hardware / firmware level can vendor-specific and implemented to support communication protocols based on Hypertext Transfer Protocol (HTTP) and HTTP Secure (HTTPS). Examples of vendor-specific APIs include Amazon Web Services APIs, Google App Engine APIs, and Microsoft SQL Azure APIs.

The provided infrastructure services from the cloud service provider 104 contain virtualized resources, such as Virtual machines, virtual storage (for example, virtual disks), virtual networking applications (such as firewalls), and so on. The infrastructure services also include virtualized services such as virtual machines. Database services, networking services, file system services, web hosting services, load balancing services, MapReduce services, message queuing services, map services, e-mail services, etc. Each of these infrastructure services may be provided by a cloud service Customers used and in an infrastructure service layer 114 above the software kernel layer 112 to be provided.

The scale and multiple aspects (eg, data, connectivity, and dependency relationships within and between service components) of an infrastructure service deployment are configurable by an administrator user of the cloud service customer. In one example, the administrator user sends a configuration specification to the cloud service provider 104 via a frontend cut surface 120 of the cloud service provider 104 , The cloud service provider 104 translates the configuration specification into instructions (such as API calls) to the infrastructure service layer 114 and the kernel layer 112 according to the APIs of the infrastructure services involved and the APIs the underlying software kernel layer 112 , These instructions are executed to configure the requested infrastructure services in the configuration specification of the deployment. For example, a configuration specification may be translated into infrastructure and kernel API calls that create, re-create, move, or delete components (e.g., virtual machines and services) and attributes (e.g., memory and CPU mappings). Network settings, size and volume of disks) to the components.

In addition to the infrastructure services, the exemplary cloud service provider provides 104 also platform services ready, such as For example, an environment (such as Linux, Solaris, Microsoft Windows, and so on) that runs virtual machines or a framework (such as .NET, Java, Oracle Database, etc.) to develop and launch a particular type of software. applications. The platform services are in a platform service layer 116 over the infrastructure service layer 114 implements and can use one or more infrastructure services that are configured in a particular way. A configuration of platform services may be done by program code written in accordance with the APIs of the platform services and optionally according to the APIs of the infrastructure services used in activating the platform services.

In this example, the cloud service provider represents 104 also software application services in an application service layer 118 ready. A software application (eg, a commercially available software application) may be installed on one or more virtual machines or in an application framework in the platform service layer 116 to be provided. The software application may also work with one or more infrastructure service components (eg, firewalls, databases, web servers, etc.) in the infrastructure layer 114 communicate. Installation and configuration of the software application in the application service layer 118 can be done through APIs of the software itself and the APIs of the underlying platform and infrastructure service components.

To manage the provisioning and operation of the deployed cloud-based services to the cloud service customer (e.g. 102 . 102b . 102c ) contains the example cloud service provider 104 a cloud service manager 122 , The exemplary cloud service manager 122 communicates with the frontend interface 120 to receive service requests from the cloud service customer. The exemplary cloud service manager 122 is also responsible for managing the cloud resources and services, including the registration, provision, coordination, monitoring, scheduling, etc. of the Services. As described in this specification, the exemplary cloud service manager includes 122 also tools and libraries for translating user requests (eg, as expressed in one or more configuration specifications and service level agreements (SLAs)) in the various service layers (eg, the layers 114 . 116 and 118 ) into physical resource requests (eg, as expressed in one or more API calls at kernel and hardware / firmware levels).

Although the exemplary cloud service provider 104 provides all three types of cloud-based services, in some implementations fewer or more service types may be provided. In some implementations, the cloud service provider may 104 outsource some of the cloud services or parts of a service to other cloud service providers. The cloud service manager 120 can implement API calls to these other cloud service providers to support some of its services to the cloud service customer. In addition are the conceptual layers of the cloud service provider 104 , in the 1 to be shown, purely illustrative. Another conceptual structure of a cloud service provider may be provided, e.g. Depending on the types of services actually offered by the cloud service provider.

In this example, cloud service customers can use cloud-based services that reside in each of the service layers 114 . 116 and 118 Tobe offered. Depending on the type of service a cloud service customer has used, the cloud service customer is granted different levels of control when configuring the services. For example, when using a software application service, an administrator user of the cloud service customer gains control over how the software application is configured but controls over the underlying platform and infrastructure services that support the software application remain at the cloud service provider 104 , When a platform service is used, an administrative user of the cloud service customer gains control over how the platform and / or application frameworks are configured, but takes control of the infrastructure services that make up the platform and / or application frameworks support, stays with the cloud service provider 104 , Similarly, when infrastructure services are used, an administrative user of the cloud service customer gains control over the specific infrastructure services used, but not on the underlying kernel layer 112 and firmware and hardware layer 110 ,

In the cloud computing environment 100 the cloud service customers are using data processing devices such. For example, personal computers, smartphones, and tablet computers rely on the cloud-based services. Depending on the type of service used, different user interfaces or programming interfaces can be used to connect with the cloud service provider 104 to communicate.

For example, when using a software application service, a user can access and use the software application through a web browser. When platform or infrastructure services are used, a user of the service (eg, an administrator user of a cloud service customer) may access a configuration user interface that includes administrative functions to control and configure the services. The administrative functions contain z. For example, turning on and off virtual machines, managing cloud storage, installing and deploying software to virtual machines, or setting up web servers, etc. Additionally, a cloud service provider may 104 optionally, allow an administrator user of a cloud service customer to write a program code according to multiple provider, platform, framework, and / or service dependent application program interfaces (APIs) to control and configure several aspects of the services that the cloud service customer receives. In some implementations, when an open standard is used for a cloud computing environment, the provider, platform, framework, and / or service dependent APIs can be used to also control and configure the services.

When configuring a cloud-based service for deployment, a service user or service developer presents one or more configuration files to the cloud service provider 104 ready. The configuration files determine the desired output status of the service expressed in the form of several configuration parameters. Normally, the configuration file is structured according to the rules and syntax written by the cloud service provider 104 be provided or recognized, so that the configuration file by the cloud service provider 104 correctly parsed and interpreted.

2A is an example of a conventional configuration specification 200 to deploy a simple web application in a cloud computing environment. The example configuration specification 200 is written in Extensible Markup Language (XML), which is a commonly used language for specifying configurations for cloud-based deployments. The example configuration specification 200 is provided to a cloud service provider in a text file. The cloud service provider uses tools (eg, a parser or API translator) that parse and specify the configuration file according to the markup (eg, the MXL tags, element and attributes, etc.) in the configuration file Converts requests in the configuration file into one or more sets of API calls. After the appropriate sets of API calls have been determined, the cloud service provider executes the API calls to perform the deployment according to the specified requirements in the configuration file.

2 B illustrates the resulting topology 208 the web application service after it has been configured according to the configuration specification 200 was provided. First, according to the code block 202 a single Grid Service Manager (GSM) 210 on a single virtual GSM machine 212 provided. After the GSM 210 on the GSM machine 212 two Grid Service Containers (GSCs) 214a and 214b each GSC on a given GSC machine ( 216a or 216b ), as indicated by the code block 204 is specified. Then the GSM installs according to the code block 202 a copy of the web application software (for example, application copy 218a or 218b ) in each of the two GSCs 214a and 214b , According to the code block 206 becomes a load balancing service 220 on a load-balancing machine 222 started and used the traffic (for example, HTTP requests from client browsers 224 ) to the two GSC machines 216a and 216b to set up and prepared responses through the web applications running on the GSC machines 216a and 216b run, to report back.

As in the 2A and 2 B As shown, the exemplary conventional configuration specification is based 200 on nested markup constructs (for example, code block 202 . 204 and 206 ) to describe the components of a provision and relationships among the components. The user of the configuration specification 200 writes with the details in every markup construct that is in the configuration specification 200 and understand the meaning of the markup construct for the cloud service provider API translator. For a large and complex deployment, the configuration file can become very long and complex with many layers of markup and duplicated instructions. In addition, the possibility of code reuse decreases with increasing length and complexity of a configuration specification, because adapting the configuration specification to another deployment would require a great deal of change, and debugging the custom configuration file would be more difficult.

As disclosed in this specification, instead of providing a written configuration specification in a markup language or through a graphical user interface, a cloud service customer or service developer may provide a written configuration specification in a higher-level object-oriented specification language. The parent object-oriented specification language allows the specification of components (eg, infrastructures, storage devices, services, software package to be installed, and "software roles" played by installed software applications) of a cloud-based deployment as instances of one or more reusable and modifiable classes, each class modeling a component of the deployment using a set of configurable class parameters. The value of each class parameter may be specified, reused, or changed for particular deployments using the syntax and functions provided by the object-oriented specification language. The instance of each reusable and modifiable class explains the desired state of the component modeled by the class.

As described in this specification, the adoption of class definitions is supported by the parent object-oriented specification language. New class definitions may be provided based on instructions relating or changing one or more existing class definitions using the parent specification language. Statements that relate to different classes capture the relationships between multiple aspects (eg, data or functional components) of a deployment. Examples of such relationships include the dependencies between software installations and service activations in a deployment, the connectivity between multiple software roles in a deployment, and the connectivity between a software role and a service or virtual device in a deployment. New class definitions can also be created by extending an existing class definition with the addition of new class parameters and / or methods. A user can customize a deployment by specifying a new class derived from one or more existing base classes and instantiating the new class.

According to this specification, a cloud service provider is able to compile written configuration specification in the parent object-oriented specification language into a set of API calls based on the specified requirements through the included class definitions in the configuration specification. Including a class definition in a configuration specification refers to a request in a configuration specification to instantiate the class definition or to instantiate a new class definition derived from the class definition.

In some implementations, different service layers of the cloud service provider and different services within the same layer have different APIs. To compile the written configuration specification in the object-oriented specification language, the cloud service provider stores a set of rules and protocols for translating a set of the most basic class definitions (or core class definitions) of the specification language into a respective set of API calls. The group of API calls from each core class definition corresponds to the model component type API through the core class definition. The compiler is then able to change the set of rules and Use protocols to translate all derived class definitions from the core class definitions into an appropriate combination of API calls to configure all components of a specific deployment. In some implementations, the API calls are sent to and executed on one or more servers of the cloud service provider. Alternatively, some of the API calls may be routed to an intermediary component of the cloud service provider or a third service provider, where the API calls are further processed into child API calls and performed by the subcomponents of the intermediate component or the third service provider.

In some implementations, the parent object-oriented specification language also includes a syntax for specifying triggers for scaling or dynamically reconfiguring multiple aspects of the deployment. For example, a class definition that models a virtual machine can contain one or more scaling policy class parameters, so that the compiler can derive API calls to estimate the number of virtual machines deployed based on multiple performance metrics that are monitored by the cloud service manager ( For example, the cloud service manager shown 122 in 1 ) dynamically adjust.

The following examples (shown in the 3A - 3C ) illustrate the syntax and various properties of an exemplary object-oriented specification language, and how to specify a cloud-based deployment according to the example object-oriented specification language and based on existing and newly-derived class definitions.

The first example shows an example configuration specification 300 , which is written in an exemplary object-oriented specification language, in 3A shown. The provision made according to this configuration specification 300 Used to boot a virtual machine with an installed web server (for example, an Apache web server) that delivers the existing files in a data packet.

This example assumes that there are a number of base class definitions that the compiler can parse and translate into API calls. The existing base class definitions contain a set of core class definitions provided by the compiler, and possibly other class definitions that extend from one or more of the core class definitions, either directly or through one or more intermediate class definitions.

In some implementations, the existing base class definitions are grouped in modules (eg, the shown modules "utils", "std" in 3A ), and contained classes are named in a configuration specification by a module name followed by a class name (for example, std.Parameters, utils.ConfiguratorLAMP, std.DataPackage, std.Role, utils.PublicTCPFirewall "," Utils.BaseDeployment "as stated in the specification 300 will be shown). Each of the base class definitions specifies an initial configuration state of a corresponding component of a cloud-based deployment subject to the changes and component relationships set forth in the configuration specification 300 are fixed.

As in 3A shown, contains the configuration specification 300 new class definitions that extend from the existing base class definitions. For example, a new class "Params" extends from the base class "std.Parameters", a new class "SimpleHostingPackage" extends from the base class "std.DataPackage", a new class "SimpleHostingVM" extends from the base class "utils.Configurator "LAMP", a new class "SimpleHostingRole" extends from the base class "std.Role", a class "SimpleHostingFirewall" extends from the base class "utils.PublicTCPFirewell", and a class "SimpleHostingDeployment" extends from the base class "utils "BaseDeployment" as shown by the new class definitions 302 . 304 . 306 . 308 . 310 , respectively. 312 , The configuration specification 300 triggers the deployment of a simple hosting application by creating an instance of the SimpleHostingDeployment class (for example, through the statement as shown) 314 ), which in turn creates instances of other classes from which the class "SimpleHostingDeployment" is derived.

In this example, the class definition fits 312 "SimpleHostingDeployment" defines the definition of the base class "utils.BaseDeployment" by changing two class parameters, a parameter "roles" and a parameter "Firewall". The "roles" parameter specifies the respective software roles that are to play one or more installed software packages in the deployment. The Firewall parameter specifies that a firewall service should be included as part of the deployment. In this case, the class definition specifies 312 that a single software role should be included, which is represented by an instance of the class "SimpleHostingRole". The class definition 312 further specifies that the firewall service to be included in this deployment is represented by an instance of the SimpleHostingFirewall class. According to the properties of the object-oriented specification language, the class "SimpleHostingDeployment" takes over others Class parameters defined in the base class "utils.BaseDeployment" without further modification. These other class parameters describe other aspects of deployment that do not need further customization for this simple hosting deployment.

According to the class definition 312 Instancing the SimpleHostingDeployment class also requires instantiation of the SimpleHostingRole and SimpleHostingFirewall classes. As in 3A shown, the class definition extends 308 "SimpleHostingRole" of the base class "std.Role". Both classes are based on a "software role" model that categorizes a software installation according to the role that the software installation plays in a cloud-based deployment. For example, a software package may be installed to play a role of a web host, a front end, a backend, a communication interface. Depending on the specific role played by a software installation, various parameters may be used to configure the software installation. Each configurable parameter for the software role may have a corresponding class parameter or function in the class definition created based on the "software role" model.

In one example, in addition to an identifier or name of the role that the software installation plays in a deployment, a model "software role" may include model parameters for configuring several aspects of the software installation, including the virtual machines on which the software resides installation, the location of the software binary data, instructions on which installer to use to install the software, and so on. If the software installation requires that other services or software installations be run first, this dependency is optional also included in the model "software role". An example of dependency relationships are "start after" or "stop before". Other dependency types (for example, installing on the same virtual machine, etc.) can also be supported.

In this example in 3A specifies the class definition 308 for the class "SimpleHostingRole" that the role of the software installation is in the deployment to serve as a "webhost". How to deploy the software "webhost" is announced to the compiler by the class definition of the class "simplehosting.webhost". In this example, the simplehosting.webhost class definition contains the configurations of a simple Apache Web server that is already written and advertised to the compiler. When the SimpieHostingRole class is instantiated, the simplehosting.webhost class is also instantiated.

The class definition 308 for the class "SimpleHostingRole" further declares that the data package necessary to run this web host is represented by an instance of the class "SimpleHostingPackage", and that the web host should be installed on the virtual machines that are protected by instances of a class " SimpleHostingVM "is displayed.

In this example, each of "roleName", "moduleName", "dataPackages" and "vms" are parameters of class "std.Role" and are in the class definition 308 Customized "SimpleHostingRole". Other class parameters of the std.Role class are inherited by the SimpleHostingRole class without modification. The class definition 308 The SimpleHostingRole class also defines a few new parameters, such as: For example, the serving_domain and document_root parameters, whose values are either indirectly indexed by another parameter name (for example, serving_domain of the class) 302 "Params") or by a direct value input (eg "/ var / www / static"). In this example, only one software role is defined, ie no dependency between software roles for the software role (eg "SimpleHostingRole") with respect to installation or execution is specified.

The class definition is based on the firewall component of the deployment 310 the class "SimpleHostingFirewall" on the existing class definition "utils.PublicTCPFirewall". In this example, the utilis.PublicTCPFirewall class defines a public firewall with a specified Transmission Control Protocol (TCP) protocol. The only parameters of the PublicTCPFirewall class for this deployment are the target and ports parameters. In the class definition 310 the firewall destination is represented by an instance of the SimpleHostingRole class, while the firewall's port is set to port 80. Other parameters (such as the source and protocol parameters) that are required to configure the firewall are specified in the base class definition of PublicTCPFirewall and are inherited by the SimpleHostingFirewall class without modification. In this example, connectivity between the firewall component and the role of simple hosting software (e.g., represented by an instance of the SimpleHostingRole class) is specified by the value assignment to the target parameter.

In this example, the class definitions of the SimpleHostingFirewall and utils.PublicTCPFirewall classes are both based on a firewall service model. Unlike a "software role" model, a service model does not have to Parameters for the underlying virtual machines, disks or software packages included. Instead, these aspects are controlled by the cloud service provider and are not subject to configuration by the users of the service. As with a "software role" model, a service model optionally also includes parameters that specify dependencies between services and between service and software roles. In this example, the firewall component is connected to the web server component, but no firewall service dependencies are specified for this simple hosting deployment. As set forth above and shown in FIG 3A requires the class definition 308 the class "SimpleHostingRole" an instantiation of the class "SimpleHostingPackage" and the class "SimpleHostingVM". The class definition 304 the SimpleHostingPackage class specifies the source of the data (for example, data in the current directory) that should be copied to the SimpleHostingRole virtual machine hosting. The class definition 304 further specifies a destination directory (eg, "/ var / www / static") of the copied data on the virtual machine. If the deployment is in accordance with the configuration specification 300 is done, the data packet "data" is copied from the directory where the configuration file resides to the target directory "/ var / www / static" on the virtual machine, according to the class definition 306 "SimpleHostingVM" is provided.

As in 3A shown, the class definition extends 306 "SimpleHostingVM" of the class definition "utils.ConfiguratorLAMP". Both classes are based on a virtual machine model and specify how a virtual machine can be configured. In this example, the utils.ConfiguratorLAMP class configures a custom virtual machine that already has an Apache Web server installed. Therefore, by extending the class "utils.ConfiguratorLAMP" rather than a standard class of a virtual machine class, a user can simplify and speed up the configuration process. The class definition 306 SimpleHostingVM also specifies the number of virtual machines to deploy in this deployment and the external IP addresses to bind to the virtual machines through the newly added replicas and staticIP class parameters. Other parameters that are commonly used to configure a virtual machine or virtual machines to support a software role include, for example, configuration parameters for the CPU and memory requirements of the virtual machine (s), storage disks that are attached to the virtual machine (n ), read-only memory sources bound to the virtual machine (s), IP addresses, network interfaces of the virtual machine (s), virtual machine datacenter location (s), etc. Each of these model parameters for The virtual machine is optionally included as a class parameter in a class definition of a virtual machine or other class that extends from the base class definition of a virtual machine.

Optionally, a special class "Params" is included in the configuration specification of a deployment, such as: The one shown in the example configuration specification 300 , In this class definition, parameter values can be provided and used to assign values to other class definitions contained in the same configuration file. For example, the values of the parameters "replica_count", "serving_domain" and "ip_array" will be in the class definitions 306 and 308 by referring to the respective parameter names.

As in the example configuration specification 300 As shown, it is possible to create class definitions for various components of a cloud-based deployment based on different component models. A high-level object-oriented specification language can be developed based on models of multiple types of infrastructures, storage, services, and software roles that typically exist in a cloud-based computing environment. Each model describes a corresponding infrastructure component, memory, service, or software role using a number of model parameters. Core class definitions that represent generic initial configuration states of some of the most common and basic components of the cloud-based environment may be created based on these component models. As more complex components can be built from combinations of multiple base components, class definitions representing the initial configuration states of more complex components can be created from multiple core class definitions and / or other class definitions derived from the core class definitions.

A superordinate object-oriented specification language compiler is provided to parse the created class definitions based on these component models, extract the expressed configuration requirements by the values of the class parameters, and translate the requirements into an appropriate set of API calls to configure the types of components. which is represented by these component models. In some implementations, a compiler is implemented as a software program or script that reads a configuration file and issues a set of API calls. In In some implementations, the compiler also directs API calls to appropriate components of the cloud service provider or third party vendors.

The example in 3A has illustrated class definitions that have been developed based on an example software data package model, an example virtual machine model, a model "software role" model, an example firewall service model, and an example deployment model, respectively. As an additional example, an example storage model includes model parameters for configuring aspects of a storage option of a deployment, such as a storage option. Memory size, mounting locations, etc. In some implementations, a memory model optionally includes a scaling policy for dynamically adjusting the size of the memory based on a monitored use of the memory. Additionally, in addition to a firewall service, a cloud-based environment may include many platform and infrastructure services, such as: A database service, a message queue service, a load balancing service, a map service, a map reduce service, etc. Various service models may be developed for each of these cloud-based services and class definitions for configuring the various services may be based on the various Service models are created.

As shown by the example of 3A , an object-oriented specification language allows the creation of class hierarchies that represent different levels of customization for components in multiple layers of the cloud computing environment. A written configuration specification in the object-oriented specification language reusing existing class definitions by augmenting an existing class definition or referring to an instance of an existing class definition when a value is assigned to a class parameter. Reusing existing class definitions simplifies the configuration specification for a new deployment. In addition, when reusing an existing class definition, a user only needs to know the configuration state that can be reached by the existing class definition, but not all of the literal details set forth in the class definition to accomplish this configuration state.

In addition, class definitions of highly complex components (e.g., components involving multiple services, multiple data sources, and multiple deployment levels) can be developed based on multiple existing class definitions, with or without change to the class parameter of the existing class definitions. These highly complex class definitions can be reused by a user in a new deployment without deep understanding of these complex class definitions at all levels.

By choosing the appropriate base classes to customize and change in a new configuration specification, the user also gains finer control over specific aspects of the deployment, while leaving other aspects of the deployment generic to the definitions of the base classes.

3B shows some base class definitions that are stored (for example, in a module 320 "Lamp"), and reused in configuration specifications from multiple cloud-based deployments. These base class definitions are tailor made for the various application deployments based on Linux Apache MySQL Per / Python (LAMP). Each class definition contains some commonly used class parameters for configuring a respective data or function component from a LAMP-based application deployment.

3C provides an example configuration specification 340 ready to use the base classes in the module 320 "Lamp" is used to provide Mantis debugging software in a LAMP-based application deployment. By using the class based definitions on the module 320 "Lamp" must be the configuration specification 340 Mantis application deployment does not include the details of how to configure a LAMP-based base environment, and it only needs to customize aspects specific to Mantis application deployment. The following describes how the class definitions are based on the module 320 "Lamp" can be used to create a basic LAMP provisioning structure. In the module 320 "Lamp" contains the special class 322 "Params" has some parameters that are used in multiple class definitions, such as: For example, a flag "single_node" indicating whether the Apache software and the MySQL software need to be installed on the same virtual machine has a "frontend_ip" parameter for specifying the IP addresses bound to the LAMP front-end component a parameter "serving domain" for specifying the domain name of the Apache web site, a parameter "doc_root" for setting the main document directory of the Apache server, a parameter "mysqldatafolder" for setting the database folder with respect to the mounting location of the persistent Hard disk, a parameter "mysql_pdname" for specifying the name of the persistent disk, a parameter "mysql_pd_mount_point" for specifying the mounting location of the persistent disk, a parameter "pd_size_gb" for specifying the size of the persistent disk in GB. Optionally, the parameter values in the Params special class may be changed by a command-line tool provided by the cloud service provider to make it easier for the user to set up deployments based on the module "lamp".

A LAMP-based application deployment typically includes the following components: a front-end (that is, the software role of a front-end software application), virtual machines that support the front-end software application (for example, an Apache Web server application) a database (that is, the software role of a database software application), virtual machines on which the database software application (for example, a MySQL software application) is installed, a persistent disk for storage the database and a firewall. Each of the above components is modeled by a respective set of class parameters that are configurable for a specific LAMP-based application deployment.

As in 3B shown, the class definition "FrontendVM" extends 324 from an existing "utils.ConfiguratorLAMP" class definition that configures an image of a virtual machine that already has Apache web server software preinstalled. In this case, the MySQL database software must be installed on the same virtual machine as the Apache software, using the "single_node" flag in the class definition 322 "Params" is specified. Therefore, the class definition extends 326 "DatabaseVM" also from the class definition "utils.ConfiguratorLAMP".

In the module 320 "Lamp" models the class definition 328 "MysqlPD" is the persistent disk on which the database is to be stored. The class definition 328 MysqlPD contains class parameters, such as For example, specify the name of the persistent disk, the size of the persistent disk, and the location of the permanent disk. Other parameters that specify how the persistent disk must be configured are inherited from an existing class definition "std.PersistentDiskSpec" without modification. The class definition 330 FrontendRole models the frontend component of the LAMP-based environment. The class definition 330 "FrontendRole" extends from a standard software role modeled by an existing base class definition "std.Role". The "FrontendRole" also refers to a placeholder class "lampfront" and a placeholder module "lamp" as temporary values assigned to the class parameters "roleName" and "moduleName". These temporary values are replaced by the names of the actual module and class that define the LAMP front-end software application to be deployed. As it is in 3C is shown, the class definition that the front-end software configures (for example, the Mantis debugging software) is the mantis_frontend class in the mantis module. The class definition 330 also specifies that the virtual machine on which the LAMP front-end role must be installed is through an instance of the class 324 "FrontVM" is displayed.

The class definition 332 DatabaseRole models the database component of the LAMP-based environment. The "DatabaseRole" class also refers to a placeholder class in a placeholder module (for example, "lamp" and "lamp_backend") for configuring the backend software. The names of the placeholder class and the placeholder module are replaced by the actual names of the class and module that configure the backend database software. The class definition 332 "DatabaseRole" also specifies that the persistent disk that stores the database is specified by an instance of the class definition 328 "MysqlPD" is displayed. In addition, a parameter "vms" is defined to indicate that the virtual machine for installing the backend database software of the LAMP environment must be represented by an instance of the class "FrontendVM" when the flag "single_node" is set to TRUE Otherwise, the virtual machine must be represented by an instance of the "DatabaseVM" class.

Last will be in the module 320 "Lamp" the firewall component of the LAMP based environment through the class definition 334 Modeled "HttpFirewall". The HttpFirewall class definition extends from the existing class definition utils.PublicTCPFirewall so that the protocol, source, and destination parameters of the util.PublicTCPFirewall class are inherited by the HttpFirewall class. The class definition "HTTPFirewall" changes the parameter "port" of the "utils.PublicTCPFirewall" from "any" to "80". Each defined class definition in the module 320 "Lamp", shown in 2 B is extensible, modifiable, and / or usable as is for application-specific provisioning and / or creating new class definitions in other modules. The configuration specification shown 340 in 3C contains and is based on the class definitions in the module 320 "Lamp", shown in 3B , An instruction 342 at the beginning of the configuration specification 340 Refers to a file containing the class definitions of the module 320 "Lamp" to tell the compiler where the base class definitions are that are in the configuration specification 340 be used.

The configuration specification 340 This is to configure an application deployment that starts virtual machines in a LAMP tree and installs the Mantis debugging software on the virtual machines. Mantis is a web-based bug-tracking system written in the PHP script language that works with a MySQL database and a web server.

As specified in the class definition 354 Mantis Deployment calls for the deployment of two software roles and a firewall to install. In this case, the two software roles are named according to the class definition 348 "MantisFrontend" and the class definition 350 "MantisDatabaseRole" created while the firewall according to the class definition 352 "MantisFirewall" is created. If the configuration specification 340 compile, does the instruction 356 an instance of the MantisDeployment class and causes the other classes to which the MantisDeployment class depends to also be instantiated.

In this example, the class definition extends 348 "MantisFrontend" from the class definition 330 "Lamp.FrontendRole", which is in 2 B is shown. The class parameters that are modified for the Mantis software installation include "roleName", "moduleName" of the software configuration specification, "dataPackages" from which the Mantis software binaries can be copied, and the database host associated with the Mantis application deployment shall be. The configuration parameters for the Mantis frontend virtual machine aspect are taken from the class definition 332 "Lamp.FrontendRole" without changes. In other words, the user who accepts the configuration specification accepts 340 writes the default configuration of the virtual machine that is in the module 320 "Lamp" is specified, and does not need to adjust the Mantis application delivery to this level of detail.

Similarly, the class definition extends 350 "MantisDatabaseRole" from the class definition 332 "Lamp.DatabaseRole", which is in 3B is shown. The class parameters that are modified for the Mantis software installation include "roleName" and "moduleName" of the configuration specification for the backend database role. In addition, the database role frontend host is set as an instance of the MantisFrontendRole class. The configurations for the virtual machine aspect and the persistent disk aspect of the database backend role are taken from the class definition 332 "Lamp.DatabaseRole" inherited without change. In addition, the class definition inherits 352 MantisFirewall takes the parameters from lamp.HTTpFirewall and only changes the value for the target parameter to an instance of the MantisFrontendRole class. Other parameters, such as. For example, the "port" and "protocol" parameters of the "MantisFirewall" class are inherited by the base class "lamp.HTTPFirewall" contained in the module 320 "Lamp" is defined.

Other parameters and values specific to the Mantis implementation are in the specific class definition 344 "Params" is specified and the data package from which the Mantis software is copied is in the class definition 346 "MantisPackage" specified. specified.

In the example above, the configuration specification for Mantis software deployment is derived from the base class definitions (for example, class definitions in the module 320 "Lamp") created for a generic LAMP-based application deployment. Configurations of many aspects of LAMP-based deployment do not need to be redefined for Mantis application deployment. The Mantis application deployment configuration specification only needs to specify new parameters or new parameter values that are specific to Mantis application deployment or require customization. Parameters already defined for other more general aspects of implementation are needed in the configuration specification 340 not to be re-specified or modified. The details of these other aspects of the implementation may remain opaque to the user.

In the example that is in 3A - 3C The examples shown are merely illustrative of the properties of an object-oriented specification language for writing configuration specifications of cloud-based implementations. In various implementations, the exact syntax of the object-oriented specification language may differ from what is shown in the examples. In addition, many types of base classes can be created to model the components that can exist in a cloud environment. Syntax for defining relationships between components modeled by the classes may vary from an object-oriented specification language to another object-oriented specification language. For a given object-oriented specification language, a compiler may be constructed to parse the class definitions contained in a configuration specification written in the object-oriented specification language according to a predetermined set of syntax rules to extract the parameters necessary for the configuration of the Different types of components are used in the cloud environment.

4 shows an example cloud service manager 222 an exemplary cloud service provider 104 , The exemplary cloud service manager 222 is for the provision of cloud-based services according to the configuration specification 104 responsible, by the administrative users (for example 102 . 102b . 102c ) of the services is provided. The cloud service manager 222 receives communications from cloud user administrative users via the frontend 120 of the cloud service provider 104 , In some implementations, the cloud service manager 222 have their own front-end components communicating directly with the cloud service customers.

After the frontend 120 the configuration specifications 104 by an administrative user of the cloud service customer (eg 102 . 102b . 102c ), hands over the frontend 120 the received configuration specifications 104 to an API translator 404 the cloud service manager 222 , The APT translator 404 has access to a library of core class definitions (for example, in a definition database 406 stored) and translation protocols (eg in a rule database 408 in terms of how to translate the core class definitions into respective sets of API calls to various components of a cloud-based environment of the cloud service provider 104 to configure.

For example, the API translator 404 include a compiler (eg, an analysis script or program) that conforms to a configuration specification 104 parses received class definitions, identifies all the base classes from which the classes in the configuration specification are derived, and extracts the unchanged base class parameters as well as the class parameters that are modified or new. In addition, the compiler also identifies all relationships (e.g., connectivity and dependencies) among the components of the cloud-based deployment from the statements in the class definitions. Based on the values of the class parameters and the stored translation logs, the API translator generates 404 a suitable set of API calls 410 to configure various aspects of cloud-based deployment.

For example, the translation protocols may include mapping between a core class definition that models a respective modular aspect of the cloud-based environment to a set of API calls used to configure that aspect of the cloud-based environment. The translation protocols may also include protocols for modifying the set of API calls (for example, to change default parameters used in the API calls) with parameter values specified for this modular aspect of the cloud-based environment into classes that are derived from the core class definition.

As a more specific example, it is assumed that a classical virtual machine class definition (for example, an "std.VM" class) is a core class definition known to the compiler. The compiler has access to a translation rule that maps the core class definition into a set of provisioning API calls made to the VM Manager in the cloud service provider's kernel layer 104 created to provide a virtual default image of the virtual machine. Deployment API calls can use a standard set of parameters, such as duplicate numbers, IP addresses, memory requirements, and so on. The API Call Modification Protocol may include protocols for changing the default parameter values according to the parameter values specified in the specification configuration and in interclass definitions derived from the class definition of the virtual machine. For example, if a class parameter of a new class definition derived from the default virtual machine image specifies the software package to be installed on the virtual machine image, the translation logs determine how the additional API calls for installing software packages on a particular one virtual machine to the group of API calls associated with the configuration of the default virtual image.

In some implementations, the protocols for translating class definitions into API calls are written as program scripts. If new class definitions to the class definition database 406 The protocol can be used to translate the new class definition and the translation rules database 408 to be added. The translation protocols may be provided, for example, by the cloud service provider 104 to be created. In some implementations, if a particular class definition occurs when parsing a received configuration specification, the API translator locates 404 an appropriate script and execute it to break the class definition into a set of API calls. When the API calls are executed, they cause the configuration defined in the class definition to be reached in the cloud-based environment.

In some implementations, the API calls become 410 provided by the API translator 404 generated to a service loader component 412 the cloud service manager 222 Posted. The service loader component 412 is for channeling the API calls 410 to different layers of the cloud service environment or components of the cloud service provider 104 where the API calls can be executed, responsible. In some implementations where multi-stage deployment is to be performed due to dependencies between different aspects of the deployment, the loader component is 412 She is also responsible for verifying the order in which the API calls to the tier and / or components are sent for execution, and is responsible for verifying that the API calls were completed in the correct order.

Because class definitions written in an object-oriented specification language, as disclosed in this specification, can be reused in multiple configuration specifications, an administrator user of a cloud service can use class definitions provided by a third party (e.g., another user, a service developer of the Cloud service provider or a third-party developer) with its own configuration specifications instead of developing these class definitions themselves. In some implementations, a marketplace may be provided for sharing / selling and selecting existing configuration defaults and reusable class definitions, for example, by the cloud service provider or a third party vendor.

In this example, the cloud service provider represents 104 provide such a platform for sharing reusable configuration specifications and class definitions. In some implementations, the frontend provides 120 The cloud service provider provides a definition submission user interface and a definition selection interface to facilitate the sharing of reusable configuration specifications and class definitions. The parties, the configuration specifications and class definitions 416 for reuse by others serve as definition suppliers 414 for the cloud service provider 104 , The potential definition users include administrative users of cloud-based services. The potential definition users optionally also include definition providers that create new reusable class definitions or class definitions for deployment based on the existing class definitions provided by other definition providers.

As in 4 shown, the cloud service manager 222 of the cloud service provider 104 or a component of the Cloud Service Manager 222 to manage the platform for sharing reusable class definitions. The definition suppliers 414 range the reusable class definitions 416 at the cloud service manager 222 via the definition submission user interface passing through the frontend 120 provided. Each class definition submission may include multiple reusable class definitions, such as in a class module. Each class definition in the submission is accompanied by descriptions of the initial configuration state that the class definition can achieve when subsequently used in a configuration specification. In some implementations, the description also includes instructions as to how the class parameters in the class definition in the configuration specifications can be subsequently adapted to the needs of particular implementations.

When a definition vendor submits a reusable class definition or module of reusable class definitions, the cloud service manager can 222 the received class definitions in a class definition database (for example, the definition database 406 ) to save. In some implementations, the frontend provides 120 Registration and authentication services for the definition suppliers 414 ready. Any class definition or class module, from a registered definition supplier 414 is received in association with the identifier of the definition supplier, so that the definition supplier 414 can be correctly credited if the class definition is subsequently used or acquired by a definition user.

In some implementations, the definition suppliers may 414 reusable class definitions 416 free or paid. The cloud service manager 222 may facilitate the sale or licensing of the reusable class definitions to the potential definition users (for example, administrative users of the cloud service customers) through the definition sharing platform. In some implementations, the definition provider provides 414 and the cloud service manager stores respective prices associated with the sale or licensing for different usage levels for the reusable class definitions provided by the definition suppliers 414 to be provided.

In some implementations, the cloud service manager 222 a definition selection user interface via the frontend 120 ready. The definition selection user interface represents the Class definitions that are available for reuse, such as when defining new class definitions. The new class definitions include those included in the configuration specification of a new deployment and, optionally, those that are submitted to the cloud service provider for reuse by others. The potential definition users (e.g., cloud service customer administrators and definition providers) can view the class definitions available for selection via the definition selection interface, along with their prices and descriptions, as well as optional ratings and quality ratings, and decide whether one or more class definitions in a configuration specification or to reuse a new class definition.

In some implementations, the definition selection user interface allows the user of the class definitions to download or copy a class definition that is available for selection. In some implementations, the user does not need to copy or download the class definition and can use the class definitions simply by identifying the module and class name in a configuration specification that is passed to the cloud service provider for deployment. The cloud service manager 222 Identifies and locates the class definitions referenced in the specification file and tracks the use of the class definition.

In some implementations, reuse includes a whole module (for example, the one in FIG 3B shown module "module"), wherein the module comprises a collection of several contiguous class definitions to configure a cloud component comprising a plurality of sub-components. In some implementations, the class definitions or class modules are categorized based on the type of components they model. In some implementations, the definition selection interface allows the potential users of the class definitions to browse or validate available class definitions by categories, functions, definition providers, and other attributes associated with the class definitions and modules.

In some implementations, the cloud service provider offers 104 or a third-party vendor also provides a platform for software vendors 418 to provide software solutions that are accompanied by several alternative configuration specifications or alternative collections of class definitions for configuring the software solutions. For example, a personal management program may be accompanied by configuration specifications tailored for cloud service customers having different company sizes, needs, and internal infrastructures. If a cloud service customer is the cloud deployment software solution for the cloud service provider 104 purchases or licenses, the cloud service customer can choose the configuration specification that best suits their needs.

In some implementations, the service manager may 222 Submissions of software solutions with associated configuration specifications (for example, either as configuration specifications or modules of reusable class definitions) via a software submission user interface received through the frontend 120 provided. In some implementations, the software submission user interface includes registration and authentication functions, such that each submission is a configuration-encapsulated software solution 420 is stored in conjunction with the software vendor who runs the configuration-wrapped software solution 420 submitted.

The cloud service provider 104 For example, the configuration-wrapped software solutions may be available to cloud service customers (e.g. 102 . 102b . 102c ) through the frontend 120 in a software selection interface. The software selection interface may also provide the descriptions of the various configuration specifications accompanying each software solution. When a user (for example, a cloud application service management user) selects a software solution and one of the associated configuration specifications from the software selection interface, the cloud service provider may 104 start the software solution in the cloud-based environment according to the selected configuration specification, with or without additional customization.

In some implementations, the cloud service provider facilitates 104 Billing (for example, through a billing component 426 ) for the sale and purchase of the reusable configuration specifications, reusable class definitions, and configuration-packed software solutions that are achieved by the platforms that the cloud service provider provides 104 to be provided. In some implementations, the cloud service provider does not need to provide these platforms directly, but can (for example, through the accounting component 426 ) to the user and provider of reusable configuration specifications, the reusable class definitions and the configuration-packed software solutions based on the actual usage in the cloud service provider's cloud environment 104 has provided accounting services.

In some implementations, the cloud service manager includes 222 a service monitor 422 , The service monitor 422 monitors the states of cloud services operating in the cloud service provider's cloud environment 104 have been provided. The status information provided by the service monitor 422 For example, the virtual resources used for each component of a cloud-based deployment, the utilization level of the virtual resources, the cloud services used by each component of the cloud-based deployment, the usage level of the cloud services. The service monitor 422 can calculate performance metrics associated with each cloud-based deployment based on the status of the virtual resources and the cloud-based services associated with the deployment. The performance metrics include, for example, the number of user requests received, the latency associated with the responses, the availability of the virtual resources and services, the error rate of each virtual resource or service, the fault tolerance of the virtual resources and services, and so forth. In some implementations, the performance metrics become in a performance data store 424 the cloud service manager 222 saved.

As disclosed in this specification, cloud-based implementations may be performed according to configuration specifications written in an object-oriented specification language, wherein the configuration specifications include class definitions that model different aspects of the cloud-based deployments at different levels of abstraction. If the cloud service manager 222 processing a configuration specification into a set of class definitions is the cloud service manager 222 able to track the hierarchy of class definitions that influenced the configuration of each of these different aspects of the implementation. Further, the cloud service provider is able to associate the virtual resources and services associated with various aspects of cloud-based provisioning to the various class hierarchies that have influenced the configuration of these aspects of cloud-based provisioning.

Therefore, the object-oriented specification language allows performance metrics for each of these different aspects to be derived based on the status and performance of the virtual resources and services that contribute to the performance of the cloud-based deployment aspect. In particular, the performance associated with every aspect of cloud-based deployment is associated with the class definitions involved in the configuration of this aspect of cloud-based deployment. Thereafter, the performance associated with a class definition may be used as a factor for determining a quality measure for the class definition. If a class definition is used to configure multiple cloud-based deployments, the aggregate performance associated with the class definition can be used to assess the quality of the class definition.

Using the reusable class definitions and configuration specifications provided in the 3B and 3C as an example, the service manager may 222 when the service cloud manager 222 the Mantis and MySQL software applications and the firewall service in Mantis application deployment according to the MantisDeployment class definition 354 and all base classes, of which the class definition is MantisDeployment 354 Depends on, monitors the respective performance of the software roles, the firewall service, and the underlying virtual machines that support the software roles. The cloud service manager 222 For example, the respective services of the front-end role can be assigned to the classes that influenced the configuration of the front-end component of the Mantis implementation, linking the respective performance of the firewall component to the classes that influenced the configuration of the firewall component match the actual performance of the virtual machines that underlie the front-end role with the classes that influenced the configuration of the front-end virtual machines, and so on.

In some implementations, the cloud service manager 222 Create a system block diagram of the cloud-based deployment according to the configuration specification letter in the object-oriented specification language. The class definitions in the configuration specification can be used to identify the properties of infrastructural components, storage, services, software roles and their relationships (such as dependencies and connectivity), reconfiguration triggers, and display them as corresponding elements in the system block diagram of the deployment. The basic system block diagram can be created if the configuration specification is provided by, for example, the API Translator 404 is analyzed.

5 shows the block diagram 500 based on the deployment specification 340 , in the 3C is shown can be generated. When analyzing the configuration specification 340 Mantis application deployment is detected by the Cloud Service Manager 222 from the MantisDeployment class definition 354 in that there are two software roles and one firewall involved in the deployment, for example the software roles modeled by the class definitions "MantisFrontendRole" and "MantisDatabaseRole", and a firewall modeled by the class definition "MatisFirewall". Therefore, the cloud service manager 222 a block 504 for the front end roll, a block 506 for the database role and a block 508 for the firewall service within a block 502 adding the Mantis application deployment.

Next, the cloud service manager determines 222 according to the class definition of the class "MantisFrontendRole", that the software application serving the frontend role should be provided according to the class definition of the class "mantis_frontend". The cloud service manager 222 therefore adds a block 510 inside the block 504 to represent the front-end software that serves the front-end role. Similarly, the service administrator determines 222 from the class definition of the MantisDatabaseRole class, to provide the software application serving the database role according to the class definition of the mantis_backend class. Therefore, the service manager adds a block 512 inside the block 506 to represent the backend database software that serves the database role.

Further, according to the class definitions 348 and 350 MantisFrontendRole and MantisDatabaseRole connect the front-end role and the database role. Based on the class definition 352 the "MantisFirewall" is the firewall connected to the frontend role. Therefore, the cloud service manager 222 a connection 514 between the block 504 and the block 506 Insert to represent the connectivity relationship between the frontend role and the database role. Additionally, the cloud service manager adds 222 also a connection 516 between the block 504 and the block 508 to represent the connectivity relationship between the front-end role and the firewall.

In addition, the cloud service manager determines 222 from the class definition 330 the class "FrontendRole" because the "MantisFrontRole" class definition 348 from the FrontendRole class definition 330 assumes that the front-end software (for example, the Mantis software) is to be installed on a virtual machine that is defined by the class definition 324 "FrontendVM" is modeled. Similarly, the class definition expands 350 "MantisDatabaseRole" from the class definition 332 for the database routine and the cloud service manager 222 determined from the class definition 332 In the DataBaseRole class, the back-end database software (for example, the MySQL database software) should be installed on the same virtual machine as the front-end role software. Based on the above information, the service administrator adds 222 a block 518 under the blocks 504 and 506 to represent the underlying virtual machine for the front end role and the database role. Further, the cloud service manager determines 222 according to the class definition 332 "DatabaseRole" that a persistent disk is connected to the database role through a mount point on the underlying virtual machine. The persistent disk is provided according to the specification used in the class definition 328 specified by MysqlPD. Therefore, the service manager adds 222 a block 520 to the block 502 which represents the Mantis implementation and adds a connection 522 to illustrate the connectivity relationship between the database software, its underlying virtual machine, and the persistent disk.

In some implementations, the service manager may 222 Also, if the components of the deployment are implemented, identifiers associated with the underlying infrastructure components (eg, process IDs or virtual machine identifiers and other virtual resources) for each block or connection shown in the block diagram 500 is shown, record. If the cloud service manager 222 Monitoring the states of the underlying virtual resources and services for deployment determines the cloud service manager 222 optionally, the performance or usage metrics for each component (eg, blocks and links) shown in the block diagram 500 being represented. The cloud service manager 222 Optionally, the services and usage of the various components in the system block diagram can also be optional 500 represent.

In some implementations, the visualization of the services and the use of these various components of the implementation and their changes over time on the block diagram 500 to be shown. In some implementations, the cloud service manager 222 display the performance and usage statistics in a visual form on the block diagram in a cloud services management interface for each cloud service user. For example, the performance and usage statistics can be displayed as a histogram or pie chart which changes dynamically according to the actual conditions of the components in the cloud environment. In some implementations, the cloud service provider calculates the cloud service customers according to the performance and usage statistics. In some implementations, the configuration specification optionally includes program-controlled reconfiguration requests. For example, the configuration specification for a component may be specified such that when a particular monitored parameter reaches a certain threshold, the cloud service manager 222 scales the deployed virtual machine or services by a certain amount. For a more specific example, the class definition of the persistent disk class (for example, the MysqlPD class definition) may include an instruction that requests an increase in the size of the persistent disk when the disk capacity is 80% utilized. The class definition of class "frontendVM" may request that if the latency of the frontend role is more than one second, the "replica counter" parameter of the frontend VM is incremented by one; and so on.

As stated in this specification, the object-oriented specification language allows the configuration of each component in a cloud-based implementation to be specified by a corresponding set of class definitions. In analyzing a configuration specification, the service manager is able to identify the components of the deployment and identify any base classes whose class parameters have contributed or influenced the configuration state of the component. In some implementations, the performance of each component is associated with the class definitions that contributed to the configuration of that component. If a class definition has contributed to the configuration of multiple components in multiple deployments, the performance of these multiple components in the multiple deployments can be linked to this class definition. The quality of the class definition may be judged, at least in part, on the aggregate performance of all of the multiple components in the multiple deployments.

In some implementations, the cloud service manager tracks the use of each class definition in the cloud-based environment and charges cloud service users who have used the class definition in their deployments. Optionally, the amount of fees charged to the users is based on the amount of usage that the user has caused for the class definition in all of the user-requested deployments. In some implementations where the class definitions are provided by third-party definition providers, the cloud service manager may 222 for each use of the class definition provided by the third party definition provider, record a credit for the third party definition provider.

For example, if the configuration specification for the in 3C Mantis application deployment being analyzed is captured by the cloud service manager 222 that the Mantis frontend component 504 according to the class definition 348 "MantisFrontendRole" is used, which is the class definition 330 "Lamp.FrontendRole" extends, it uses the class definition "mantis frontend" for the software configuration and the class definition 346 "MantisPackage" to identify the location of the software package, and is with the class 350 "MantisDatabaseRole" connected. Further, the service manager determines 222 that is the class definition 330 the "lamp.FrontendRole" extends from the class definition "std.Role" and the class definition 324 "FrontendVM" is used, and that is the class definition 324 "FrontendVM" extends from the class definition "utils.ConfiguratorLAMP".

The cloud service manager 222 can also identify the class definitions that are involved in the configuration of the deployment front-end role component by specifying the class hierarchies associated with the MantisFrontendRole class definition 348 are tracked until the most basic sets of class definitions are identified. All class definitions that contributed to the configuration of the front-end role component are mapped to the deployment front-end role component. A similar procedure can be performed for each component of the insert.

When the implementation is performed, the cloud service manager can 222 record the usage of each class definition in the configuration of the deployment according to the number of times the class definition used in the implementation. In some implementations, the multiple use of a class definition is counted once for each implementation or for each user, depending on the payment structure defined by the class definition definition provider (eg, fees per usage license or per sale).

In some implementations, in a reusable class definition marketplace, each newly used class definition may be classified against other reused class definitions according to the aggregate performance of the class definition in all deployments that used the class definition. In some Implementations can associate the performance of a deployment with any class definition that has contributed to the configuration of the deployment, and can be used in evaluating the quality of the class definition. In some implementations, only the performance of the components whose configurations are affected by a class definition are associated with the class definition and used in evaluating the quality of the class definition.

For example, if the cloud service manager identified multiple components in multiple deployments that are affected by a definition of a virtual machine, the aggregate performance of the multiple components is used to assess the quality of the virtual machine's definition. Additionally, if the cloud service manager identifies any class definitions associated with the configuration of a front-end role component of a deployment, the performance associated with the front-end role component in the deployment is associated with each of those identified class definitions.

In some implementations, a quality factor is calculated for each class definition based on aggregate performance associated with all or multiple components or deployments configured at least in part based on the class definition. The Quality Score may be presented with the class definition in the definition selection interface provided by the cloud service provider. In some implementations, for each class definition, multiple quality metrics may be computed based, for example, on the scales of the implementations that used the class definition, the weight or impact of the class definition in each implementation that used the class definition, the availability, the Fault tolerance, scalability and failure rate of the components configured according to the class definition, the types of problems encountered, the modifications required to solve the problems encountered, explicit user feedback and so on. Based on the various quality metrics, one or more types of quality values may be provided for each common class definition, and a potential definition user may search the list of available shared class definitions based on the quality values.

Although the example above describes the quality rating for reusable class definitions, similar quality values can be calculated for reusable class modules, reusable configuration specifications, or configuration packaged software solutions.

6 is a flowchart of an example process 600 for processing a configuration specification written in an object-oriented specification language. An example of such a high-level object-oriented specification language is in 3A - 3C shown. The example process 600 can be obtained from a cloud service provider (for example, the in 1 shown cloud service provider 104 ), such as from a cloud service manager (for example, the cloud service manager 222 ) of the cloud service provider. In some implementations, the cloud service manager leads the process 600 through an API translator component (for example, the API translator 404 in 4 ) out.

In the example process 600 is a configuration specification for configuring a cloud-based deployment (for example, by the API translator of a cloud service provider) ( 602 ) received. The configuration specification is written in an object-oriented specification language and requires instantiation of class definitions of one or more classes. Each class models a corresponding cloud-based deployment data or function component using a set of configurable class parameters. The respective class definition of each class represents a requested state of the data or function component modeled by the class. A variety of API calls to configure cloud-based deployment are made based on the class definitions of one or more classes ( 604 ) derived. The cloud service provider's API translator then causes the plurality of API calls to be executed to complete the cloud-based deployment ( 606 ).

In some implementations, the one or more classes include at least one existing base class and at least one custom class extended from the existing base class. In some implementations, the custom class inherits corresponding class parameters of the existing base class and modifies a value of at least one of the class parameters inherited from the existing base class. In some implementations, the custom class inherits corresponding class parameters of the existing base class and modifies a value of at least one of the class parameters inherited from the existing base class.

In some implementations, the data or functional component modeled by each class is a virtual appliance that supports a cloud-based environment, a service that is used in the cloud-based environment is a software role that is dependent on an installed application in the cloud. a data packet comprising data to be used during the provisioning or operation of the cloud-based environment, or a combination of one or more thereof.

In some implementations, the object-oriented specification language supports the dependency between class definitions, and a definition dependency between a first class and a second class represents a deployment dependency between respective components modeled by the first and second classes. In some implementations, the definition dependency between the first class and the second class is expressed by a class parameter of the first class, wherein the class parameter of the first class refers to an instance of the second class.

In some implementations, the object-oriented specification language supports the connectivity between class definitions, and a value assignment that associates an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first class and the second class.

7 is a flowchart of an example process 700 for deriving a block diagram showing a topology of a cloud-based deployment based on the cloud-based deployment configuration specification. The example process 700 can be executed by a cloud service manager of a cloud service provider (for example, the one in 1 and 4 illustrated cloud service providers 104 ).

In the example process 700 The cloud service provider identifies, based on the respective class definitions of the one or more classes in a configuration specification, a plurality of data and functional components, one of the one or more classes, and one or more dependency and connectivity ratios among the plurality of data or functional components ( 702 ) are modeled. The cloud service provider then directs a block diagram of a cloud-based environment based on the identified plurality of data and functional components and the identified dependency and connectivity relationships ( 704 ). In some implementations, when deriving the block diagram, the cloud service provider also presents trigger events for dynamic reconfiguration of the cloud-based environment in the block diagram.

8th is a flowchart of an example process 800 to monitor the performance of cloud-based deployments and to associate performance with class definitions used in the configuration of cloud-based deployments.

In the example process 800 For each class definition, the cloud service provider identifies an aspect of the cloud-based deployments identified by the class definition relative to the particular initial configuration state of the aspect (FIG. 802 ) to be influenced. The cloud service provider monitors one or more features that are consistent with the identified aspect ( 804 ) assigned. The cloud service provider associates the one or more performance metrics with the class definition ( 806 ). The cloud service provider then uses the one or more performance metrics in the computation of a quality metric of the class definition ( 808 ).

9 is a flowchart of an example process 900 evaluate the quality of a reused class definition based on the aggregate performance of multiple cloud-based deployments configured based at least in part on the reused class definition. In the example process 900 The cloud service provider identifies a plurality of cloud-based deployments, each of which has been executed according to a respective configuration specification that is in the object-oriented specification language ( 902 ) is written. The cloud service provider then identifies at least one base class whose class definition is in a multiple of the plurality of cloud-based deployments ( 904 ) is used. The cloud service provider monitors the respective performance of each of the plurality of multiple cloud-based deployments ( 906 ). The cloud service provider then calculates a quality metric of the at least one base class based on the aggregate performance of the multiple of the plurality of cloud-based deployments ( 908 ). In some implementations, the respective performance of each of the plurality of plurality of cloud-based environments is a performance associated with a data or functional component modeled by the at least one class.

10 is a flowchart of an example process 1000 to derive API calls to configure a cloud-based one Deployment based on class definitions used in a configuration specification.

In the example process 1000 The cloud service provider stores corresponding class definitions of several object-oriented specification language core classes ( 1010 ). Each core class corresponds to a modular component of a cloud-based environment, and each core class can be extended with additional class parameters to configure each modular component. The cloud service provider also stores an association between each of the core classes and a corresponding set of API calls ( 1020 ). The particular set of API calls is used to configure the modular component associated with the core class according to the class parameters of the core class. The cloud service provider also stores several protocols for modifying the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition that is distinct from the core class (). 1030 ) is derived.

To derive the plurality of API calls for configuring the cloud-based deployment, in some implementations, the cloud service provider derives the plurality of API calls based on: the respective groups of API calls associated with one or more of the plurality of core classes from which one or more classes of the configuration specification are derived, and based on the plurality of protocols for modifying the respective groups of API calls.

In some implementations, the plurality of protocols further include rules for imposing an array of the groups of API calls according to dependency and connectivity relationships specified in class definitions written according to the object-oriented specification language.

11 is a flowchart of an example method 1100 to provide a platform for sharing reusable class definitions. The example procedure 1100 can be performed by a cloud service provider or a platform provider that does not offer cloud-based services.

In the example method 1100 receives the cloud service provider or platform provider from each of a variety of definition providers ( 1110 ) a corresponding definition submission. The respective definition submission includes one or more class definitions written in an object-oriented specification language. Each class definition models a data or function component of a cloud-based deployment using a set of configurable class parameters and is extensible to create at least one new class definition by modifying one or more sets of configurable class parameters or by adding one or more new class parameters. The cloud service provider or platform provider then provides a user interface for reviewing and selecting the class definitions received from the plurality of definition providers by a plurality of definition users ( 1120 ) introduces.

12 is a flowchart of an example method 1200 to configure multiple separate cloud-based deployments based on different configuration specifications that all use at least one common reusable class definition. The example procedure 1200 may be from a cloud service provider, such as the example cloud service provider 104 to be performed in 4 is shown.

In the example method 1200 The cloud service provider receives a variety of different configuration specifications that are in the object-oriented specification language ( 1210 ) are written. Each of the plurality of different configuration specifications serves to configure a unique, cloud-based deployment and includes a unique class definition that extends from the same one of the class definitions obtained from the plurality of definition providers. The cloud service provider then configures each of the different cloud-based deployments that are based at least on the same of the received class definitions and the unique class definition as reflected in the distinct configuration specification of the unique cloud-based deployment (FIG. 1220 ) of which extend.

13 is a flowchart of an example process 1300 for loading definition users and credit definition suppliers based on the use of the reusable class definitions provided by the definition suppliers.

In the example method 1300 For each of the received class definitions, the cloud service provider monitors the use of the class definition in a variety of configuration specifications that have been used to run a variety of cloud-based deployments ( 1310 ). The cloud service provider records for each use of the class definition in the multitude of Configuration specifications a loan to a definition provider of the class definition and a charge to a definition user associated with the use ( 1320 ).

In some implementations, the use of the class definition includes instantiating the class definition in a respective configuration specification that has been used to execute a respective cloud-based implementation. In some implementations, the use of the class definition includes instantiating the class definition in a respective configuration specification that has been used to execute a respective cloud-based implementation.

14 is a flowchart of an example method 1400 to provide a platform for selling and "configuration wrapped" software solutions. The process 1400 can be provided by a cloud service provider or a platform provider that does not provide cloud-based services. In the example method 1400 the cloud service provider or platform provider receives software submission from a software vendor ( 1410 ). The software submission includes a software application provided in a cloud-based environment and a variety of different configuration specifications for providing the software application in the cloud-based environment in different ways. Thereafter, the cloud service provider or platform provider provides the plurality of specific configuration specifications for review and selection by a software user ( 1420 ) ready.

15 is a flowchart of an example method 1500 for loading software users and recognizing software vendors based on software user selection of configuration-wrapped software solutions. The example procedure 1500 can be obtained from a cloud service provider (for example, the in 4 shown cloud service provider 104 ).

In the example procedure 1500 the cloud service provider receives the selection of one of the plurality of different configuration specifications from the user ( 1510 ). The cloud service provider implements the software application in the cloud-based environment according to the selected configuration specification ( 1520 ). Thereafter, the cloud service provider records a fee for the software user and a credit to the software provider based on a price corresponding to the selected different configuration specification (s). 1530 ) assigned. In some implementations, to provide the plurality of class definitions for selection, the cloud service provider provides the respective performance metrics with each of the plurality of class definitions for user reviews in a selection user interface.

16 is a flowchart of an example method 1600 to use aggregated performance metrics of multiple cloud-based deployments in classifying reusable class definitions that were used in configuring the multiple cloud-based deployments. The example procedure 1600 may be from a cloud service provider (eg, a cloud service provider 104 who in 4 shown).

In the example method 1600 the cloud service provider provides a variety of class definitions for selection ( 1610 ) ready. Each class definition models a particular data or functional component of a cloud-based environment using a set of configurable class parameters. Each class definition supports instantiation and inheritance of the class definition in a configuration specification for a cloud-based deployment. The cloud service provider also derives respective performance metrics associated with each of the plurality of class definitions based on the aggregate performance of multiple cloud-based deployments where the multiple cloud-based implementations were performed according to the particular configuration specifications that facilitate instantiation of the cloud Require a class definition or a new class definition from the class definition ( 1620 ) is derived. The cloud service provider then uses it to classify the plurality of class definitions ( 1630 ) the respective performance metrics associated with each of the plurality of class definitions.

17 is a flowchart of an example method 1700 for categorizing reusable class definitions and classifying the reusable class definitions in their respective categories.

In the example process 1700 The cloud service provider categorizes the plurality of class definitions based on the respective data or functional components of the cloud-based environment, which are defined by the plurality of class definitions (FIG. 1710 ) is modeled. Then, the cloud service provider maps the multitude of class definitions into the categories of class definitions ( 1720 ) one.

18 FIG. 10 is a flowchart of an example method. FIG 1800 to associate services from multiple cloud-based deployments with a class definition that has been used to configure the multiple cloud-based deployments.

In the example process 1800 For each of a plurality of class definitions, the cloud service provider identifies a plurality of cloud-based deployments that have been executed according to the respective configuration specifications that include an instantiation of the class definition or at least one new class definition from the class definition ( 1810 ) required. The cloud service provider monitors the respective performance of the large number of cloud-based deployments ( 1820 ). The cloud service provider then associates the respective services of the plurality of class definition deployments ( 1830 ).

19 is a flowchart of an example method 1900 for deriving performance metrics associated with a reused class definition based on aggregate performance of multiple deployments. The cloud service provider, in deriving the respective performance metrics associated with each of a plurality of class definitions based on aggregated performance of multiple cloud-based deployments, performs the example method 1900 out. In the example method 1900 For each of the plurality of class definitions, the cloud service provider identifies one or more data or functional components of the plurality of cloud-based deployments that are selected according to the class definition or a new class definition derived from the class definition. 1910 ) were configured. The cloud service provider identifies one or more performance metrics associated with the one or more identified data or functional components ( 1920 ). The cloud service provider then determines the respective performance metrics associated with the class definition by aggregating the one or more identified performance metrics ( 1930 ). In some implementations, the performance metrics include one or more measures of latency, reliability, scalability, availability, or security.

20 is a flowchart of an example method 2000 to use multiple factors in classifying reusable class definitions.

In the example method 2000 For each class definition, the cloud service provider keeps track of a number of cloud-based deployments, at least in part, according to the class definition ( 2010 ) were configured. Optionally, the cloud service provider tracks a number of problems that occur with cloud-based deployments that are at least partially configured according to the class definition. Optionally, the cloud service provider also tracks a number of required changes to solve the problems that occur in the cloud-based deployments that were at least partially configured according to the class definition. The cloud service provider then uses the respective counts associated with the plurality of class definitions in the ranking of the plurality of class definitions ( 2020 ) are associated. Optionally, the cloud service provider also uses the respective counts of the problems and the respective number of required changes associated with the plurality of class definitions in the ranking of the plurality of class definitions.

In some implementations, the respective number of required changes associated with the plurality of class definitions is used to calculate respective weights associated with the respective performance metrics associated with the plurality of class definitions to accommodate the plurality of class definitions rate.

Embodiments of the subject matter and the activities described in this specification may be implemented in digital electronic circuits or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification may be embodied as one or more computer programs, i. H. are implemented as one or more modules of computer program instructions encoded on a computer storage medium for performing or controlling the operation of the data processing apparatus. Alternatively or additionally, the program instructions may be based on a generated propagated signal, e.g. A machine-generated electrical, optical or electromagnetic signal which is generated to encode information for transmission to a suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium may be a machine-readable storage device, a machine-readable storage medium, a random or serial storage array or storage device, or a combination of one or more of these devices.

The term "data processing device" encompasses all types of devices, devices and machines for processing data including, for example, a programmable processor, a computer or multiple processors or calculator. The device may include special logic circuits, e.g. As an FPGA (Field Programmable Gate Array programmable hardware logic) or an ASIC (application-specific integrated circuit). The apparatus may include, in addition to the hardware, a code that provides an execution environment for the particular computer program in question, e.g. A code, the processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of the cited.

A computer program (also referred to as program, software, software application, script or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and the program may be in any form, including as independent program or as a module, component, subroutine or other entity suitable for use in a computing environment. A computer program may or may not be equivalent to a file in a file system. A program may be stored in a portion of a file containing other programs or data (eg, one or more scripts stored in a document in markup language), in a single file specific to that program, or in multiple coordinated files (for example, files that store one or more modules, subprograms, or pieces of code). A computer program may be set up or executed on one or more computers located at a site or distributed over multiple sites and connected via a communications network.

The processes and logic operations depicted in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logical operations may also be performed by special purpose logic circuits, and the apparatus may be implemented as special purpose circuits, e.g. As an FPGA (Field Programmable Gate Array) or an ASIC (application-specific integrated circuit).

Processors suitable for executing a computer program include, for example, both general and special purpose microprocessors, as well as all types of one or more processors of any type. In general, a processor accepts instructions and data from read-only memory or memory, or both. The essential elements of a computer are a CPU for executing instructions and one or more storage devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices for storing data, e.g. As magnetic, magneto-optical or optical disks to receive and / or transmit data, or a computer is operatively coupled to such a storage device. However, a computer does not have to have such devices. In addition, a computer may be embedded in another device, e.g. In a mobile phone, an organizer (PDA), a mobile audio or video player, a game console, a radio navigation receiver, or a portable storage device (eg, a USB stick), to name but a few.

Computer readable media suitable for storing computer program instructions and data includes all forms of non-volatile memory, media and storage devices including, for example, semiconductor memory devices, e.g. EPROM, EEPROM and USB flash memory; Magnetic disks, z. Internal hard drives or removable floppy disks; magneto-optical diskettes; and CD-ROMs and DVD-ROMs. The processor and memory may be supplemented or incorporated by special purpose logic circuits.

To facilitate interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer with a display device, e.g. As a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, with which the user information is displayed, and a keyboard and a display device, eg. As a mouse or a trackball, with which the user can make inputs to the computer. Other types of devices may be used to provide for interaction with a user; For example, a user-supplied feedback of any form of sensory feedback may be present, e.g. A visual feedback, auditory feedback or tactile feedback; and the input from the user may be received in any form, including acoustic, voice or tactile input. In addition, a computer may interact with a user by sending and receiving documents from a device used by a user; for example, by sending web pages to a web browser by a user device of the user in response to requests from the web browser.

Embodiments of the subject matter contemplated in this specification may be implemented in a computer system that includes a back-end component (eg, a data server), or a middleware component (eg, an application server), or a front-end component (e.g. A client computer with graphical user interface or web browser), which allows the user to interact with an implementation of the subject matter considered in this specification, or any combination of such backend, middleware or frontend components. The components of the system may be interconnected by any form or medium of digital data communication, e.g. B. a communication network. For example, communication networks include a local area network ("LAN"), a long distance network ("WAN"), e.g. For example, the Internet.

The computing system may include client and server. A client and server are generally remote from each other and typically interact over a communications network. The relationship between client and server arises because of computer programs that run on the respective computers and that have a client-server relationship with each other.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope or on the claims, but rather as descriptions of specific features of particular embodiments of particular inventions. Certain features described in this specification in the context of the various embodiments may also be implemented in combination in a single embodiment. On the other hand, various features described in the context of a single embodiment may be implemented in multiple embodiments or in any suitable subcombination. In addition, one or more features of a claimed combination may in some instances be released from the combination, even if the features are described above as functioning in some combinations or even claimed as a combination, and the claimed combination may be attached to a subcombination or variation of a subcombination to get expelled.

Also, while activities in the drawings are presented in a particular order, this should not be construed as requesting that such activities be performed in the particular order shown or in a sequential order, or that all activities depicted must be performed to achieve desired results to achieve. Under certain circumstances, multitasking and parallel processing can be beneficial. Moreover, the separation of various system components in the embodiments described above should not be construed as required in all embodiments, and it should be understood that the described program components and systems generally can be integrated together into a single software product or encapsulated into multiple software products.

Thus, certain embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the operations set forth in the claims may be performed in a different order and still achieve desired results. For example, the methods illustrated in the accompanying drawings do not necessarily require the order shown or sequential order to achieve desired results. In certain implementations, multitasking and parallel processing may be beneficial.

Other implementations are summarized in the following examples:
Example 1: A computer-implemented method, comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class having a respective data or functional component model the cloud-based deployment using a set of configurable class parameters and the respective class definition of each class represents a requested state of the data or functional components modeled by the class; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Identifying, based on the respective class definitions, the one or more classes of a plurality of data and functional components modeled by the one or more classes and one or more dependency and connectivity relationships existing among the plurality of data or functional components; Deriving a block diagram of a cloud-based environment based on the identified plurality of data and functional components and the identified dependency and connectivity relationships; and presenting the trigger events for the dynamic reconfiguration of the cloud-based environment in the block diagram.

Example 2: The computer-implemented method of Example 1, wherein the one or more classes include at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits corresponding class parameters of the existing base class and the custom class has a value of modified at least one of the class parameters inherited from the existing base class, or at least one new class parameter that does not exist in the existing base class.

Example 3: The computer-implemented method of Example 1, wherein the data or functional component modeled by each class is: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment, a software role performed by an installed application in the cloud-based environment, a data packet containing data to be used during the provisioning or operation of the cloud-based environment, or a combination of one or more thereof.

Example 4: The computer-implemented method of Example 1, wherein the specification language supports at least one of dependency between class definitions or connectivity between class definitions, and wherein dependency dependency between a first class and a second class represents dependency dependency between respective components passing through the first and second Class, and wherein a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first class and the second class.

Example 5: A computer-implemented method, comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class having a respective data or data class Modeling the cloud-based deployment functional component using a set of configurable class parameters and the respective class definition of each class representing a requested state of the data or functional component modeled by the class; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Identifying a plurality of cloud-based deployments, each executed according to a respective configuration specification written in the specification language; Identify at least one base class whose class definition is used in a wide variety of cloud-based deployments; Monitoring the respective performance of each of the large variety of cloud-based deployments; and calculating a quality metric of the at least one base class based on the aggregate performance of the large variety of cloud-based deployments.

Example 6: The computer-implemented method of Example 5, wherein the one or more classes include at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits corresponding class parameters of the existing base class and the custom class has a value of modified at least one of the class parameters inherited from the existing base class or at least one new class parameter that does not exist in the existing base class.

Example 7: The computer-implemented method of Example 5, wherein the data or functional component modeled by each class is: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment, a software role executed by an installed application in the cloud-based environment, packet-holding data to be used during the provisioning or operation of the cloud-based environment, or a combination of one or more thereof.

Example 8: The computer-implemented method of Example 5, wherein the specification language supports at least one of dependency between class definitions or connectivity between class definitions, and wherein dependency dependency between a first class and a second class represents dependency dependency between respective components passing through the first and second Class and wherein a value assignment connecting an instance of a second class to a class parameter of a first class is connectivity between the components modeled from the first class and the second class.

Example 9. A computer-implemented method, comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class having a respective data or function component of the cloud-based deployment using a set of configurable class parameters, and the respective class definition of each class represents a requested state of the class-modeled data or functional components; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Storing respective class definitions of multiple core classes of the specification language, wherein each core class corresponds to a modular component of a cloud-based environment, wherein each core class can be extended with additional class parameters to configure the respective modular component; Storing an association between each of the core classes and a corresponding set of API calls, the respective set of API calls for configuring the modular component being assigned to the core class according to the class parameters of the core class; and storing a plurality of protocols for modifying the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition derived from the core class.

Example 10. The method of Example 9, wherein deriving the plurality of API calls to configure the cloud-based deployment further comprises: deriving the plurality of API calls based on the respective groups of API calls that one or more are associated with the plurality of core classes from which the one or more classes of the configuration specification are derived, and based on the plurality of protocols for modifying the respective groups of API calls.

Example 11: The method of Example 9, wherein the plurality of protocols further comprises rules for imposing an array of the groups of API calls according to dependency and connectivity relationships specified in class definitions written according to the specification language.

Example 12: The method of Example 9, wherein the one or more classes include at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits corresponding class parameters of the existing base class and the custom class has a value of at least that Modifies class parameters inherited from the existing base class, or at least includes a new class parameter that does not exist in the existing base class.

Example 13: The method of Example 9, wherein the data or functional component modeled by each class is one of: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment, a software role executed by an installed application in the cloud-based environment, package holding data to be used during the deployment or operation of the cloud-based environment, or a combination of one or more thereof.

Example 14. The method of Example 9, wherein the specification language supports the dependency between class definitions and a dependency dependency between a first class and a second class represents a dependency dependency between respective components modeled by the first and second classes.

Example 15: The method of Example 9, wherein the specification language supports connectivity between class definitions and a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components of the first class and the second Class are modeled.

Example 16: A system comprising: one or more processors; and a memory having instructions stored thereon, the instructions, when executed by the one or more agents, causing the operators to perform operations comprising: receiving a configuration specification for configuring a cloud-based deployment, the configuration specification being included in a Specification language is written and requires an instantiation of the respective class definitions of one or more classes, each class a respective data or Cloud Based Implementation Function Component Using Modeled A set of configurable class parameters and the respective class definition of each class representing a requested state of the data or functional components modeled by the class; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Executing the plurality of API calls to configure the cloud-based deployment; Identifying, based on the respective class definitions of the one or more classes, a plurality of data and functional components modeled by the one or more classes and one or more dependency and connectivity relationships consisting of the plurality of data or functional components; Deriving a block diagram of a cloud-based environment based on the identified plurality of data and functional components and the identified dependency and connectivity relationships; And show trigger events for the dynamic reconfiguration of the cloud-based environment in the block diagram.

Example 17: The system of Example 16, wherein the one or more classes comprise at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits the respective class parameters of the existing base class and the custom class has a value of at least one of the class parameters inherited from an existing base class, or at least one new class parameter that does not exist in the existing base class.

Example 18. The system of Example 16, wherein the data or functional component modeled by each class is one of: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment A software role that is executed by an installed application in the cloud-based environment, a data packet that stores data to be used during the provisioning or operation of the cloud-based environment, or a combination of one or more thereof.

Example 19. The system of Example 16, wherein the specification language supports at least one of a dependency between class definitions and a connectivity between class definitions, and wherein a dependency dependency between a first class and a second class represents a dependency dependency between respective components represented by the first and second classes and wherein a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first class and the second class.

Example 20. A system comprising: one or more processors; and a memory having instructions stored thereon, the instructions, when executed by the one or more processors, causing the processors to perform operations comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification in a specification language and requires instantiation of the respective class definitions of one or more classes, each class modeling a respective data or function component of the cloud-based implementation using a set of configurable class parameters and the respective class definition of each class representing a requested state of the data or functional components modeled by the class; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Identifying a plurality of cloud-based deployments, each executed according to a respective configuration specification written in the specification language; Identify at least one base class whose class definition is used in the wide variety of cloud-based deployments; Monitoring the respective performance of each of the large variety of cloud-based deployments; and calculating a quality metric of the at least one base class based on the aggregate performance of the large variety of cloud-based deployments.

Example 21. The system of Example 20, wherein the one or more classes include at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits corresponding class parameters of the existing base class and the custom class has a value of at least one modifies the class parameter inherited from the existing base class, or at least includes a new class parameter that does not exist in the existing base class.

Example 22: The system of Example 20, wherein the data or functional component modeled by each class is one of: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment A software role that is executed by an installed application in the cloud-based environment, a data packet that stores data to be used during the provisioning or operation of the cloud-based environment, or a combination of one or more thereof.

Example 23: The system of Example 20, wherein the specification language supports at least one of a dependency between class definitions and a connectivity between class definitions, and wherein a dependency dependency between a first class and a second class represents a dependency dependency between respective components represented by the first and second classes and wherein a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first class and the second class.

Example 24. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, causing the processors to perform operations comprising: receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class modeling a respective data or function component of the cloud-based implementation using a set of configurable class parameters, and requesting the respective class definition of each class State the data or function components modeled by the class; Deriving a plurality of Application Programming Interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Storing respective class definitions of a plurality of specification-language core classes, each core class corresponding to a modular component of a cloud-based environment, wherein each core class may be augmented with additional class parameters to configure the respective modular component; Storing an association between each of the core classes and a corresponding set of API calls, the respective set of API calls serving to configure the modular component associated with the core class according to the class parameters of the core class; and storing a plurality of protocols for modifying the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition derived from the core class.

Example 25: The computer-readable medium of Example 24, wherein deriving the plurality of API calls to configure the cloud-based deployment further comprises: deriving the plurality of API calls based on the respective groups of API calls that are one or; associated with a plurality of the plurality of core classes from which the one or more classes of the configuration specification are derived, and based on the plurality of protocols for modifying the respective groups of API calls.

Example 26: The computer-readable medium of Example 24, wherein the plurality of protocols further comprises rules for imposing an array of the groups of API calls according to dependency and connectivity relationships specified in class definitions written according to the specification language.

Example 27: The computer-readable medium of Example 24, wherein the one or more classes include at least one existing base class and at least one custom class extended from the existing base class, wherein the custom class inherits corresponding class parameters of the existing base class and the custom class has a value of at least one of the class parameters inherited from the existing base class, or at least one new class parameter that does not exist in the existing base class.

Example 28: The computer-readable medium of Example 24, wherein the data or functional component modeled by each class is one of: a virtual device that supports a cloud-based environment, a service that is used in the cloud-based environment, a software role executed by an installed application in the cloud-based environment, a data packet storing data to be used during deployment or operation of the cloud-based environment, or a combination of one or more thereof.

Example 29: The computer-readable medium of Example 24, wherein the specification language supports dependency between class definitions and a dependency dependency between a first class and a second class depicts deployment dependency between respective components modeled by the first and second classes.

Example 30: The computer-readable medium of Example 24, wherein the specification language supports connectivity between class definitions and a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components selected by the first class and the first class class second class are modeled.

Claims (7)

A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, causing the processors to perform operations comprising: Receiving a configuration specification to configure a cloud-based deployment, wherein the configuration specification is written in a specification language and requires instantiation of the respective class definitions of one or more classes, each class configuring a corresponding data or function component of the cloud-based implementation using a group Class parameters and the respective class definition of each class represents a requested state of the data or function components modeled by the class; Deriving a plurality of application programming interface (API) calls to configure the cloud-based deployment based on the class definitions of the one or more classes; Causing the plurality of API calls to be executed to configure the cloud-based deployment; Storing respective class definitions of a plurality of specification-language core classes, each core class corresponding to a modular component of a cloud-based environment, wherein each core class may be augmented with additional class parameters to configure the respective modular component; Storing a mapping between each of the core classes and a respective set of API calls, the respective set of API calls for configuring the modular component associated with the core class according to the class parameters of the core class; and Storing a plurality of protocols for modifying the respective groups of API calls associated with each core class to obtain a new set of API calls for a new class definition derived from the core class. The computer-readable medium of claim 1, wherein deriving the plurality of API calls for configuring the cloud-based deployment comprises: Deriving the plurality of API calls based on the respective groups of API calls associated with one or more of the plurality of core classes from which the one or more classes of the configuration specification are derived, and based on the plurality of protocols for modifying the respective groups of API calls. The computer-readable medium of claim 1, wherein: the plurality of protocols further comprise rules for imposing an array of the groups of API calls according to dependency and connectivity relationships specified in class definitions written according to the specification language. The computer-readable medium of claim 1, wherein: the one or more classes comprise at least one existing base class and at least one custom class extended by the existing base class, the custom class inherits corresponding class parameters from the existing base class and the custom class modifies a value of at least one class parameter inherited from the existing base class or at least one new class parameter that does not exist in the existing base class. The computer-readable medium of claim 1, wherein: the data or function component modeled by each class is one of the following: a virtual appliance that supports a cloud-based environment, a service that is used in the cloud-based environment, a software role that is executed by an installed application in the cloud-based environment, a data package that stores data that during the provisioning or operation of the cloud-based environment, or a combination of one or more of them. The computer-readable medium of claim 1, wherein: the specification language supports dependency between class definitions and a dependency dependency between a first class and a second class represents staging dependency between respective components modeled by the first and second classes. The computer-readable medium of claim 1, wherein: the specification language supports connectivity between class definitions, and a value assignment associating an instance of a second class with a class parameter of a first class represents connectivity between respective components modeled by the first class and the second class.

Images