Declarative language and compiler for provisioning and deploying data centers on cloud platforms

Abstract

A computing system, for example, a multi-tenant system, creates a datacenter within a cloud platform using a cloud platform-independent cloud platform infrastructure language. The system receives a platform-independent declarative specification that describes a new datacenter to be created or modifications to an existing datacenter deployed on the cloud platform. The system compiles the cloud platform-independent declarative specification to generate a metadata representation of the datacenter. If the datacenter exists, the system generates a metadata representation that describes modifications to the datacenter to obtain the desired datacenter. The system transmits the metadata representation and a set of instructions to execute on a target cloud platform. The target cloud platform executes the instructions to configure the datacenter. The system provides users with access to computing resources in the datacenter configured by the target cloud platform.

Description

[Technical Field]

[0001] The present disclosure relates generally to cloud computing platforms, and more particularly to declarative languages ​​and compilers for creating data centers in cloud computing platforms. [Background technology]

[0002] Organizations are increasingly turning to cloud computing platforms (or cloud platforms), such as Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure, for their infrastructure needs. Cloud platforms provide organizations with servers, storage, databases, networking, software, and more over the Internet. Traditionally, organizations maintained data centers to house the hardware and software used by the organization. However, maintaining a data center can incur significant overhead in terms of maintenance, personnel, and so on. As a result, organizations are migrating their data centers to cloud platforms that offer scalability and elasticity of computing resources.

[0003] Organizations maintain cloud infrastructure on cloud platforms using continuous delivery platforms that can manage and deploy applications on the cloud platforms. Such continuous delivery platforms enable organizations to simplify the software deployment process and manage applications, firewalls, clusters, servers, load balancers, and other computing infrastructure on the cloud platforms. However, maintaining large-scale data centers on cloud platforms using continuous delivery platforms can be complex. Such large-scale data centers may require maintaining millions of lines of instructions for such platforms. Furthermore, multi-tenant systems manage data and applications for multiple organizations, representing tenants of the multi-tenant system.

[0004] A multi-tenant system may need to maintain thousands of data centers on a cloud platform. Maintaining such data centers can be a complex task because each data center may require millions of lines of code. Furthermore, the software, languages, and features supported by each cloud platform may differ. For example, different cloud platforms may support different mechanisms for implementing network policies or access control. Furthermore, a network policy supported by a particular cloud platform may not be supported by another cloud platform. As a result, a multi-tenant system must maintain different data center implementations depending on the number of cloud platforms supported for the data center. As a result, a multi-tenant system that supports data centers across multiple cloud platforms incurs high maintenance costs. [Brief explanation of the drawings]

[0005] [Figure 1]FIG. 1 is a block diagram of a system environment illustrating a multi-tenant system that configures a data center on a cloud platform, according to one embodiment.

[0006] [Figure 2] FIG. 2 is a block diagram illustrating a system architecture of a data center generation module, according to one embodiment.

[0007] [Figure 3] FIG. 2 is a block diagram illustrating the architecture of a compilation module, according to one embodiment.

[0008] [Figure 4] 1 illustrates an example of a data center declarative specification, according to one embodiment.

[0009] [Figure 5] 1 illustrates an exemplary data center created on a cloud platform based on a declarative specification, according to one embodiment.

[0010] [Figure 6] 1 is a flowchart illustrating a process for creating a data center on a cloud platform based on a declarative specification, according to one embodiment.

[0011] [Figure 7] FIG. 1 is a block diagram illustrating the creation of a data center on a cloud platform based on a declarative specification, according to one embodiment.

[0012] [Figure 8] 1 is a flowchart illustrating a process for deploying a data center on a cloud platform, according to one embodiment.

[0013] [Figure 9] FIG. 2 is a block diagram illustrating a system architecture of a data center modification module, according to one embodiment.

[0014] [Figure 10A] 1 illustrates a metadata representation of a data center according to one embodiment.

[0015] [Figure 10B] 10B illustrates a modified metadata representation of the data center of FIG. 10A, according to one embodiment.

[0016] [Figure 10C] 10C illustrates a delta metadata representation based on the differences between the metadata representations of FIGS. 10A and 10B, according to one embodiment.

[0017] [Figure 11] 1 is a flowchart illustrating a process for modifying a data center deployed on a cloud platform, according to one embodiment.

[0018] [Figure 12] 2 is a block diagram illustrating a functional diagram of a typical computer system for use in the environment of FIG. 1, according to one embodiment.

[0019] The drawings depict various embodiments for purposes of illustration only. Those skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the embodiments described herein.

[0020] The figures use like reference numbers to identify like elements. Letters following a reference number, such as "115a," indicate that the text is specifically referring to the element having that particular reference number. A reference number in the text without a following letter, such as "115," refers to any or all of the elements in the figure having that reference number. DETAILED DESCRIPTION OF THE INVENTION

[0021] Cloud platforms provide computing resources, such as storage, computing resources, and applications, to computing systems on an on-demand basis over public networks such as the Internet. Cloud platforms allow companies to minimize the initial costs of setting up computing infrastructure and enable companies to quickly launch and run applications with less maintenance overhead. Cloud platforms also allow companies to adjust computing resources to rapidly fluctuating and unpredictable demand. Companies can create data centers using cloud platforms for use by their users. However, implementing a data center on each cloud platform requires specialized knowledge of the cloud platform's technology.

[0022] Embodiments enable a computing system (or systems) to create a datacenter within a cloud platform using a cloud platform-agnostic cloud platform infrastructure language. The system receives a cloud platform-agnostic declarative specification for the datacenter. The declarative specification describes the datacenter and may not provide instructions for creating the datacenter. The cloud platform-agnostic declarative specification is configured to generate a datacenter on any of multiple cloud platforms and is specified using the cloud platform infrastructure language. The system receives information identifying a target cloud platform for creating the datacenter. The system compiles the cloud platform-agnostic declarative specification to generate a cloud platform-specific datacenter representation. The system transmits the platform-specific datacenter representation and a set of instructions for execution on the target cloud platform. The target cloud platform executes the instructions to configure the datacenter using the platform-specific datacenter representation. The system provides a user with access to computing resources of the datacenter configured by the cloud platform.

[0023] In one embodiment, a system enables modification of a data center deployed on a cloud platform based on modifications to a declarative specification describing the data center. The system creates a data center on the cloud platform based on an original version of the declarative specification. The system receives the modified declarative specification along with instructions to modify the data center to correspond to the description specified in the modified declarative specification. The system generates a delta metadata representation representing differences between an original version of the data center based on the original declarative specification and a modified version of the data center based on the modified declarative specification. The system generates a modification plan based on the delta metadata representation, the modification plan including instructions for modifying the data center on a target cloud platform to obtain a modified version of the data center. The system sends the generated execution instructions to the target cloud platform. The target cloud platform executes the generated instructions to obtain the modified version of the data center from the original version of the data center. The system provides a set of users with access to computing resources in the modified version of the data center deployed on the target cloud platform. The data center may be created for a set of users associated with tenants of a multi-tenant system. Alternatively, the set of users may be any users, for example, users of a company that has requested the creation of a data center, or users associated with any computing system that has requested the creation of a data center.

[0024] In one embodiment, the delta metadata representation includes nodes representing data center entities annotated with the type of operation associated with the data center entity, for example, a create operation, a delete operation, or an update operation. The remediation plan may include instructions to start the data center entities in an order determined based on the start dependencies specified in the delta metadata representation. If the remediation plan includes instructions to delete or decommission a data center entity, the remediation plan specifies the order in which other data center entities that depend on this data center entity are to be decommissioned in an order determined based on the dependency graph.

[0025] Cloud platforms are also referred to herein as substrates. While declarative specifications of data centers are substrate-independent or substrate-agnostic, cloud platform-specific data center representations are substrate-specific. When creating a data center using traditional methods, users must provide cloud platform-specific instructions for creating each data center entity. Therefore, users must know how to create each data center entity for a cloud platform. Furthermore, the instructions are cloud platform-specific and not portable across multiple platforms. For example, instructions for creating a data center or data center entity on the AWS cloud platform are different from instructions for creating the same data center or data center entity on the GCP cloud platform. Developers creating data centers on each cloud platform must understand the details of how each data center entity and function is implemented on that specific cloud platform. The disclosed system provides a cloud platform infrastructure language that enables users to describe the data center they want to create on any cloud platform selected from multiple cloud platforms. A compiler for the cloud platform infrastructure language generates a detailed cloud platform specific metadata representation of the data center and creates the data center on the target cloud platform.

[0026] The cloud platform infrastructure language is sometimes referred to as a domain-specific language (DSL) for creating datacenters. The system may represent a multi-tenant system, but is not limited to a multi-tenant system, and may be any online system or any computing system with network access to a cloud platform. Overall system environment

[0027] 1 is a block diagram of a system environment illustrating a multi-tenant system that configures a data center on a cloud platform, according to one embodiment. System environment 100 includes multi-tenant system 110, one or more cloud platforms 120, and one or more client devices 105. In other embodiments, system environment 100 may include more or fewer components.

[0028] The multi-tenant system 110 stores information for one or more tenants 115. Each tenant may be associated with a company that represents a customer of the multi-tenant system 110. Each tenant may have multiple users who interact with the multi-tenant system via client devices 105. In the multi-tenant system 110, data for multiple tenants may be stored in the same physical database. However, the system may be configured so that one tenant's data is kept logically separate from other tenants' data, such that one tenant does not have access to another tenant's data unless such data is explicitly shared. It is transparent to the tenants that their data may be stored in tables shared with other customers' data. A database table may store rows for multiple tenants. Thus, in a multi-tenant system, various elements of the system's hardware and software may be shared by one or more tenants. For example, the multi-tenant system 110 may run an application server that processes requests for multiple tenants simultaneously. However, the multi-tenant system enforces tenant-level data isolation to ensure that one tenant's jobs do not access another tenant's data.

[0029] A cloud platform is also referred to as a cloud computing platform or a public cloud environment. A tenant may use a cloud platform infrastructure language to provide a declarative specification of a data center to be created on the target cloud platform 120. A tenant 115 may create one or more data centers on the cloud platform 120. A data center represents a set of computing resources, including servers, applications, storage, memory, etc., that can be used by a user, e.g., a user associated with the tenant.

[0030] The computing resources of a data center are secure and inaccessible to users who are not authorized to access them. For example, data center 125a created for users of tenant 115a cannot be accessed by users of tenant 115b unless access is explicitly granted. Similarly, data center 125b created for users of tenant 115b cannot be accessed by users of tenant 115a unless access is explicitly granted. Furthermore, services provided by a data center may be accessed by computing systems outside the data center only if the computing systems are granted access according to the data center's declarative specification.

[0031] Examples of cloud platforms include Amazon Web Services (AWS), Google Cloud Platform, or Microsoft Azure. The cloud platform 120 provides computing infrastructure services that may be used on-demand by tenants 115 or by any computing system external to the cloud platform 120. Examples of computing infrastructure services provided by the cloud platform include servers, storage, databases, networking, security, load balancing, software, analytics, intelligence, and other infrastructure service capabilities. These infrastructure services may be used by tenants 115 to build, deploy, and manage applications in a scalable and secure manner.

[0032] The multi-tenant system 110 may include a tenant data store that stores data related to various tenants of the multi-tenant store. The tenant data store may store data for different tenants in separate physical structures, for example, separate database tables or separate databases. Alternatively, the tenant data store may store data for multiple tenants in a shared structure. For example, user accounts for all tenants may share the same database table. However, the multi-tenant system stores additional information to logically separate the data of different tenants.

[0033] Each component shown in Figure 1 represents one or more computing devices. The computing devices may be, for example, conventional computer systems running a Microsoft® Windows®-compatible operating system (OS), Apple® OS X, and / or a Linux® distribution. The computing devices may be client devices with computer capabilities, such as personal digital assistants (PDAs), mobile phones, video game systems, etc. Each computing device stores software modules that store instructions.

[0034] Interaction between the various components of system environment 100 is typically performed over a network, not shown in Figure 1. In one embodiment, the network uses standard communication technologies and / or protocols. In another embodiment, the entities may use custom and / or proprietary data communication technologies instead of or in addition to those described above.

[0035] Although the techniques disclosed herein are described in the context of a multi-tenant system, these techniques may be implemented using other systems that may not be multi-tenant systems. For example, an online system used by a single organization or company may use the techniques disclosed herein to create one or more data centers on one or more cloud platforms 120. System Architecture

[0036] 2 is a block diagram illustrating a system architecture of a data center generation module, according to one embodiment. Data center generation module 210 includes version control system 220, compilation module 230, and deployment module 240. Other embodiments may have different and / or other components than those described herein, and functionality may be distributed among components in different ways.

[0037] Version control system 220 stores one or more versions of a platform-independent declarative specification 225 of the data center. The platform-independent declarative specification 225 of the data center defines various entities of the data center, including the services available at the data center and their interactions. Expert users may modify the platform-independent declarative specification, for example, using applications running on client devices 105. Modifications to the platform-independent declarative specification may be submitted via commit requests in version control system 220. Version control system 220 allows users to create snapshots of the platform-independent declarative specification at various stages of modification, thereby allowing users to roll back specific changes and apply previous versions of the platform-independent declarative specification.

[0038] Compilation module 230 receives as input platform-independent declarative specification 225 and a target cloud platform and generates cloud platform-specific metadata representation 235 for the target cloud platform. The architecture of compilation module 230 and the processes performed by compilation module 230 are described in further detail herein, for example, in the description of Figure 3. Deployment module 240 deploys the generated cloud platform-specific metadata representation 235 on the target cloud platform to create a data center on the target cloud platform according to declarative specification 225.

[0039] 3 is a block diagram illustrating the architecture of a compilation module 230, according to one embodiment. The compilation module 230 includes a specification analysis module 310, a security module 320, a user account processing module 330, a metadata store 340, and a provisioning module 350. Other embodiments may include more, fewer, or different modules than those illustrated herein in FIG. 3.

[0040] Specification analysis module 310 analyzes data center declarative specification 225 received as input by compilation module 230. Specification analysis module 310 identifies individual data center entities represented in data center declarative specification 225. Specification analysis module 310 generates data structures and metadata representations of the data center entities and provides the generated data structures and metadata representations to other modules of compilation module 230 for further processing.

[0041] Security module 320 handles security aspects of the various data center entities defined in data center declarative specification 225. For example, security module 320 ensures that interactions within the various data center entities and interactions between data center entities and systems external to the generated data center conform to security policies defined in data center declarative specification 225. Security policies may specify which data center entities can be accessed by external systems, which external systems can be accessed by particular data center entities, whether services can interact with other services, whether service groups can interact with other service groups, whether services can access particular functions or APIs (application programming interfaces) supported by the cloud platform, etc. External systems may be identified using IP addresses or domain names.

[0042] The user account processing module 330 creates user accounts in the cloud platform where the data center is created. These user accounts are used for various purposes such as debugging, simulating the data center, interacting with team members, etc.

[0043] The metadata store 340 stores various transformed metadata representations of the data center generated by the compilation module 230. The transformed metadata representations may be used to perform rollbacks to previous versions if a problem occurs with the current version of the data center. The transformed metadata representations may also be used for validation, auditing, governance, etc. at various stages of the transformation process.

[0044] The provisioning module 350 creates instructions for provisioning resources on a target cloud system and executes them to deploy the data center. In one embodiment, the provisioning system creates a pipeline for execution on a cloud platform. The pipeline includes stages containing instructions for provisioning various services on the cloud platform or deploying applications to create various services according to a declarative specification describing the data center.

[0045] 4 illustrates an example of a declarative specification of a data center, according to one embodiment. The declarative specification 410 includes multiple data center entities. A data center entity is an instance of a data center entity type, and there can be multiple instances of each data center entity type. Examples of data center entities include a data center, a service group, a service, a team, an environment, and a schema.

[0046] The declarative specification 410 includes definitions of various types of datacenter entities, including service groups, services, teams, environments, and schemas. The declarative specification includes one or more instances of a datacenter. The following describes various types of datacenter entities and examples thereof. The examples are illustrative and show some of the attributes of the datacenter entities. Other embodiments may include different attributes, and attributes with the same functionality may be given different names than those shown herein. In one embodiment, the declarative specification is specified using hierarchical objects, such as Javascript object notation (JSON), that conform to a predefined schema.

[0047] According to one embodiment, service group 420 represents a set of capabilities, features, and services provided by one or more computing systems that can be independently constructed and provided. A service group may also be referred to as a logical service group, functional unit, or bounded context. A service group 420 may be viewed as a set of services for a comprehensive set of technical use-case functionality provided by one or more computing systems. Service group 420 enforces security boundaries. Service group 420 defines the scope of modifications. Thus, any changes to entities, such as capabilities, features, or services, provided by one or more computing systems within service group 420 may be propagated as needed or preferred to entities within service group 420, but not to entities existing outside the bounded definition of service group 420. A data center may contain multiple service groups 420. A service group definition specifies attributes such as a name, description, identifier, schema version, and set of service instances. An example of a service group is a blockchain service group that includes a set of services used to provide blockchain functionality. Similarly, a security service group provides security features. A user interface service group provides functionality for a specific user interface feature. The Shared Documents service group provides the ability to share documents across users. There may be multiple other service groups as well.

[0048] Service groups support specification reusability so that tenants or users interested in developing a data center can have a library of service groups that they can easily use. The boundaries of services in a service group are based on security and network concerns, among other things. A service group is associated with a protocol for performing interactions with the service group. In one embodiment, a service group provides a collection of APIs (application programming interfaces) and services that implement those APIs. Furthermore, service groups are substrate agnostic. A service group provides a blast radius for services within the service group so that any failure of a service within the service group is limited to the impact on the services within the service group and minimizes impact outside the service group.

[0049] The following is an example of a service group specification: A service group specifies various attributes that represent metadata for the service group and includes the set of services within the service group. There may be other types of metadata defined for a service group that are not shown here.

number

[0050] As shown in the example above, a service group may define a set of clusters. A cluster represents a set of computing nodes, such as a set of servers, a set of virtual machines, or a set of containers (such as KUBERNETES containers). A physical server may run multiple containers, each with its own share of file systems, CPUs, memory, process space, etc.

[0051] A service group specifies a set of services. A service group may specify clusters for services, such that a data center deployed on a cloud platform runs a cluster of computing nodes, and maps services to clusters based on the specified mappings, if included in the declarative specification. For example, in the example service group above, service instance serviceinstance0002 is specified to run on cluster instance cluster1.

[0052] A service group may define security groups, each of which defines a set of services that are allowed to interact with each other. Services outside the security group are required to pass additional authentication to communicate with services within the security group. Alternatively, services within the security group may use one protocol to interact with each other, and services outside the security group may use a different protocol that requires extended authentication to interact with services within the security group. Thus, a security group defines policies that determine how services can interact with each other. A security policy may define one or more environments for which the security policy is applicable. For example, a security policy, policy1, may apply to a specific environment, env1 (e.g., a production environment), and another security policy, policy2, may apply to another environment, env2 (e.g., a development environment). Security policies may be defined for a service group type or for a specific service type.

[0053] In one embodiment, a security policy defines expressions for filtering service groups based on various attributes such that the security policy is applicable to a set of filtered service groups. For example, a security policy may specify a list of Internet Protocol (IP) addresses that are whitelisted for the set of service groups identified by the filtered set, thereby allowing those computing systems access to the service groups or a particular set of services within the service groups.

[0054] In one embodiment, a security policy may be defined for a service group, a set of source services, and a set of destination services. The source service for a particular service defines the services outside of the security group that this particular service can connect to. The destination service for a particular service defines the services outside of the security group that this particular service needs to connect to. During provisioning and deployment, the data center generation module generates instructions for the cloud platform that implement the particular network policy using cloud platform specific features and network capabilities, such that the network policy implements the security policy defined in the declarative specification.

[0055] A data center entity called a cell represents a set of services that interact with each other in a vertical fashion and can be scaled by additional instances or copies of the cell, i.e., copies of the set of services. Creating multiple instances of a cell allows the system to scale the set of services that interact with each other. A data center instance may contain one or more cells. Each cell may contain one or more services. A data center may contain service groups or instances of cells.

[0056] A service definition specifies metadata for a type of service, such as a database service or a load balancer service. The metadata describes various attributes of the service, including the service's name, service description, the location of the service's documentation, any subservices associated with the service, the service owner, the team associated with the service, the service's build dependencies, which specify other services on which this service depends when built, the service's start dependencies, which specify other services that should run when this particular service starts, authorized clients, the domain name server (DNS) name associated with the service, the service status, and the service's support level. The service definition also specifies a listening port attribute, which specifies the ports on which the service can listen for different communication protocols. For example, a service may listen on port p1 for the UDP protocol and port p2 for the TCP protocol. Other services in the data center can interact with the service through the ports specified by the service.

[0057] A service definition specifies an attribute outbound_access that specifies a destination endpoint, e.g., external_url, that specifies that the service requires access to a specified external uniform resource locator (URL). During deployment, the data center generation module ensures that the cloud platform implements the access policy to provide instances of this service type with the required access to the external URL.

[0058] An outbound access specification may identify one or more environment types for the service to which the outbound access is applicable. For example, outbound access for a set of endpoints S1 may apply to a particular environment env1 (e.g., a production environment), and outbound access for a set of endpoints S2 may apply to another environment env2 (e.g., a development environment).

[0059] Below is an example of a service definition.

number

[0060] The team definition 450 includes team member names and other team attributes, such as name, email, communication channel, etc. An example of a team definition is shown below. A service may be associated with one or more teams responsible for modifications made to the service. Accordingly, any modifications made to the service are approved by the team. After a service is deployed within the cloud platform, the service may be associated with a team responsible for maintaining the service. A team may be associated with a service group and, accordingly, all services in that service group. For example, the team approves any changes to a service group, e.g., any changes to a service that is part of the service group. A team may be associated with a datacenter and, accordingly, all service groups within the datacenter. Team association defined at the datacenter level provides a default team for all service groups within the datacenter and further provides a default team for all services within the service group.

[0061] According to one embodiment, a team association specified at the function level overrides a team association provided at the datacenter level. Similarly, a team association specified at the service level overrides defaults that may be provided by team associations specified at the service group or datacenter level. The team can determine how specific actions are taken for datacenter entities associated with the team. The team association also generates a final metadata representation of the datacenter for the cloud platform by the compiler and determines the number of accounts on the cloud platform to be created for provisioning and deploying the datacenter on the cloud platform. The datacenter creation module 210 creates one or more user accounts in the cloud platform and provides team members with access to the user accounts. Thus, team members can perform specific actions associated with the datacenter entities associated with their team, such as making or approving structural changes to or maintenance of the datacenter entities as they are deployed, including debugging and testing issues that may be identified for the datacenter entities.

[0062] Conventional techniques associate the same team with a datacenter throughout the design process, thereby resulting in an organizational structure that influences the design of the datacenter and service groups, as stated by Conwoy's Law. Conwoy's Law states that an organization that designs a system is constrained to produce designs that are copies of the organization's communication structure. Embodiments decouple team definitions from the configurations that define datacenter entities, thereby reducing the influence that teams have on the design and architecture of datacenter entities.

number

[0063] The environment definition 460 defines the type of system environment presented by the data center, e.g., development environment, staging environment, test environment, or production environment. The schema definition 470 defines a schema that defines the syntax of specific data center entity definitions. The schema definition 470 is used to validate various data center entity definitions. The data center generation module determines the data center's security policies in the cloud platform-specific metadata representation 235 based on the environment. For example, a particular set of security policies may be applicable to environment env1, and a different set of security policies may be applicable to environment env2. For example, a security policy may provide much more restricted access in a production environment compared to a development environment. A security policy may also define the length of time a security token is allowed to exist for a particular purpose. For example, long access tokens (e.g., week-long access tokens) may be allowed in a development environment, while access tokens with a much shorter lifespan (e.g., a few hours) are used in a production environment. An access token may enable a user or service to access specific cloud platform resources.

[0064] The datacenter definition 420 specifies the attributes and components of a datacenter instance. A declarative specification may specify multiple datacenter instances. The datacenter definition 420 specifies attributes including a name, description, type of environment, set of service groups, team, domain name servers for the datacenter, etc. The datacenter definition may specify a schema definition, and any metadata representation generated from the datacenter definition is validated against the specified schema definition. A datacenter includes a set of core services and capabilities that enable other services to function within the datacenter. A datacenter instance may be deployed on a specific cloud platform and associated with a specific development type, e.g., development, test, staging, production, etc.

[0065] Below is a definition of a datacenter instance: A datacenter instance definition includes a list of service groups included in the datacenter instance, as well as other attributes including the datacenter's environment, a datacenter identifier, a name, a region representing a geographic region, one or more teams associated with the datacenter, and a schema version.

number

[0066] FIG. 5 illustrates several exemplary data centers created on a cloud platform based on a declarative specification according to one embodiment. Data center 510 may be created based on the declarative specification processed by data center creation module 210. As shown in FIG. 5, multiple data centers may be configured within cloud platform 120. Each data center 510 may correspond to a tenant 115 of multi-tenant system 110. A tenant 115 may create one or more data centers 510. Alternatively, data center 510 may be created by any computing system. Each data center includes one or more service groups. For example, data center 510a includes service groups 520a and 520b, and data center 510b includes service group 520c. A data center may include multiple instances of a particular type of service group. Each service group includes a set of services. For example, service group 520a includes services 530a and 530b, service group 520b includes services 530a, 530b, and 530c, and service group 520c includes services 530e, 530f, and 530g. A service group may include multiple instances of services of the same service type. Overall Process

[0067] 7 is a flowchart illustrating a process for creating a data center on a cloud platform based on a declarative specification, according to one embodiment. Other embodiments may perform the steps of FIG. 7 in a different order. Additionally, other embodiments may include different and / or additional steps than those described herein.

[0068] The data center generation module 210 receives 610 a cloud platform-independent declarative specification of a data center. The cloud platform-independent declarative specification may be for a tenant of a multi-tenant system or for any other computing system, e.g., an online system. The cloud platform-independent declarative specification is specified using a cloud platform infrastructure language. The cloud platform-independent declarative specification of the data center is configured to generate a data center on any of multiple cloud platforms.

[0069] The data center creation module 210 receives 620 information identifying a target cloud platform for creating the data center based on the cloud-platform-independent declarative specification. The target cloud platform can be any of multiple cloud platforms, such as AWS, AZURE, or GCP. The data center creation module 210 further receives information for connecting with the target cloud platform, such as credentials for creating a connection with the target cloud platform. The cloud platform may also be referred to as a cloud computing platform.

[0070] The data center generation module 210 compiles the cloud platform-agnostic declarative specification to generate a cloud platform-specific data center representation for creating a data center on a target cloud platform (630). For example, the cloud platform-specific data center representation may refer to user accounts, network addresses, etc. specific to the target cloud computing platform.

[0071] The data center creation module 210 sends the platform-specific data center representation along with instructions for deploying the data center on the target cloud computing platform (640). The target cloud computing platform executes the instructions to configure the target cloud computing platform's computing resources to create a data center according to the platform-specific data center representation (650). The data center creation module 210 provides users with access to the computing resources of the data center configured by the cloud computing platform (660). For example, if a data center is created for a tenant in a multi-tenant system, users associated with the tenant are provided with access to the data center.

[0072] 7 is a block diagram illustrating the generation of a data center on a cloud platform based on a declarative specification, according to one embodiment. The data center generation module 210 receives as input a cloud platform-independent declarative specification 710 (represented as declarative specification 225 in FIG. 2 ). The cloud platform-independent declarative specification 710 may be a version of a declarative specification that is incrementally modified by a user. The data center generation module 210 processes a specific version of the cloud platform-independent declarative specification 710. Because the cloud platform-independent declarative specification 710 is not specified for any particular target cloud platform, the data center generation module 210 can configure a data center on any target cloud platform based on the cloud platform-independent declarative specification 710.

[0073] The data center generation module 210 processes the cloud platform agnostic declarative specification 710 to generate a cloud platform agnostic detailed metadata representation 720 for the data center. The cloud platform agnostic detailed metadata representation 720 defines details of each instance of a data center entity specified in the cloud platform agnostic declarative specification 710. The data center generation module 210 creates a unique identifier for the data center entity instance, e.g., a service instance.

[0074] In one embodiment, the cloud platform-agnostic detailed metadata representation 720 includes an array of instances of a data center entity type, such as an array of service group instances of a particular service group type. Each service group instance includes an array of service instances. A service instance may further include details of a team of users who are enabled to perform specific actions associated with the service instance. The team details are used during provisioning and deployment by the data center creation module 210, for example, to create user accounts for the service instance and enable team members to access the user accounts.

[0075] The cloud platform-independent detailed metadata representation 720 includes attributes of each instance of a data center entity. Thus, the description of each instance of a data center entity is expanded to include all details. As a result, the cloud platform-independent detailed metadata representation 720 of a data center may be significantly larger than the cloud platform-independent declarative specification 710. For example, the cloud platform-independent declarative specification 710 may be a specification of several thousand lines, while the cloud platform-independent detailed data center representation 320 may be millions of lines of generated code. As a result, the data center generation module 210 maintains the cloud platform-independent detailed metadata representation 720 as immutable, i.e., once the representation is finalized, no modifications to the representation are performed. For example, if any updates, deletions, or additions of data center entities need to be performed, they are performed against the cloud platform-independent declarative specification 710.

[0076] The data center generation module 210 receives a target cloud platform on which the data center is expected to be provisioned and deployed and generates a cloud platform-specific detailed metadata representation 730 of the data center. For example, the data center generation module 210 interacts with the target cloud platform to generate specific entities (or resources), such as user accounts, virtual private clouds (VPCs) and subnets on the VPCs, and networking resources such as various connections between entities within the cloud platform. The data center generation module 210 receives resource identifiers of resources created in the target cloud platform, such as user account names and VPC IDs, and incorporates these into the cloud platform-independent detailed metadata representation 720 to obtain a cloud platform-specific metadata representation 730 of the data center. In one embodiment, the data center generation module 210 creates one unique user account on the cloud platform for each team for a given combination of service group and service. The user account is used by the team to perform interactions with that particular service for that service group, such as debugging, receiving alerts, etc.

[0077] The data center generation module 210 deploys the cloud platform-specific metadata representation 730 on the particular target cloud platform for which the representation was generated. The data center generation module 210 may use the generated metadata representation to perform various validations, including policy validation, format validation, etc.

[0078] The cloud platform independent declarative specification 710 is referred to as a declared data center representation, the cloud platform independent detailed metadata representation 720 is referred to as a derived metadata representation of the data center, and the cloud platform specific metadata representation 730 is referred to as a hydrated metadata representation of the data center.

[0079] The target cloud platform processes the cloud platform-specific detailed metadata representation 730 to create (or configure) a data center. The data center generation module 210 generates instructions for deploying the cloud platform-specific detailed metadata representation 730 on the target cloud platform. The instructions may be represented as a pipeline containing stages, with each stage performing a specific operation related to deploying the data center. For example, the pipeline may represent instructions for a continuous delivery platform such as SPINNAKER.

[0080] The target cloud platform may perform several steps to process the cloud platform-specific detailed metadata representation 730. For example, the cloud platform-agnostic declarative specification may specify allowed interactions between services. These allowed interactions are specified in the cloud platform-specific detailed metadata representation 730 and implemented as network policies of the cloud platform. The cloud platform may further create security groups that implement the network strategies for implementing the data center according to the declarative specification.

[0081] The cloud-platform-agnostic declarative specification defines dependencies between services. For example, start dependencies for each service list all services that should run when a particular service is started. The compilation module 230 generates a cloud-platform-specific detailed metadata representation for the data center that includes information describing these dependencies, so that the instructions for deploying the services ensure that the cloud platform starts the services in the order specified by the dependencies, such that, for each service, those services are required to be started before the service that runs when the service is started. Thus, the dependencies between services represent a dependency graph, and start the execution of the services in an order determined based on the dependency graph, so that if service A depends on service B, service B is started before service A is started.

[0082] The data center generation module 230 creates trust relationships between user accounts that allow services to access other services over secure communication channels. These trust relationships are generated based on a declarative specification, for example, using substrate-specific instructions generated based on outbound access attributes specified for the services. The data center generation module 230 sends instructions to the cloud platform to create network policies based on cloud platform-specific mechanisms that control interaction and access across service groups and services, as specified by constructs in the declarative specification, such as outbound access, security groups, and security policies.

[0083] The data center generation module 230 generates instructions, for example, a pipeline for deploying a service that specifies stages that determine the order in which services are started in the deployment.

[0084] 8 is a flowchart illustrating a process for deploying a data center on a cloud platform, according to one embodiment. The data center generation module 210 accesses 810 a cloud platform-specific detailed metadata representation 730 of the data center. The cloud platform-specific detailed metadata representation 730 is generated from a cloud platform-independent declarative specification 710, for example, as shown in FIG. 7.

[0085] The data center generation module 210 configures (820) a master pipeline for data center entities of the data center. The master pipeline includes multiple pipelines, such as a provisioning pipeline for provisioning resources in a target cloud platform and a deployment pipeline for deploying data center entities using the provisioned resources. Each pipeline includes a series of stages, each representing one or more actions that need to be performed by the target cloud platform for data center provisioning and deployment. The data center generation module 210 generates (830) detailed pipelines for generating specific services as specified by the cloud platform-specific detailed metadata representation 730.

[0086] In one embodiment, a detailed pipeline is generated from a pipeline template that includes variables. The pipeline template is converted into a pipeline by providing specific values ​​for the variables to the pipeline. The process of generating a pipeline from a template is called hydrating the pipeline template. The pipeline template includes template expressions that are used as placeholders for actual values ​​used in deployment. For example, template expressions may be replaced by target-specific parameter values ​​or expressions. Multiple pipeline instances may be generated by hydrating a pipeline template for different targets. Template variables represent parameters that may be replaced with specific values ​​for a given target to generate a pipeline instance specific to that target. For example, the template variable "account_id" may be replaced during hydration with the actual value of "account_id," e.g., "12345."

[0087] The template hydration module may access a data source, such as a configuration file or database, to identify actual values ​​for parameters used in templating the representation. For example, template variables may represent a set of computing systems in a cluster. The datacenter creation module 230 executes 840 the generated pipelines on the target cloud platform. For example, a provisioning pipeline may be executed first to provision resources on the cloud platform, and then a deployment pipeline may be executed to deploy applications on the provisioned resources to create a datacenter on the target computing platform.

[0088] The process for generating pipelines according to one embodiment is as follows: The data center generation module 210 generates pipelines in a hierarchical manner based on the hierarchy of data center entities in a data center. For example, a data center includes different types of data center entities, including data centers, service groups, services, etc. A data center entity may include one or more child data center entities. For example, a data center includes one or more service groups as child data center entities. A service group includes one or more services as child data center entities. Thus, the data center generation module 210 starts with a data center entity at a level in the hierarchy and generates pipelines for data center entities below that level. For example, the data center generation module 210 starts with a data center and generates pipelines for service groups within the data center. For each service group, the data center generation module 210 generates pipelines for the services within the service group.

[0089] Generation of a pipeline for an input data center entity having a set of child data center entities is as follows: The data center generation module 210 identifies a set of child data center entities for the input data center entity. The data center generation module 210 generates a dependency graph for the set of child data center entities. For example, if the child data center entity represents a service, the data center generation module 210 identifies dependencies specified in the cloud platform-specific detailed metadata representation 730, which is obtained from the cloud platform-independent declarative specification 710. The data center generation module 210 analyzes the dependency graph, for example, to check for cycles in the dependency graph. If the data center generation module 210 identifies a cycle in the dependency graph, the data center generation module 210 reports an error. If there is no cycle in the dependency graph, the data center generation module 210 further processes the dependency graph by performing a topological sort of the dependency graph. The data center generation module 210 determines the order of the child data center entities based on the topological sort. The data center generation module 210 orders the child data center entities based on the sort order of the dependency graph. The data center generation module 210 creates a stage in a pipeline for each child data center entity arranged in the order determined for the child data center entities. The stage may be for provisioning resources for the child data center entity while generating a provisioning pipeline, or the stage may be for deploying the child data center entity if a deployment pipeline is being generated.

[0090] The process for executing a pipeline according to one embodiment is as follows: The data center creation module 210 receives a request to deploy a data center in a target cloud platform. The data center creation module 210 executes an aggregation pipeline for each data center entity in the data center. The aggregation pipeline includes pipelines for services in service groups. The pipeline is executed by executing all stages of the pipeline for each service in each service group. The provisioning pipeline executes, which results in the provisioning of resources for the service, and the deployment pipeline results in the deployment of the service in the target cloud platform. Modifying a Data Center Deployed on a Cloud Platform

[0091] Embodiments perform modifications of a data center deployed within a cloud platform with minimal downtime. The data center modifications may be performed on any data center entity, such as a service group being modified, a service being modified, a team being modified, etc. The data center modifications may include adding a new service, decommissioning an existing service, modifying the configuration of an existing service, etc.

[0092] Modifications to an existing data center deployed within a cloud platform may be performed for several reasons. For example, a tenant in a multi-tenant system may build out a data center incrementally. The data center initially deployed may be small with a minimal set of service groups and services. Once the data center is operational and in use for a period of time, the data center may be expanded with additional service groups or services. This process may continue over time to iteratively build out the data center.

[0093] Modifications to an existing data center may be performed due to changing needs of the enterprise or tenant using the data center. For example, a tenant may introduce a new feature that requires the installation of a new service. There may also be changes to the load, which may be seasonal or permanent. Because the use of a cloud platform allows for elasticity in the resources used, a tenant or enterprise may modify the data center based on the change in load by increasing or decreasing the cloud computing resources used.

[0094] Modifications to an existing data center may be driven by changes in tenant or corporate policy. For example, a tenant may decide to tighten security and therefore implement a new security policy. A tenant may modify network policies to restrict or modify access to various services. A tenant may restrict or modify outbound access to certain services based on security concerns or organizational policy changes. A tenant may modify the teams responsible for various data center entities in response to organizational changes. A tenant may need to add or remove services based on monitoring service usage. For example, if utilization of a service is determined to be below a threshold for a period longer than a threshold period, a tenant may decide to remove the service or modify the service's configuration to account for the change in load.

[0095] Thus, there may be any number of reasons to modify a data center currently deployed in a cloud platform. Embodiments enable such dynamic modification to an existing data center deployed in a cloud platform while minimizing disruption to currently running services.

[0096] 9 is a block diagram illustrating the system architecture of a data center remediation module, according to one embodiment. Data center remediation module 900 includes a metadata differencing module 910, a remediation plan generation module 920, and a CRUD operations module 930. Other embodiments may have more or fewer modules, and functions shown as being performed by modules may be performed by other modules than those shown herein.

[0097] The metadata differencing module 910 determines differences between two metadata representations of a data center. In one embodiment, the metadata differencing module 910 receives a metadata representation of a data center currently deployed on a cloud platform and a metadata representation of a modified data center planned for deployment and generates a delta metadata representation representing the differences between the two metadata representations. The metadata differencing module 910 provides the delta metadata representation to a modification plan generation module to generate a modification plan for modifying the data center currently deployed on the cloud platform to the planned data center. In one embodiment, the input metadata representation is the cloud platform-specific detailed metadata representation 730, but may also be the cloud platform-independent detailed metadata representation 720 or the cloud platform-independent declarative specification 710. In one embodiment, the metadata differencing module 910 traverses the two metadata representations simultaneously in a top-down hierarchical manner, comparing the nodes of the metadata representations to determine whether there are matching nodes available at each level. If the metadata differencing module 910 determines a mismatch in the nodes of the metadata representations, the metadata differencing module 910 adds nodes to the delta metadata representation representing the differences. If there is a difference at node N1 at a particular level, the metadata difference module 910 adds the complete branch extending from the root node to node N1 in the generated delta metadata representation. The metadata difference module 910 also marks or annotates the nodes of the delta metadata representation with information characterizing the differences. Nodes in the delta metadata representation may be marked as unchanged, new, modified, or deleted.

[0098] The CRUD operations module 930 contains instructions for performing specific modifications to a data center. The operations supported by the CRUD operations module 930 are create, read, update, and delete operations. A create operation creates a data center entity within a data center. A read operation returns a representation of a data center or part of a data center. An update operation modifies an existing data center entity from a data center. A delete operation removes or decommissions a data center entity.

[0099] The modification plan generation module 920 receives a delta metadata representation of a data center that represents the differences between the metadata representation of the data center currently deployed on the cloud platform and the metadata representation of the planned data center configuration, and generates a modification plan for changing the data center currently deployed on the cloud platform to the planned data center configuration. In one embodiment, the modification plan generation module 920 uses node annotations to determine instructions added to the modification plan. Thus, the modification plan generation module 920 generates (1) instructions to add a data center entity if the node in the delta metadata representation is marked as new, (2) instructions to delete a data center entity if the node in the delta metadata representation is marked for deletion, and (3) instructions to update a data center entity if the node in the delta metadata representation is marked for update. The modification plan generation module 920 generates a plan that minimizes service interruptions as much as possible. For example, if updating data center entity D1 does not affect data center entity D2, the modification plan keeps that data center entity unmodified and running while data center entity D1 is modified.

[0100] 10A-10C illustrate the determination of a delta metadata representation of a requested change to a data center, according to one embodiment. Figure 10A shows a metadata representation 1010a of a data center currently deployed on a cloud platform. As shown in Figure 10A, data center DC includes two service groups SG1 and SG2. Service group SG1 includes two cells CELL1 and CELL2. CELL1 includes services SVCA, ..., SVCZ. CELL2 includes a service SVCB. Service group SG2 includes two services SVCA and SVCB.

[0101] Figure 10B includes a modified metadata representation 1010b of data center DC. For example, a user may construct the modified declarative specification by modifying a previous version of the declarative specification corresponding to the metadata representation of Figure 10A. In addition to the nodes of metadata representation 1010a, modified metadata representation 1010b includes the following nodes: a node for the SVCF of cell CELL2, and a new service group SG3 that includes cell CELL1 and service SVCE.

[0102] FIG. 10C shows delta metadata representation 1010c, which represents the differences between metadata representations 1010a and 1010b. Delta metadata representation 1010c includes node DC with service groups SG1 and SG3 below node DC, node CELL2 below node SG1, node SVCF below node CELL2, node SG3 below node DC, node CELL1 below node SG3, and node SVCE below node CELL1. If a node N1, such as a node for SVCF that is different in 1010b compared to 1010a, appears at a lower level, e.g., a leaf level, delta metadata representation 1010c includes the entire branch starting from root node DC and including node N1. Thus, nodes DC, SG1, and CELL2 above node SVCF are included even though they are not different in metadata representations 1010a and 1010b. In addition, delta metadata representation 1010c includes a branch below node DC that includes SG3, CELL1, and SVCE.

[0103] The metadata difference module 910 may obtain the delta metadata representation 1010c by simultaneously performing a top-down traversal of the metadata representations 1010a and 1010b. For each node that matches in the two metadata representations 1010a and 1010b, the metadata difference module 910 compares the corresponding child nodes. If there are differences in the child nodes of the node, the metadata difference module 910 determines the differences and adds the corresponding node to the delta metadata representation 1010c.

[0104] For example, the metadata difference module 910 notes that metadata representations 1010a and 1010b are identical at the root node because they both have a single node, DC. The metadata difference module 910 checks the child nodes of the root node in both metadata representations 1010a and 1010b. Metadata representation 1010b includes three nodes, SG1, SG2, and SG3, under the root node, DC, while metadata representation 1010a includes two nodes, SG1 and SG2, under the root node, DC. Therefore, there is a difference in the child nodes under the root node. The metadata difference module 910 determines the difference as node SG3 and adds node SG3 under node DC in the delta metadata representation 1010c.

[0105] Below is an example of a portion of a delta metadata representation 1010c when a data center with service groups SG1 and SG2 is modified to add a new service group SG3.

number

[0106] The following is an example of a portion of delta metadata representation 1010c when a datacenter with service group SG1 having three services SVCA, SVCB, and SVCC is modified so that service group SG1 has four services SVCA, SVCB, SVCC, and SVCD: Delta metadata representation 1010c includes a node for the new service SVCD that is being added and other metadata related to the service SVCD, such as metadata for the team for the service SVCD.

number

[0107] 11 is a flowchart illustrating a process for modifying a data center deployed on a cloud platform, according to one embodiment. A data center modification module 900 receives 110 a modified metadata representation of the data center, e.g., a modified version of a previously created cloud platform-independent declarative specification of the data center. A compilation module 1210 compiles the cloud platform-independent declarative specification to generate a cloud platform-specific detailed data center representation. The data center modification module 900 accesses 1130 the cloud platform-specific detailed data center representation of a data center currently deployed on the cloud platform.

[0108] The data center remediation module 900 determines 1140 the delta metadata representation as the differences between the two cloud platform-specific detailed data center representations. In one embodiment, the data center metadata representation is received as a nested object structure, defined, for example, as a JSON object. The data center remediation module 900 processes the received structure as a graph. Each data center entity is represented as a JSON object. Particular attributes of the JSON object represent metadata attributes of the data center entity. Some attributes may represent a set of objects, for example, a dictionary representation corresponding to a child object of the JSON object. The metadata differencing module 910 determines the delta metadata by comparing the metadata attributes of each nested object representing the data center entity and recursively running a differencing process for each child object.

[0109] The data center modification module 900 generates 1150 instructions for modifying the data center according to the delta metadata representation. If the delta metadata representation 1010c includes a node marked as a new data center entity, the data center modification module 900 generates instructions to create the new data center entity. If the delta metadata representation includes a node marked as a data center entity to be deleted, the data center modification module 900 generates instructions to delete the existing data center entity. If the delta metadata representation includes a node marked as a data center entity to be updated, the data center modification module 900 generates instructions to update the existing data center entity. In one embodiment, the instructions include a pipeline for execution on a cloud platform.

[0110] The data center modification module 900 submits the generated instructions for execution on the cloud platform, which modify the data center to correspond to the modified version of the cloud platform-independent declarative specification. The data center modification module 900 provides users with access to any new services added to the data center as a result of the modifications.

[0111] Although the process shown in FIG. 11 determines the differences between two cloud platform-specific detailed data center representations of a data center, this process may be performed by determining the differences between any other metadata representations of the data center, for example, a cloud platform-independent detailed data center representation of the data center.

[0112] If the delta metadata representation includes a node marked as a data center entity to be updated, the data center modification module 900 determines the changes to be performed on the data center entity and generates instructions accordingly. For example, if the update operation modifies a security policy of a service, the data center modification module 900 generates appropriate instructions to modify the security policy. If the update operation modifies a network policy of a service, the data center modification module 900 generates appropriate instructions to modify the security policy.

[0113] If the SVCA metadata representation includes a new relationship between two services, SVCA and SVCB, the data center modification module 900 modifies the security group definition to enable interaction between the SVCA and SVCB and generates instructions to reapply the security group definition.

[0114] If the delta metadata representation specifies a change to the port of the service from P1 to P2, the data center modification module 900 generates instructions to remove the network policy and trust relationship based on port P1 because port P1 is no longer functioning. The data center modification module 900 generates instructions to add the network policy and trust relationship based on port P2 as specified in the delta metadata representation.

[0115] If the delta metadata representation specifies that outbound access to a service is to be changed from URL1 to URL2, the data center modification module 900 generates instructions to remove access to URL1 and add access to URL2 for the service.

[0116] The data center modification module 900 generates instructions to minimize service outages at the data center and minimize security risks to the data center when making updates. For example, if outbound or inbound access is modified, the generated instructions first remove unnecessary access and then add new access, thereby ensuring that the opportunity for unauthorized access is minimized. In one embodiment, the data center modification module 900 hierarchically traverses the data center representation to determine the minimum number of services that need to be shut down and restarted to perform the update operation. If no services need to be modified to perform the update, the data center modification module 900 leaves the services without any modifications.

[0117] The data center modification module 900 analyzes the service dependencies in the delta metadata representation to determine the order in which services are started or destroyed depending on the type of operation that needs to be performed on the data center entities.

[0118] In one embodiment, a data center entity specifies start dependency information in a declarative specification, e.g., a set of other data center entities on which the data center entity depends. If data center entity E1 has a start dependency on data center entity E2, then data center entity E2 must be started before data center entity E1 is started. The data center modification module 900 analyzes the start dependencies of all data center entities in the delta metadata representation. The data center modification module 900 builds a dependency graph based on the start dependency information specified in the data center entities in the delta metadata representation. The data center modification module 900 generates a modification plan based on the dependency graph. In one embodiment, the data center modification module 900 generates a pipeline for starting the data center entities in an order determined based on the dependency graph.

[0119] If the delta metadata representation includes a data center entity E1 that needs to be created in the data center, the data center modification module 900 generates a modification plan to start the set S1 of data center entities on which the data center entity E1 depends in an order determined based on the dependency graph, such that the data centers in the set S1 are started before the data center entity E1. The data center entities in the set S1 are also started in an order such that if a data center entity Ex depends on a data center entity Ey, then the data center entity Ey is started before the data center entity Ex.

[0120] If the delta metadata representation includes a data center entity E1 that needs to be deleted or disposed of in the data center, the data center modification module 900 generates a modification plan to destroy the set S1 of data center entities on which the data center entity E1 depends in an order determined based on the dependency graph, such that the data centers in the set S1 are destroyed after the data center entity E1. The data center entities in the set S1 are also destroyed in an order such that if a data center entity Ex depends on a data center entity Ey, the data center entity Ey is destroyed after the data center entity Ex. A data center entity is destroyed when the cloud platform reclaims the computing resources used by the data center entity, for example, for use for another purpose. The cloud platform also removes access to the data center entity. If the data center entity is a service, the cloud platform destroys the service by removing access to the service and stopping the processes that execute the instructions of the service. Computer Architecture

[0121] 12 is a high-level block diagram illustrating a functional view of a typical computer system for use as one of the entities illustrated in environment 100 of FIG. 1, according to one embodiment. Illustrated is at least one processor 1202 coupled to a chipset 1204. Also coupled to chipset 1204 are memory 1206, a storage device 1208, a keyboard 1210, a graphics adapter 1212, a pointing device 1214, and a network adapter 1216. A display 1218 is coupled to graphics adapter 1212. In one embodiment, the functionality of chipset 1204 is provided by memory controller hub 1220 and I / O controller hub 1222. In another embodiment, memory 1206 is coupled directly to processor 1202 instead of chipset 1204.

[0122] The storage device 1208 is a non-transitory computer-readable storage medium such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. The memory 1206 holds instructions and data used by the processor 1202. The pointing device 1214 may be a mouse, a trackball, or other type of pointing device and is used in combination with the keyboard 1210 to input data into the computer system 200. The graphics adapter 1212 displays images and other information on the display 1218. The network adapter 1216 couples the computer system 1200 to a network.

[0123] As is known in the art, computer 1200 may have different and / or other components than those depicted in Figure 12. Additionally, computer 1200 may lack certain illustrated components. For example, a computer system 1200 operating as multi-tenant system 110 may lack keyboard 1210 and pointing device 1214. Furthermore, storage device 1208 may be local and / or remote from computer 1200 (e.g., embodied in a storage area network (SAN)).

[0124] The computer 1200 is adapted to execute computer modules to provide the functions described herein. As used herein, the term "module" refers to computer program instructions and other logic for providing a particular function. A module may be implemented in hardware, firmware, and / or software. A module may include one or more processes and / or may be provided by only a portion of a process. A module is typically stored on the storage device 1208, loaded into the memory 1206, and executed by the processor 1202.

[0125] 1 may vary depending on the embodiment and the processing power used by the entities. For example, client device 105 may be a mobile phone with limited processing power, a small display 1218, and may lack a pointing device 1214. In contrast, multi-tenant system 110 and cloud platform 120 may include multiple blade servers that cooperate to provide the functionality described herein. Additional Considerations

[0126] The particular naming of components, term capitalization, attributes, data structures, or other programming or structural aspects are not required or important, and mechanisms for implementing the described embodiments may have different names, formats, or protocols. Furthermore, the systems may be implemented through a combination of hardware and software as described, or entirely with hardware elements. Also, the particular division of functionality between various system components described herein is merely exemplary and not required; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

[0127] Some portions of the above description are presented in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, will be understood to be implemented by computer programs. Further, it has proven convenient at times to refer to arrangements of these operations as modules or by functional names, without loss of generality.

[0128] As is clear from the above description, unless otherwise stated, throughout this specification, descriptions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," and the like will be understood to refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities in the computer system memory or registers, or other such information storage, transmission, or display device.

[0129] Certain embodiments described herein include process steps and instructions that are written in the form of an algorithm. It should be noted that the process steps and instructions of the embodiments may be embodied in software, firmware, or hardware, and when embodied in software, may reside on and operate from different platforms that may be downloaded and used by a real-time network operating system.

[0130] The described embodiments also relate to apparatus for performing the operations herein. The apparatus may be specially constructed for the required purposes, or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored on a computer-readable medium accessible by the computer. Such computer programs may be stored on any type of non-transitory computer-readable storage medium, such as, but not limited to, a floppy disk, optical disk, CD-ROM, magneto-optical disk, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical card, application-specific integrated circuit (ASIC), or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus. Furthermore, the computers referred to herein may include a single processor or may be architectures employing multiple processor designs to increase computing power.

[0131] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may be convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems, along with equivalent variations, will be apparent to those skilled in the art. Additionally, the present embodiments are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the teachings of the embodiments as described herein.

[0132] Embodiments are well suited to a wide variety of computer network systems across numerous topologies, including the configuration and management of large networks including storage devices and computers communicatively coupled to dissimilar computers and storage devices over networks such as the Internet.

[0133] Finally, it should be noted that the language used herein has been chosen primarily for readability and educational purposes, and not to delineate or delimit inventive subject matter. Accordingly, the disclosure of embodiments is intended to be illustrative, but not limiting.

Claims

1. 1. A computer-implemented method for modifying a data center created in a cloud platform, comprising: receiving an original declarative specification of a data center, the data center representing a set of computing resources used by a set of users associated with tenants of a multi-tenant system, the original declarative specification being specified using a cloud platform infrastructure language and configured to generate an original version of the data center on any of a plurality of cloud platforms; deploying the original version of the data center that conforms to the original declarative specification on a target cloud platform; receiving a modified declarative specification of the data center; generating a delta metadata representation representing differences between the original version of the data center based on the original declarative specification and a modified version of the data center based on the modified declarative specification; generating a modification plan for the data center based on the delta metadata representation, the modification plan including instructions for modifying the data center on the target cloud platform to obtain the modified version of the data center; sending the generated instructions to the target cloud platform for execution, wherein the target cloud platform executes the generated instructions to obtain the modified version of the data center from the original version of the data center; providing a set of users associated with tenants of the multi-tenant system with access to computing resources of the modified version of the data center deployed on the target cloud platform.

2. The revised plan is: Creating a new Data Center entity, Deleting a data center entity, or The computer-implemented method of claim 1 , further comprising instructions for one or more of updating data center entities.

3. and further comprising compiling the cloud platform independent declarative specification to generate a cloud platform specific representation of the data center, the compiling comprising: generating a first version of the cloud platform independent detailed metadata representation of the data center from the original declarative specification; and generating a second version of the cloud platform-independent detailed metadata representation of the data center from the modified declarative specification.

4. generating a platform-specific detailed metadata representation for the target cloud platform based on the first version of the cloud platform-independent detailed metadata representation; The computer-implemented method of claim 3 , further comprising: deploying the data center on the target cloud platform based on the platform-specific detailed metadata representation.

5. 5. The computer-implemented method of claim 4, wherein the delta metadata representation represents differences between the first version of the cloud platform-independent detailed metadata representation and the second version of the cloud platform-independent detailed metadata representation.

6. 2. The computer-implemented method of claim 1, wherein the cloud platform-independent declarative specification includes a definition of one or more data center instances, each data center instance including one or more service groups, each service group including a set of services.

7. 2. The computer-implemented method of claim 1, wherein the generated instructions include one or more pipelines, each pipeline including a series of stages, each stage performing one or more actions to create the datacenter on the cloud platform.

8. 2. The computer-implemented method of claim 1, wherein generating the remediation plan comprises determining a minimum set of services that need to be restarted to remediate the data center; and generating instructions that limit the restart operations to the minimum set of services.

9. The delta metadata representation includes new data center entities that are added to the data center, and the computer-implemented method includes: determining a set of data center entities with which the data center entity has an initiation dependency; The computer-implemented method of claim 1 , wherein the remediation plan includes instructions to start the data center entities of the set before starting the data center entity.

10. The delta metadata representation includes data center entities to be deleted from the data center, and the computer-implemented method includes: determining a set of data center entities with which the data center entity has an initiation dependency; The computer-implemented method of claim 1 , wherein the modification plan includes instructions to remove the data center entity before the data center entity from the set.

11. 2. The computer-implemented method of claim 1, wherein the delta metadata representation includes a service at the data center to be updated to have a second outbound access instead of a first outbound access, the first outbound access and the second outbound access each specifying a uniform resource locator (URL), and the remediation plan includes instructions to update a network policy in the target cloud platform to enable the service to access the URL of the second outbound access and to disable the service from accessing the URL of the first outbound access.

12. 2. The computer-implemented method of claim 1, wherein the delta metadata representation includes a first service adding access to a second service, and the remediation plan includes instructions to update network policies in the target cloud platform to enable the second service to interact with the first service.

13. A non-transitory computer readable storage medium for storing instructions that, when executed by a computer processor, cause the computer processor to perform the computer-implemented method of any one of claims 1 to 12.

14. 1. A computer system comprising: A computer processor; 1. A non-transitory computer-readable storage medium for storing instructions that, when executed by a computer processor, cause the computer processor to perform steps for configuring a data center within a cloud platform, the steps comprising: receiving an original declarative specification of a data center, the data center representing a set of computing resources used by a set of users associated with tenants of a multi-tenant system, the original declarative specification being specified using a cloud platform infrastructure language and configured to generate an original version of the data center on any of a plurality of cloud platforms; deploying the original version of the data center that conforms to the original declarative specification on a target cloud platform; receiving a modified declarative specification of the data center; generating a delta metadata representation representing differences between the original version of the data center based on the original declarative specification and a modified version of the data center based on the modified declarative specification; generating a modification plan for the data center based on the delta metadata representation, the modification plan including instructions for modifying the data center on the target cloud platform to obtain the modified version of the data center; sending the generated instructions to the target cloud platform for execution, wherein the target cloud platform executes the generated instructions to obtain the modified version of the data center from the original version of the data center; providing a set of users associated with tenants of the multi-tenant system with access to computing resources of the modified version of the data center deployed on the target cloud platform.

15. and further comprising compiling the cloud platform independent declarative specification to generate a cloud platform specific representation of the data center, the compiling comprising: generating a first version of the cloud platform independent detailed metadata representation of the data center from the original declarative specification; and generating a second version of the cloud platform-independent detailed metadata representation of the data center from the modified declarative specification.

16. generating a platform-specific detailed metadata representation for the target cloud platform based on the first version of the cloud platform-independent detailed metadata representation; 16. The computer-implemented method of claim 15, further comprising: deploying the data center on the target cloud platform based on the platform-specific detailed metadata representation.

17. 17. The computer-implemented method of claim 15, wherein the delta metadata representation represents differences between the first version of the cloud platform-independent detailed metadata representation and the second version of the cloud platform-independent detailed metadata representation.

18. 18. The computer-implemented method of any one of claims 1-2 and 15-17, wherein the cloud platform-independent declarative specification includes a definition of one or more data center instances, each data center instance including one or more service groups, each service group including a set of services.

19. 19. The computer-implemented method of any one of claims 1-2 and 15-18, wherein the generated instructions include one or more pipelines, each pipeline including a series of stages, each stage performing one or more actions to create the data center on the cloud platform.

20. 20. The computer-implemented method of claim 1, wherein generating the modification plan includes determining a minimum set of services that need to be restarted to modify the data center, and generating instructions that limit the restart operations to the minimum set of services.

21. The delta metadata representation includes new data center entities that are added to the data center, and the computer-implemented method includes: determining a set of data center entities with which the data center entity has an initiation dependency; The computer-implemented method of any of claims 1-2, 15-20, wherein the correction plan includes instructions to start the data center entities of the set before starting the data center entity.

22. The delta metadata representation includes new data center entities to be removed from the data center, and the computer-implemented method includes: determining a set of data center entities with which the data center entity has an initiation dependency; The computer-implemented method of any one of claims 1 to 2, 15 to 21, wherein the modification plan includes instructions to remove the data center entity before the data center entity from the set.

23. 23. The computer-implemented method of claim 1, wherein the delta metadata representation includes a service of the data center to be updated to have a second outbound access instead of a first outbound access, the first outbound access and the second outbound access each specifying a uniform resource locator (URL), and the remediation plan includes instructions to update a network policy in the target cloud platform to enable the service to access the URL of the second outbound access and to disable the service from accessing the URL of the first outbound access.

24. 24. The computer-implemented method of claim 1, wherein the delta metadata representation includes a first service adding access to a second service, and the remediation plan includes instructions to update network policies in the target cloud platform to enable the second service to interact with the first service.

Images