Multi-substrate fault-tolerant continuous delivery of data center builds on cloud computing platforms

Abstract

A computing system, e.g., a multi-tenant system, deploys software artifacts to a datacenter created in a cloud platform using a cloud platform infrastructure language that is cloud platform independent. The system uses a control datacenter with a set of service groups that are used to configure other datacenters, e.g., perform continuous delivery of the software artifacts for the other datacenters. The system uses a primary control datacenter and a secondary control datacenter. The primary control datacenter configures the infrastructure of the tenant datacenter, e.g., by configuring computing resources in the cloud platform for the tenant datacenter according to a declarative specification of the tenant datacenter. The secondary control datacenter efficiently controls the process of configuring the tenant datacenter, e.g., in the event of a failure of the primary control datacenter.

Description

[Technical field]

[0001] The present disclosure relates generally to continuous delivery of software releases on cloud computing platforms, and more particularly to multi-substrate fault tolerant continuous delivery of data center builds on cloud computing platforms. [Background technology]

[0002] Organizations are increasingly turning to cloud platforms (or cloud computing platforms), such as AWS (AMAZON® WEB SERVICES), GOOGLE® CLOUD PLATFORM, MICROSOFT® AZURE, etc., for their infrastructure needs. Cloud platforms provide servers, storage, databases, networking, software, etc. to organizations over the Internet. Traditionally, organizations maintained data centers that house the hardware and software used by the organizations. However, maintaining data centers can result in significant overhead in terms of maintenance, personnel, etc. As a result, organizations are shifting their services to cloud platforms that offer scalability and elasticity of computing resources.

[0003] An organization maintains a computing infrastructure on a cloud platform using a continuous delivery platform that can manage and deploy applications on the cloud platform. Such a continuous delivery platform allows an organization to simplify the software deployment process and manage applications, firewalls, clusters, servers, load balancers, and other computing infrastructure on the cloud platform. However, using a continuous delivery platform to deploy software releases for services offered on a cloud platform can be complicated. For example, different versions of software may need to be deployed on different services running on different cloud computing resources. Furthermore, each cloud platform uses different tools to manage resources.

[0004] Large systems, such as multi-tenant systems, can manage services for multiple organizations, representing tenants of the multi-tenant system, and can interact with multiple cloud platforms. Furthermore, maintaining services for multiple tenants requires enforcing boundaries across the data and applications of different tenants in the cloud platform. A system that maintains services on a cloud platform must also ensure that any continuous delivery of new releases is performed without interruption. A failure in the infrastructure used to perform the continuous delivery of software artifacts can limit the ability to manage all services running for all tenants if the system is a multi-tenant system. Such a failure will interrupt the installation of new features and any fixes due to defects or failures in existing services. Traditional systems that do not effectively handle such failures of the infrastructure can cause long interruptions in service. Traditional techniques for continuous delivery are suitable for traditional data centers managed and operated by a single organization. Continuous delivery on public cloud environments involves several additional considerations, such as the possibility of unauthorized data access, shared resources, and lack of direct control over computing resources by organizations. Traditional techniques for continuous delivery are insufficient for deploying software artifacts on public cloud environments. [Brief description 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. [Figure 2A] 2 is a block diagram illustrating a system architecture of a deployment module 210 according to one embodiment. [Figure 2B] 1 illustrates an overall process for deploying software artifacts to a data center, according to one embodiment. [Diagram 3] FIG. 2 is a block diagram illustrating the architecture of a software release management module according to one embodiment. [Figure 4] 1 illustrates an example of a data center declarative specification according to one embodiment. [Diagram 5] 1 illustrates an exemplary data center created on a cloud platform based on a declarative specification, according to one embodiment. [Figure 6] FIG. 2 is a block diagram illustrating the creation of a data center on a cloud platform based on a declarative specification, according to one embodiment. [Figure 7] 1 illustrates an overall process for generating a pipeline for deployment of software artifacts on a data center configured on a cloud platform, according to one embodiment. [Figure 8] 1 illustrates an exemplary master pipeline, according to one embodiment. [Figure 9] 1 illustrates the overall process performed by stages for an environment of a master pipeline on a cloud platform, according to one embodiment. [Figure 10] 1 illustrates an exemplary master pipeline, according to one embodiment. [Figure 11] 1 illustrates an overall process for deployment of software artifacts on a data center configured on a cloud platform, according to one embodiment. [Figure 12] FIG. 2 is a block diagram illustrating the architecture of a fault-tolerant continuous delivery module according to one embodiment. [Figure 13] FIG. 2 is a block diagram illustrating the architecture of a control data center according to one embodiment. [Figure 14A] 1 illustrates an architecture of a fault-tolerant architecture of a control data center for continuous delivery of software artifacts to data centers configured in a cloud platform, according to one embodiment. [Figure 14B]1 illustrates an architecture of a fault-tolerant architecture of a control data center for continuous delivery of software artifacts to data centers configured in a cloud platform, according to one embodiment. [Figure 15] 15 illustrates a process for configuring a data center on a cloud platform using the fault-tolerant architecture of the control data center illustrated in FIG. 14 according to one embodiment. [Figure 16] 1 illustrates a process for handling a failure in a primary control data center, according to one embodiment. [Figure 17] 2 is a block diagram illustrating a functional diagram of an exemplary computer system for use in the environment of FIG. 1, according to one embodiment.

[0006] 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 shown herein may be employed without departing from the principles of the embodiments described herein.

[0007] The drawings use like reference numbers to identify like elements. A letter following a reference number, such as "115a," indicates that the text specifically refers to the element with that particular reference number. A reference number in text without a following letter, such as "115," refers to any or all of the elements in the figure with that reference number. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] A cloud platform provides computing resources, such as storage, computing resources, and applications, to computing systems on an on-demand basis over a public network, such as the Internet. Cloud platforms enable enterprises to minimize up-front costs for setting up computing infrastructure and also enable enterprises to launch and run applications more quickly with less maintenance overhead. Cloud platforms also enable enterprises to adjust computing resources to rapidly fluctuating and unpredictable demand. Enterprises can create data centers using cloud platforms for use by the enterprise's users. However, implementing a data center on each cloud platform requires expertise in the technology of the cloud platform.

[0009] An embodiment creates data centers in a cloud platform using a cloud platform infrastructure language that is cloud platform independent. The system receives a cloud platform independent declarative specification of the data center. The declarative specification describes the structure of the data center and may not provide instructions specifying how to create the data center. The cloud platform independent declarative specification is configured to generate the data center on any of a plurality of cloud platforms and is specified using the cloud platform infrastructure language. The system receives information identifying a target cloud platform for creating the data center and compiles the cloud platform independent declarative specification to generate a cloud platform specific data center representation. The system transmits the cloud platform specific data center representation and a set of instructions for execution in the target cloud platform. The target cloud platform executes the instructions to configure the data center using the platform specific data center representation. The system provides a user with access to computing resources of the data center configured by the cloud platform.

[0010] In one embodiment, the system performs operations related to a software release on a data center configured on a cloud platform, such as deploying the software release, provisioning resources, performing a rollback of the software release, etc. The system accesses a data center configured on a target cloud platform. The data center is generated based on a cloud platform independent declarative specification that includes a hierarchy of data center entities. Each data center entity includes one or more of: (1) a service, or (2) one or more other data center entities. The system generates a cloud platform independent master pipeline that includes: (1) a sequence of stages for deployment of software artifacts, such as a development stage, a test stage, and a production stage, and (2) criteria for promoting the software artifacts from one stage in the sequence of stages to a subsequent stage. The system compiles the cloud platform independent master pipeline to generate a cloud platform dependent detailed pipeline for the target cloud platform with instructions for performing operations related to the services according to the layout of the data center defined by the declarative specification. The system executes a cloud platform dependent detailed pipeline on a target cloud platform to deploy, for example, a software release onto data center entities of a data center.

[0011] In one embodiment, the system receives a cloud platform independent artifact version map that associates data center entities of a data center with versions of software artifacts targeted for deployment on the data center entities. Each software artifact includes executable instructions associated with a service configured for execution on one or more cloud platforms. The system generates a cloud platform specific master pipeline for the target cloud platform based on the cloud platform independent artifact version map. The cloud platform specific master pipeline includes instructions to perform operations such as building and deploying appropriate versions of deployment artifacts for the service on the data center entities according to the cloud platform independent version map. The system transmits the cloud platform specific deployment pipeline to the target cloud platform for execution. The artifact version map and master pipeline can be used to perform various actions related to the service, including deploying the service, destroying the service, provisioning resources for the service, destroying resources for the service, etc.

[0012] In one embodiment, the system performs fault tolerant continuous delivery of datacenter builds on a cloud platform. The datacenter builds can configure a datacenter, configure a service or service group in the datacenter, deploy software artifacts associated with the services of the datacenter, etc. The datacenter builds can be associated with a set of changes, e.g., code changes or configuration changes, associated with the datacenter or services running on the datacenter. The datacenters are configured on the cloud platform. The system uses a control datacenter with a specific set of service groups that are used to configure other datacenters, e.g., tenant datacenters created for use by a specific tenant. The control datacenter is also used to perform continuous delivery of software artifacts for the tenant datacenters. The system includes a fault tolerant architecture for the control datacenter. Thus, the system uses a primary control datacenter and a secondary control datacenter. Any requests related to continuous delivery of software artifacts are directed to the primary control datacenter. The primary control datacenter configures the infrastructure of the tenant datacenter, for example, by configuring computing resources in the cloud platform for the tenant datacenter according to the tenant datacenter's declarative specification. The primary control datacenter transmits information describing the state of the configured infrastructure to the secondary control datacenter, the state indicating the infrastructure configured so far for the tenant datacenter. The information describing the state of the configured infrastructure allows the secondary control datacenter to efficiently resume control of the processes that configure the tenant datacenter at any point in time, for example, in the event of a failure of the primary control datacenter.When the secondary control datacenter assumes control of the processes that configure the tenant datacenters, the secondary control datacenter begins transferring information describing the state of the configured infrastructure to the secondary control datacenter, thereby reversing the roles of the primary and secondary control datacenters.

[0013] The cloud platform is also referred to herein as a substrate. The declarative specification of the data center is substrate independent or agnostic. The system may represent, but is not limited to, a multi-tenant system and may be any online system or any computing system that has network access to the cloud platform.

[0014] System Environment 1 is a block diagram of a system environment illustrating a multi-tenant system constituting 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.

[0015] The multi-tenant system 110 stores information for one or more tenants 115. Each tenant may be associated with a business that represents a customer of the multi-tenant system 110. Each tenant may have multiple users that interact with the multi-tenant system via client devices 105.

[0016] A cloud platform may also be 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 a target cloud platform 120 and may use the data center to perform operations, such as provisioning resources, performing software releases, etc. 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 may be used by a user, e.g., a user associated with the tenant. Each tenant may provide different functionality to the tenant's users. Thus, each tenant may run different services on the data center configured for the tenant. A multi-tenant system may implement different mechanisms for software release and deployment for each tenant. A tenant may further obtain or develop a version of software that includes instructions for various services running in the data center. An embodiment allows a tenant to deploy specific versions of software releases for different services running on different computing resources of the data center.

[0017] The computing resources of the data center are secure and cannot be accessed by users who are not authorized to access them. For example, a data center 125a created for a user of tenant 115a cannot be accessed by a user of tenant 115b unless access is explicitly granted. Similarly, a data center 125b created for a user of tenant 115b cannot be accessed by a user of tenant 115a unless access is explicitly granted. Furthermore, services provided by the data center can be accessed by a computing system outside the data center only if access is granted to the computing system according to the declarative specification of the data center. The system uses multiple security layers to identify and authorize users to access these resources.

[0018] In a multi-tenant system 110, data for multiple tenants may be stored in the same physical database. However, the database is configured such 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 that are 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 several tenants simultaneously. However, the multi-tenant system enforces tenant-level data isolation to ensure that one tenant's jobs do not access other tenants' data.

[0019] Examples of cloud platforms include AWS (AMAZON WEB SERVICES), GOOGLE CLOUD PLATFORM, or MICROSOFT AZURE. The cloud platform 120 provides computing infrastructure services that can be used on-demand by the tenants 115 or by any computing system outside 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 can be used by the tenants 115 to build, deploy, and manage applications in a scalable and secure manner.

[0020] The multi-tenant system 110 may include a tenant data store that stores data for various tenants of the multi-tenant store. The tenant data store may store data for different tenants in separate physical structures, such as 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 data for different tenants.

[0021] Each component shown in FIG. 1 represents one or more computing devices, such as Microsoft TM Windows TM Compatible Operating Systems (OS): Apple TMThe computing devices may be conventional computer systems running OS X and / or Linux distributions. The computing devices may also be client devices having computing capabilities such as personal digital assistants (PDAs), mobile phones, video game systems, etc. Each computing device stores software modules that store instructions.

[0022] 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.

[0023] 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 enterprise may use the techniques disclosed herein to create one or more data centers on one or more cloud platforms 120.

[0024] System Architecture The multi-tenant system 110 includes a deployment module for deploying software artifacts on a cloud platform. The deployment module can perform various operations associated with a software release, such as provisioning resources on the cloud platform, deploying the software release, performing a rollback of the software artifact installed on a data center entity, etc. Figure 2 is a block diagram illustrating a system architecture of a deployment module 210, according to one embodiment. The deployment module 210 includes a data center creation module 220 and a software release management module 230. Other embodiments can have different and / or other components than those described herein, and functionality can be distributed between the components in a different manner.

[0025] The data center creation module 220 includes instructions for creating a data center on the cloud platform. The software release management module 230 includes instructions for deploying software releases or software artifacts for various services or applications running on the data center created by the data center creation module 220.

[0026] The data center generation module 220 receives a cloud platform independent declarative specification of a data center from a user, e.g., a tenant user. The cloud platform independent declarative specification of a data center specifies various entities of the data center. In one embodiment, the cloud platform independent declarative specification of a data center includes a hierarchical organization of data center entities, where each data center entity may include one or more services, one or more other data center entities, or a combination of both. FIG. 4 describes the various types of data center entities in further detail. The data center generation module 220 receives the platform independent declarative specification and a target cloud platform as input and generates a cloud platform specific metadata representation for the target cloud platform. The data center generation module 220 deploys the generated cloud platform specific metadata representation on the target cloud platform to create a data center on the target cloud platform according to the declarative specification.

[0027] Software release management module 230 receives as inputs (1) artifact version map 225 and (2) master pipeline 235. Artifact version map 225 identifies specific versions of software releases or deployment artifacts that are targeted for deployment on specific data center entities. Artifact version map 225 maps data center entities to software release versions that are targeted for deployment on the data center entities. Master pipeline 235 contains instructions for operations related to software releases on a data center, such as deploying a service, destroying a service, provisioning resources for a service, destroying resources for a service, etc.

[0028] The master pipeline 235 may include instructions for performing operations related to software releases for different environments, such as a development environment, a test environment, a canary environment, and a production environment, and instructions for determining when a software release is promoted from one environment to another. For example, if the deployment of a software release in a development environment executes a number of test cases that exceeds a threshold, the software release is promoted to a test environment for further testing, e.g., system-level and integration testing. If the software release in the test environment passes a threshold of test coverage, the software release is promoted to a canary environment where the software release is provided to a small subset of users on a trial basis. If the software release in the canary environment runs without errors for a threshold time, the software release is promoted to a production environment where the software release is provided to all users.

[0029] The software release management module 230 compiles the input artifact version map 225 and master pipeline 235 to generate a cloud platform specific detailed pipeline 255 that is sent to the target cloud platform. The cloud platform specific detailed pipeline 255 includes instructions for deploying the appropriate version of the software release or deployment artifact on the data center entity as specified in the artifact version map 225. The software release management module 230 can receive a modification to one of the inputs. For example, a user may modify the input artifact version map 225 and provide the same master pipeline 235. Thus, the same master pipeline is used, but a different software release is deployed on the data center entity. The software release management module 230 recompiles the input to generate a new cloud platform specific detailed pipeline 255 that deploys the version of the software release according to the new artifact version map 225.

[0030] The artifact version map may also be referred to as a deployment manifest, a version manifest, a software release map, or a software artifact version map. The master pipeline may also be referred to as a master deployment pipeline or a master orchestration pipeline.

[0031] FIG. 2B illustrates an overall process for deploying software artifacts to a data center, according to one embodiment. FIG. 2B illustrates a layout of a data center 265 including various data center entities. As shown in FIG. 2B, an artifact version map 225 identifies different versions of software targeted for release on different data center entities 275 of the data center 265. A master pipeline represents the flow of deployment artifacts through various environments of the data center. The software release management module 230 combines the information in the master pipeline 235 with the artifact version map 225 to determine a cloud platform specific detailed pipeline 255 that maps appropriate versions of software artifacts on the data center entities according to the artifact version map 225.

[0032] 3 is a block diagram illustrating the architecture of software release management module 230, according to one embodiment. Software release management module 230 includes an analysis module 310, a pipeline generator module 320, an artifact version map store 330, a pipeline store 340, a fault tolerant continuous delivery module 350, and a pipeline execution engine 360. Other embodiments may include more, fewer, or different modules than those shown in FIG. 3 herein.

[0033] The analysis module 310 analyzes various types of user inputs, including declarative specifications of data centers, artifact version maps 225, and master pipelines 235. The analysis module 310 generates data structures and metadata representations of the processed inputs and provides the generated data structures and metadata representations to other modules of the software release management module 230 for further processing.

[0034] The metadata store 340 stores various transformed metadata representations of the data center generated by the software release management module 230. The transformed metadata representations may be used to perform rollbacks to previous versions in case of encountering problems with the current version of the data center. The transformed metadata representations may also be used for validation, auditing, control, etc. at various stages of the transformation process.

[0035] The pipeline generator module 320 processes the master pipeline with the artifact version map received as input to generate a detailed pipeline for the target cloud platform. The pipeline includes stages containing instructions for provisioning a service or deploying an application to deploy software release versions for various services on the cloud platform according to the artifact version map. The artifact version map store 330 stores the artifact version map received from the user, and the pipeline store 340 stores the master pipeline and the pipelines generated by the pipeline generator module 320.

[0036] The fault-tolerant continuous delivery module 350 manages the continuous delivery of software artifacts to data centers configured in a cloud platform in a fault-tolerant manner. Details of the fault-tolerant continuous delivery module 350 are further shown and described in connection with FIG.

[0037] Pipeline execution engine 360 ​​executes the detailed pipeline generated by pipeline generator module 320. In one embodiment, pipeline execution engine 360 ​​is a system such as SPINNAKER that executes pipelines for software release / deployment. Pipeline execution engine 360 ​​parses the pipeline and executes each stage of the pipeline on the target cloud computing platform.

[0038] Cloud platform-based data center creation 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 multiple instances of each data center entity type can exist. Examples of data center entities include data centers, service groups, services, teams, environments, and schemas.

[0039] 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. Below are descriptions of various types of datacenter entities and examples thereof. These 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 shown herein. In one embodiment, the declarative specification is specified using hierarchical objects, e.g., Javascript object notation (JSON), that conform to a predefined schema.

[0040] A service group 520 represents a set of capabilities and features and services provided by one or more computing systems that can be independently constructed and delivered, according to one embodiment. A service group may also be referred to as a logical service group, a functional unit, or a bounded context. A service group 520 may also be considered as a set of services for a set of cohesive technical use case functionality provided by one or more computing systems. A service group 520 enforces security boundaries. A service group 520 defines a scope for modifications. Thus, any modifications to entities such as capabilities, features, or services provided by one or more computing systems in a service group 520 may be propagated to entities in the service group as needed or appropriate, but not to entities that exist outside the bounded definition of the service group 520. A data center may include multiple service groups 520. A service group definition specifies attributes including a name, a description, an identifier, a schema version, and a 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 particular user interface feature. The Shared Documents service group provides the ability to share documents across users. There may be several other service groups as well.

[0041] Service groups support reusability of specifications so that tenants or users interested in developing a data center have a library of service groups they can easily use. Boundaries around the services in a service group are based on security and network concerns, among others. Service groups are associated with protocols 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. Additionally, service groups are substrate agnostic. Service groups provide a blast radius scope for services within the service group, such that any failure of a service within the service group has impact limited to the services within the service group and minimal impact outside the service group.

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

[0043] As shown in the above example, a service group can specify a set of clusters. A cluster represents a set of computing nodes, e.g., a set of servers, a set of virtual machines, or a set of containers (such as KUBERNETES containers). A physical server can run multiple containers, where each container has its own share of filesystem, CPU, memory, process space, etc.

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

[0045] A service group can specify security groups, each of which specifies 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 in the security group. Alternatively, services in the security group use one protocol to interact with each other, and services outside the security group use a different protocol that requires enhanced authentication to interact with services in the security group. Thus, a security group specifies policies that determine how services can interact with each other. A security policy can specify one or more environments to which the security policy is applicable. For example, a security policy policy1 can apply to a particular environment env1 (e.g., production environment), and another security policy policy2 can apply to another environment env2 (e.g., development environment). A security policy may be specified for a service group type or for a particular service type.

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

[0047] In one embodiment, a security policy may specify a set of source services and a set of destination services for a service group. A source service for a particular service specifies the services outside of the security group that are allowed to connect with this particular service. A destination service for a particular service specifies the services outside of the security group that this particular service needs to connect with. During provisioning and deployment, the data center creation module generates instructions for the cloud platform that implement the particular network policy using the cloud platform's specific features and network capabilities, such that the network policy implements the security policy specified in the declarative specification.

[0048] A datacenter entity called a cell represents a set of services that interact with each other in a vertical fashion and can be scaled with further 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 a set of services that interact with each other. A datacenter instance can contain one or more cells. Each cell can contain one or more services. A datacenter can contain service groups or instances of cells.

[0049] A service definition specifies metadata about the type of service, e.g., database service, load balancer service, etc. The metadata describes various attributes of the service, including the name of the service, a description of the service, the location of documentation for the service, any subservices associated with the service, the owner of the service, the team associated with the service, build dependencies of the service, which specify other services this service depended on when built, start dependencies of the service, which specify other services that should be running when this particular service is started, authorized clients, DNS (Domain Name Server) names associated with the service, service status, support level of the service, etc. The service definition specifies a listen port attribute that specifies the ports on which the service can listen for different communication protocols, e.g., a service can listen on port p1 for UDP protocol and port p2 for TCP protocol. Other services in the data center can interact with the service through the ports specified by the service.

[0050] A service definition specifies a destination endpoint, e.g., an attribute outbound-access that specifies that the service requires access to a specified external URL (Uniform Resource Locator). During deployment, the data center generation module ensures that the cloud platform implements the access policy such that an instance of this service type is provided with the required access to the external URL.

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

[0052] Below is an example of a service definition. [Table 2]

[0053] The team definition 450 includes team member names and other attributes of the team, such as name, email, communication channel, etc. The following is an example of a team definition: A service can be associated with one or more teams responsible for modifications made to the service. Thus, any modifications made to the service are approved by the team. A service may be associated with a team responsible for maintaining the service after it is deployed to the cloud platform. A team may be associated with a service group and correspondingly, all services in that service group. For example, the team approves any changes to the service group, e.g., the services that are part of the service group. A team may be associated with a data center and therefore, all service groups in the data center. Team association specified at the data center level provides a default team for all service groups in the data center, which in turn provides a default team for all services in the service group.

[0054] 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 have been provided by team associations specified at the service group level or datacenter level. A team can determine how certain actions are taken for a datacenter entity associated with the team. The team association further determines the number of accounts on the cloud platform that are created for generating the final metadata representation of the datacenter by the compiler to the cloud platform and 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 access to the user accounts to the team members. Thus, the team members are permitted to perform certain actions associated with the datacenter entity associated with the team, such as making or approving structural changes to the datacenter entity, including debugging and testing issues that may be identified for the datacenter entity, or maintenance of the datacenter entity as it is deployed.

[0055] Conventional techniques associate the same team with a datacenter throughout the design process, resulting in organizational structure having influence on the design of the datacenter or service group. Embodiments decouple team definition from the configuration that defines the datacenter entity, thereby reducing the influence of the team on the design and architecture of the datacenter entity. [Table 3]

[0056] Environment definition 460 specifies the type of system environment represented by the data center, for example, development environment, staging environment, test environment, or production environment. Schema definition 470 specifies a schema that specifies the syntax of certain data center entity definitions. Schema definition 470 is used to validate various data center entity definitions. The data center generation module determines the security policies of the data center in the cloud platform specific metadata representation 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 more restricted access in a production environment compared to a development environment. A security policy may specify the length of time that a security token is allowed to exist for a particular purpose. For example, a long access token (e.g., a week-long access token) may be allowed in a development environment, while an access token with a shorter life span (e.g., a few hours) may be used in a production environment. An access token may allow a user or service to access a particular cloud platform resource.

[0057] A datacenter definition 420 specifies attributes and components of a datacenter instance. A declarative specification can specify multiple datacenter instances. A datacenter definition 420 specifies attributes including the datacenter's name, description, type of environment, set of service groups, team, domain name servers, etc. A datacenter definition can specify a schema definition, and any metadata representation generated from the datacenter definition is validated against the specified schema definition. A datacenter contains a set of core services and capabilities that enable other services to function within the datacenter. An instance of a datacenter can be deployed within a particular cloud platform and associated with a particular environment type, e.g., development, testing, staging, production, etc.

[0058] The following is one definition of a datacenter instance: A datacenter instance definition includes a list of service groups contained 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. [Table 4]

[0059] FIG. 5 illustrates some exemplary data centers created on a cloud platform based on a declarative specification, according to one embodiment. The data centers 510 may be created based on the declarative specification processed by the data center generation module 210. As shown in FIG. 5, multiple data centers may be configured in the cloud platform 120. Each data center 510 may correspond to a tenant 115 of the multi-tenant system 110. A tenant 115 may create one or more data centers 510. Alternatively, the data centers 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 can include multiple instances of services of the same service type.

[0060] The data center generation module 220 creates a data center on a cloud platform based on a declarative specification using the following steps: The data center generation module 210 receives 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 in any of a plurality of cloud platforms.

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

[0062] The data center generation module 210 compiles the cloud platform independent declarative specification to generate a cloud platform specific data center representation for creating a data center on a target cloud computing platform. For example, the cloud platform specific data center representation can point to user accounts, network addresses, etc. that are specific to the target cloud computing platform.

[0063] The data center creation module 210 transmits the platform-specific data center representation along with instructions for deploying the data center on the target cloud computing platform. The target cloud computing platform executes the instructions for configuring computing resources of the target cloud computing platform to generate a data center according to the platform-specific data center representation. The data center creation module 210 provides users with access to the computing resources of the data center configured by the cloud computing platform. For example, if a data center is created for a tenant of a multi-tenant system, users associated with the tenant are provided with access to the data center.

[0064] 6 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 610. The cloud platform independent declarative specification 610 may be a version of a declarative specification that has been incrementally modified by a user. The data center generation module 210 processes a particular version of the cloud platform independent declarative specification 610. Because the cloud platform independent declarative specification 610 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 610.

[0065] The data center generation module 210 processes the cloud platform agnostic declarative specification 610 to generate a cloud platform agnostic detailed metadata representation 620 for the data center. The cloud platform agnostic detailed metadata representation 620 defines details of each instance of the data center entities specified in the cloud platform agnostic declarative specification 610. The data center generation module 210 creates unique identifiers for the data center entity instances, e.g., service instances.

[0066] In one embodiment, the cloud platform agnostic detailed metadata representation 620 includes an array of instances of a data center entity type, e.g., 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 that are authorized 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 members of the team to access the user accounts.

[0067] The cloud platform independent detailed metadata representation 620 includes attributes of each instance of the data center entity. Thus, the description of each instance of the data center entity is expanded to include all details. As a result, the cloud platform independent detailed metadata representation 620 of the data center can be significantly larger than the cloud platform independent declarative specification 610. For example, the cloud platform independent declarative specification 610 can be thousands of lines of specification, while the cloud platform independent detailed data center representation 620 can be millions of lines of generated code. As a result, the data center generation module 210 keeps the cloud platform independent detailed metadata representation 620 as immutable, i.e., once the representation is finalized, no modifications are performed on the representation. For example, if any updates, deletions, or additions of the data center entities need to be performed, they are performed on the cloud platform independent declarative specification 610.

[0068] The data center generation module 210 receives a target cloud platform where the data center is expected to be provisioned and deployed, and generates a cloud platform specific detailed metadata representation 630 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, networking resources such as virtual private clouds (VPCs) and subnets on the VPCs, various connections between entities in the cloud platform, etc. The data center generation module 210 receives resource identifiers of resources to be created in the target cloud platform, such as user account names, VPC IDs, etc., and incorporates them into the cloud platform agnostic detailed metadata representation 620 to obtain a cloud platform specific metadata representation 630 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 of that service group, such as to debug, receive alerts, etc.

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

[0070] The cloud platform independent declarative specification specifies dependencies between services, e.g., start dependencies for each service that list all services that should be running when a particular service is started. The data center generation module 220 generates a cloud platform specific detailed metadata representation of the data center that includes information describing these dependencies, such 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, when this service is started, the services that need to be started before this service are running. Thus, the dependencies between services represent a dependency graph, and the cloud platform starts the execution of the services in an order determined based on the dependency graph, such that if service A depends on service B, service B is started before service A is started.

[0071] The data center generation module 220 creates trust relationships between user accounts that allow services to access other services over a secure communication channel. These trust relationships are generated using substrate-specific instructions based on the declarative specification, e.g., generated based on outbound access attributes specified for the services. The data center generation module 220 sends instructions to the cloud platform to create network policies based on cloud platform specific mechanisms that control interactions and access across service groups and services, as specified by configuration of the declarative specification, e.g., outbound access, security groups, security policies, etc.

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

[0073] The cloud platform agnostic declarative specification 610 may be referred to as a declared data center representation, the cloud platform agnostic detailed metadata representation 620 may be referred to as a derived metadata representation of the data center, and the cloud platform specific metadata representation 630 may be referred to as a hydrated metadata representation of the data center.

[0074] Overall process for deployment of software artifacts in a data center 7 illustrates an overall process for generating a pipeline for deployment of software artifacts on a data center configured on a cloud platform, according to one embodiment. A data center generation module generates one or more data centers on a target cloud platform (710). Each data center is generated from a cloud platform-independent declarative specification and has a hierarchy of data center entities.

[0075] The software release management module 230 generates (720) a cloud platform agnostic master pipeline. In one embodiment, the cloud platform agnostic master pipeline includes stages corresponding to environments of a data center, e.g., development, test, canary, and production environments. The master pipeline configures a sequence of incremental and / or conditional deployments across various environments, such as development, test, staging, or production. The master pipeline may be triggered by delivery of an image of the software artifact and includes stages or instructions for deploying the build in an environment of type development. The built software artifact is conditionally promoted to one or more test environments, followed by one or more canary environments, before finally being deployed to the production environment. The master pipeline may be customized by a user, e.g., a service owner, to represent a particular orchestration across environments. The master pipeline may be customized to capture a particular promotion criteria for moving from one stage to the next. For example, different tenants of a multi-tenant system may customize the master pipeline in different ways. In one embodiment, the master pipeline by default uses the latest version of software for software artifacts for services, and builds and deploys this version across various environments. Users can use artifact version maps to ensure that specific versions of software artifacts are deployed on specific data center entities.

[0076] In one embodiment, each service deployed in a datacenter has a cloud platform independent master pipeline generated from datacenter entities as defined by the declarative specification of the datacenter, e.g., a master pipeline for the datacenter instance, a master pipeline for the service group, a master pipeline for the cell, a master pipeline for the service, etc. The master pipeline can be triggered upon delivery of an image of the software artifact. The master pipeline can implement continuous deployment controlled by the service owner. The master pipeline may implement on-demand deployment owned by the datacenter instance owner or owned by the release owner.

[0077] Certain portions of the master pipeline may be customized by users, e.g., by tenants of a multi-tenant system deploying services on a data center. For example, a promotion decision pipeline may be customized by a tenant to determine which test cases are executed and what the thresholds are. The software release management module 230 receives 730 customizations to the logic for promoting software artifacts from one stage to another of the cloud platform agnostic master pipeline.

[0078] The software release management module 230 compiles the cloud platform agnostic master pipeline to generate cloud platform specific detailed deployment pipelines that are specific to the hierarchy of data center entities for each data center as specified by the cloud platform agnostic declarative specification for the data center (740).

[0079] The software release management module 230 further receives (750) code for releasing one or more features of the service deployed on the data center. The software release management module 230 executes a cloud platform specific detailed deployment pipeline to deploy (760) software artifacts based on the received code.

[0080] FIG. 8 illustrates an exemplary master pipeline 800, according to one embodiment. The master pipeline represents a sequence of stages that represent progressive conditional deployment across various data center environments. FIG. 8 illustrates stages for different environments in a data center, including development, test, canary, and production environments. Each stage further represents the pipeline that is executed for that stage. Thus, the master pipeline 800 includes a development environment pipeline 810, which feeds into a test environment pipeline 820, which feeds into a canary environment pipeline 830, which feeds into a production environment pipeline 840.

[0081] The pipelines at each stage are hierarchical pipelines that contain lower level pipelines. For example, development environment pipeline 810 includes a development master pipeline that feeds data center pipelines D11, D12, ... depending on the number of data centers specified as having development environments in the data center declarative specification.

[0082] The test environment pipeline 820 includes a test master pipeline that feeds data center pipelines D21, D22, . . . according to the number of data centers specified as having test environments in the data center declarative specification.

[0083] The canary environment pipeline 820 includes a canary master pipeline that feeds data center pipelines D31, D32, ... depending on the number of data centers specified as having a canary environment in the data center declarative specification.

[0084] The production environment pipeline 820 includes a production master pipeline that feeds data center pipelines D21, D22, ... according to the number of data centers specified as having test environments in the data center declarative specification.

[0085] Each environment pipeline 810, 820, 830 includes a promotion decision pipeline 815a, 815b, 815c, respectively. The output of the data center pipelines of the environment pipelines is collected by the promotion decision pipeline 815, which determines whether the software artifact is ready for promotion to the next stage. The promotion decision pipeline 815 can determine whether the software artifact for the service is promoted to the next stage based on the test case results obtained by the data center. For example, if more than a threshold number of test cases pass, the promotion decision pipeline 815 promotes the software artifact to the next stage. The last environment stage, e.g., the production environment pipeline, may not have a promotion decision pipeline because there is no subsequent stage to which the software artifact needs to be promoted. As shown in FIG. 8, the development environment pipeline promotion decision pipeline 815a determines whether to promote a software artifact from a development stage to a testing stage, the test environment pipeline promotion decision pipeline 815b determines whether to promote a software artifact from a testing stage to a canary stage, and the canary environment pipeline promotion decision pipeline 815c determines whether to promote a software artifact from the canary stage to a production stage.

[0086] The master pipeline includes multiple pipelines, such as a provisioning pipeline for provisioning resources of a target cloud platform and a deployment pipeline for deploying software artifacts on data center entities. Each pipeline includes a sequence of stages, and each stage represents 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 detailed pipelines for deploying versions of software artifacts on data center entities.

[0087] In one embodiment, the pipeline generator module 320 generates detailed pipelines using pipeline templates that contain variables. The pipeline templates are converted into pipelines by providing specific values ​​for the variables in the pipeline. The process of generating a pipeline from a template is called hydration of the pipeline template. The pipeline templates contain template expressions that are used as placeholders for the actual values ​​used in deployment. For example, the template expressions may be replaced by target-specific parameter values ​​or expressions. Multiple pipeline instances can be generated by hydrating the pipeline template for different targets. Template variables represent parameters that can 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 with the actual value of account_id, e.g., "12345", during hydration.

[0088] In one embodiment, the pipeline generator module 320 generates pipelines in a hierarchical manner based on a hierarchy of data center entities for 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 one level of the hierarchy and generates pipelines for the data center entities below that level. For example, the pipeline generator module 320 starts at the data center level and generates pipelines for the service groups in the data center. For each service group, the pipeline generator module 320 generates pipelines for the services in the service group.

[0089] The process of executing a pipeline according to one embodiment is as follows: The software release deployment module 230 receives a request to deploy a software artifact on a set of data center entities in a target cloud platform. The software release deployment module 230 executes a master pipeline for one or more data centers. The software release deployment module 230 executes an aggregation pipeline for each service group in each data center. The aggregation pipeline includes pipelines for the services in the service groups. For each service in each service group, the pipeline is executed by executing all stages of the pipeline. Execution of the provisioning pipeline 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.

[0090] Figure 9 illustrates the overall process performed by stages for an environment of a master pipeline on a cloud platform, according to one embodiment. Steps 910, 920, 930, 940, and 950 may be performed by each environment pipeline 810, 820, 830. The production environment pipeline 3 may only perform steps 910 and 920. The steps illustrated in Figure 9 may be performed for one service or for multiple services specified using a manifest file.

[0091] The environment pipeline for environment E includes instructions for deploying 910 the software to a set of datacenter entities, e.g., a set of datacenter entities designated as having environment E. In one embodiment, the software artifacts are generated by compiling source code for the services. The source code may be obtained from version control software. The set of datacenter entities may include datacenter instances, service groups, cells, services, or any combination thereof.

[0092] The environment pipeline for environment E further includes instructions for executing (920) tests to test the software artifacts deployed on the set of data center entities. The environment pipeline for environment E further includes instructions for evaluating (930) the test results against the promotion criteria, e.g., using the promotion decision pipeline 815. If the promotion criteria are not met, steps 910, 920, 930, and 940 may be repeated using a revised software artifact, e.g., a software artifact generated from source code that includes fixes for specific defects identified during testing (920). The environment pipeline for environment E further includes instructions for proceeding to the next stage (950) if the promotion criteria are met.

[0093] In one embodiment, the master pipeline includes a hierarchy of pipelines. The hierarchy includes multiple levels, and pipelines at a particular level include the pipelines at the next lower level as child pipelines. For example, at the highest level of the hierarchy, the master pipeline includes a release master pipeline that deploys a set of services related to a product. The next level of the hierarchy includes a service master pipeline that represents all deployments of a particular service across various environments. The next level of the hierarchy can include a service group master pipeline followed by a service master pipeline.

[0094] FIG. 10 illustrates an exemplary master pipeline, according to one embodiment. The master pipeline is a hierarchical pipeline, in which each stage of the pipeline can include a pipeline with detailed instructions for executing the stage. The master pipeline hierarchy can mirror the data center hierarchy. For example, the top level of the master pipeline represents a sequence of stages for different environments. Each environment can include one or more pipelines for a data center instance or other type of data center entity. The data center instance pipeline 1010 can include a service group pipeline 1020. Each service group pipeline 1020 can include one or more service pipelines 1030. The data center instance pipeline 1010 can include a cell pipeline 1025, each cell pipeline 1025 includes one or more service pipelines 1030. The service pipelines 1030 can include stages, each stage representing a pipeline that represents instructions for deploying a service for a particular environment. The lowest level pipeline in the hierarchy, or leaf-level pipeline, is called a unit pipeline and can include detailed service-specific instructions for performing operations related to the service. For example, the deployment of a service may include a pre-deployment step, a deployment step, a post-deployment step, and a post-deployment test and validation step.A pipeline that is not a leaf-level pipeline and has one or more child pipelines is an aggregate pipeline that orchestrates the execution of the child pipelines.

[0095] The master pipeline may be driven by a pull request that causes the software version control system to receive a request to consider changes committed to an external repository for inclusion in the project's main repository. Thus, the master pipeline is automatically triggered when a pull request is received to deploy the software artifact based on the latest software version for which the pull request was received. The master pipeline performs continuous delivery of the software artifact based on the pull request. The master pipeline may be driven on an on-demand basis, for example, by invoking a request using an application programming interface (API) of the deployment module 210. On-demand deployment based on the master pipeline may be requested for any set of services specified using the API and for any version of a given service. The master pipeline may be invoked to request a rollback from a current version to a previous version or a rollforward from a currently deployed version to a more recent version.

[0096] In one embodiment, the deployment module 210 creates a service master pipeline for each service. These pipelines are triggered when a pull request is received for the software repository. The deployment module 210 receives pipeline templates from a user for a particular service. These pipeline templates include detailed instructions for testing, validating, building, etc. for a particular service. The data center creation module 220 receives a cloud platform independent declarative specification for one or more data centers. The data center creation module 220 creates (or configures) the data centers according to the received cloud platform independent declarative specification. The deployment module 210 receives a promotion decision 815 pipeline. The promotion decision 815 pipeline is integrated into an overall master pipeline.

[0097] The pipeline generator creates all the pipelines for each datacenter from the templates and combines them through the master pipeline in a hierarchical manner, for example as shown in Figure 10. In one embodiment, the pipeline generator generates service pipelines for individual services, the pipeline generator generates cell master pipelines to call the service pipelines, the pipeline generator generates service group master pipelines to call the cell master pipelines, the pipeline generator generates datacenter instance master pipelines to call the service group pipelines, and the pipeline generator generates service master pipelines to call the datacenter instance master pipelines.

[0098] Below is a snippet of the master pipeline showing the various stages. Each stage can specify attributes including the stage name, the type of pipeline, the stage type (e.g. master deploy pipeline or promote pipeline), the previous stage, etc. [Table 5] JPEG0007666827000007.jpg113151

[0099] As shown in the inspector master pipeline, the first stage is the artifact version map. The next stage is the master deployment pipeline for deployment to the development environment. The next stage is the promote pipeline to determine if the software artifact can be promoted to the next stage. The next stage is the master deployment pipeline for deployment to the testing environment. The next stage is the promote pipeline to determine if the software artifact can be promoted to the next stage which is the staging environment.

[0100] Software Artifact Version Map In one embodiment, the deployment module 210 receives an artifact version map that associates various software artifacts and their versions with data center entities. The artifact version map provides a declarative specification of the specific versions of software artifacts that need to be deployed for a service at different data center entities. Each data center entity may be uniquely identified based on its location in the data center hierarchy specified by the declarative specification of the data center. For example, for a service, a software library may serve as a software artifact. A software artifact may have multiple versions, e.g., V1, V2, V3, etc. The artifact version map may specify that version V1 needs to be deployed to data center entities C1 and C2, and version V2 needs to be deployed to data center entities C3 and C4. The deployment module 210 generates master pipelines and instructions that ensure that the appropriate software artifact versions are deployed to the data center entities as specified in the artifact version map.

[0101] In one embodiment, the artifact version map is specified as a Javascript object notation (JSON) file, a YAML file, or a file using any other syntax for representing nested objects. The artifact version map is associated with various data center entities distributed across a hierarchy of data centers. <service> : <version>It can contain a set of key pairs. The artifact version map key pair acts as a whitelist for the corresponding pipelines. If a key for a service is not included in the artifact version map, all pipelines for that service will be excluded during the pipeline execution. Different artifact version maps may be applied to the same master pipeline, resulting in different services being included / excluded during the master pipeline execution.

[0102] Below is an example artifact version map. The artifact version map specifies the environment type using the attribute "env_types". In the example below, an environment type development is specified. An environment type can include one or more data center instances, which can include one or more service groups, which can include one or more services. In the example below, the software artifact name is specified as library1 and the version is specified as version1 and is associated with the service instance instance001. However, the software artifact name and version may be associated with any level of the data center entity in the hierarchy. For example, when a software artifact name and version is specified or of a service group, the software artifact name and version are applicable to all services in the service group unless the software artifact name and version are overridden with a different value of the software artifact name and version specified for a particular service instance in the service group. Similarly, a software artifact name and version can be specified for a data center instance and is applicable to all service groups or cells in the data center instance unless an override value is specified for the service group. [Table 6] JPEG0007666827000009.jpg24168

[0103] In one embodiment, the artifact version map specifies a datacenter entity using a full path of the datacenter entity, e.g., "stagger_group1 / datacenter1 / service_group2 / service1". In one embodiment, the artifact version map specifies a set of datacenter entities using regular expressions within the full path of the datacenter entity. For example, a full path that includes service_group[?] includes service_group1, service_group2, service_group3, etc.

[0104] Below is an example of an artifact version map that specifies a regular expression to define a set of services. The environment types are specified as dev and test, the datacenter entity in the full path including datacenter instance and service group is specified as a wildcard, and the service instance is specified as "service*". Therefore, for all datacenter instances for dev and test environments, for all service groups, for service names matching service*, version V1 of application app1 will be deployed. [Table 7]

[0105] In some embodiments, an artifact version map can specify parameters that are used by the pipeline such that the specified parameters are applicable to the stagger group for which the parameters are specified.

[0106] 11 illustrates an overall process for deployment of software artifacts on a data center configured on a cloud platform, according to one embodiment. A data center generation module generates 1110 one or more data centers on a target cloud platform. Each data center is generated from a cloud platform-independent declarative specification and has a hierarchy of data center entities.

[0107] The software release management module 230 receives as input an artifact version map that maps data center entities to versions of software artifacts (1120). The software release management module 230 further receives as input a cloud platform agnostic master pipeline (1130).

[0108] The software release management module 230 compiles the cloud platform agnostic master pipeline in conjunction with the artifact version map to generate 1140 a cloud platform specific detailed pipeline. In one embodiment, the generated cloud platform specific detailed pipeline includes an artifact version map filter before a particular stage to determine whether the particular stage should be enabled or disabled according to the artifact version map.

[0109] The software release management module 230 further receives (1150) code for releasing one or more features of the service deployed on the data center. For example, the code may represent source code obtained from a version control management system that stores a source code repository to which changes are submitted by developers. The software release management module 230 executes (1160) a cloud platform-specific deployment pipeline to deploy software artifacts based on the received code.

[0110] The artifact version map and master pipeline can be used to orchestrate various types of operations related to continuous delivery of software artifacts in a cloud-based data center. The artifact version map and master pipeline can be configured to perform aggregate retry operations for a service or service group or any data center entity. The artifact version map contains the configuration of retry operations for the data center entity, including the retry strategy, the threshold number of retries to perform in case of failure to execute a stage of the pipeline, whether confirmation from a user is required before retrying or the retry is performed automatically, etc. For example, the retry strategy may be a fixed backoff strategy that pauses execution for a fixed period of time before retrying. Other retry strategies may be configured using the artifact version map and master pipeline. In one embodiment, the pipeline generator introduces an invoke retrier stage in the aggregate pipeline to trigger the retry strategy if a previous pipeline stage fails. The retry strategy and configuration parameters specified for a data center entity apply to all data center entities and services within the data center entity unless the values ​​are overridden for nested data center entities.

[0111] A System Architecture for Fault-Tolerant Continuous Delivery Figure 12 is a block diagram illustrating the architecture of a fault-tolerant continuous delivery module according to one embodiment. The fault-tolerant continuous delivery module includes a data center configuration module 1210, a continuous delivery request router 1220, and a control data center metadata store 1230. Other embodiments may include more or fewer modules than those shown in Figure 12. Functions performed by specific modules illustrated herein may be performed by modules other than the illustrated modules.

[0112] In one embodiment, the fault tolerant continuous delivery module configures a primary control datacenter and a secondary control datacenter on the cloud platform. The primary control datacenter may also be referred to as an active control datacenter or an active control plane. The secondary control datacenter may also be referred to as a standby control datacenter or a standby control plane. The control datacenter may also be referred to herein as a bootstrap datacenter, e.g., the active control datacenter may be referred to as an active bootstrap datacenter and the standby control datacenter may be referred to as a standby bootstrap datacenter. The control datacenter includes a minimum set of services required to configure other datacenters and to make changes to the configuration of the datacenter, e.g., to reconfigure services installed on the datacenter, to configure software artifacts associated with services on the datacenter, etc.

[0113] The data center configuration module 1210 configures one or more control data centers on the target cloud platform. In one embodiment, the data center configuration module 1210 configures a primary control data center and a secondary control data center on the target cloud platform. The primary control data center is used to process requests to configure a data center or services on the data center, and the secondary control data center is used in place of the primary control data center, for example, as a standby control data center. The secondary control data center may be used in place of the primary control data center in the event of failure of one or more services of the primary control data center, planned maintenance of one or more services of the primary control data center, data corruption of a data store of the primary control data center, a security breach at the primary data center, or other reasons. The use of two control data centers provides fault tolerance because the likelihood of both control data centers failing or being unavailable at the same time is significantly lower than the likelihood of a single control data center failing or being unavailable.

[0114] The data center configuration module 1210 can configure a primary control data center on one target cloud platform and a secondary control data center on a different target cloud platform. This provides additional fault tolerance in case of a cloud platform failure. For example, if both control data centers are running on the same cloud platform and the cloud platform fails or is unreachable for any reason, both control data centers will be unavailable, resulting in downtime if any services need to be configured or reconfigured. Running two control data centers in different cloud platforms ensures that the likelihood of both cloud platforms being unavailable is extremely small, thereby significantly reducing the chance of downtime for the continuous delivery platform. Other embodiments may include more than two control data centers for additional fault tolerance.

[0115] The continuous delivery request router 1220 monitors requests for configuration of tenant datacenters, requests for configuration or service groups or services on tenant datacenters, etc., and sends them to the control datacenter. In one embodiment, if the primary control datacenter is functioning, the continuous delivery request router 1220 continues to send configuration requests to the primary control datacenter. The continuous delivery request router 1220 can receive an indication that control should be transferred from the primary control datacenter to another control datacenter, e.g., a secondary control datacenter. The indication can be received in various circumstances described herein, e.g., failure of the primary control datacenter, scheduled downtime of the primary control datacenter, etc. If such an indication is received, the continuous delivery request router 1220 begins routing configuration requests to the other control datacenter, e.g., the secondary control datacenter. In one embodiment, the continuous delivery request router 1220 includes a Domain Name Service (DNS) to route requests.

[0116] The control datacenter metadata store 1230 stores metadata for configuring any control datacenter, e.g., a primary control datacenter and a secondary control datacenter. The metadata describing the control center may be received using a declarative specification, e.g., the declarative specification shown in FIG. 4, including a particular set of service groups or service instances as further described herein. The datacenter configuration module 1210 invokes the software release management module to generate a cloud platform specific detailed pipeline 255 for configuring the control datacenter and submits the cloud platform specific detailed pipeline 255 for execution to create or configure the control datacenter on the target cloud platform.

[0117] FIG. 13 is a block diagram illustrating an architecture of a control data center according to one embodiment. The control data center includes a set of service groups as shown in FIG. 13. These service groups are required to perform configuring the data center in the cloud platform and to perform continuous delivery of software artifacts on the data center. According to one embodiment, the control data center includes service groups including a production service group 1310, a functional integration and testing service group 1320, a foundation service group 1330, an access control service group 1340, a cryptographic service group 1350, and a site bridge service group 1360. Other embodiments may include more or fewer service groups. The service groups of the control data center are defined using metadata stored in the control data center metadata store 1230 and specified using a declarative specification for the control data center.

[0118] The production services group 1310 provides services required to deploy software artifacts including pipeline generation, pipeline execution, etc. The functional integration and testing services group 1320 provides services to perform functional and integration testing of software artifacts to determine whether the software artifacts can be promoted from one environment to another. The foundation services group 1330 includes foundational services such as network time protocol (NTP), domain name system (DNS), and other core infrastructure services. The access control services group 1340 manages passwords and credentials and manages user access to computing resources. The cryptographic services group 1350 manages encryption of data in transit and when stored. The site bridge services group 1360 provides connectivity between organization networks (e.g., organizations that are tenants in a multi-tenant system) and computing systems that serve as endpoints in the cloud platform. Thus, the control data center includes services required to perform continuous delivery. Computing systems access the control data center to configure data centers in the cloud platform and to deploy software artifacts in data centers deployed in the cloud platform.

[0119] The control data center is a potential point of failure because it is used by all systems of an organization or multi-tenant system for continuous delivery and a failure of the control data center affects all entities that use the control data center for continuous delivery. Therefore, the embodiment uses a fault-tolerant architecture as shown in Figures 14A-14B.

[0120] 14A-14B show a fault-tolerant architecture of a control data center for continuous delivery of software artifacts to data centers configured in a cloud platform, according to one embodiment. Both FIGS. 14A-14B show a primary control data center 1410, a secondary control data center 1420, and a tenant data center 1430. The primary control data center 1410 and the secondary control data center 1420 may be in two separate geographical areas, for example, two different states. This ensures that any disaster that may affect one control center is unlikely to affect the other control data center.

[0121] The datacenter configuration module 1210 sends (1415) metadata describing the tenant datacenters to the primary control datacenter 1410 and the secondary control datacenter 1420. The primary control datacenter 1410 generates a pipeline for configuring the tenant datacenters based on the metadata it receives (1415).

[0122] As shown in FIG. 14A, the primary control datacenter 1410 controls the process of configuration of the tenant datacenter 1430. Thus, the primary control datacenter 1410 executes the generated pipelines and performs infrastructure configuration 1435 of the tenant datacenter 1430. For example, the primary control datacenter 1410 can create user accounts for access by various teams defined in the tenant datacenter's declarative specification and configure computing resources that can be accessed by the created user accounts according to the tenant datacenter's declarative specification, so that the user accounts can perform specific tasks specified in the declarative specification. The control datacenter dynamically creates user accounts and configures infrastructure in the cloud platform as part of the continuous delivery process based on metadata describing the tenant datacenter, metadata describing the services, metadata describing the service groups, etc. The control datacenter can delete user accounts when they are not needed according to the metadata, e.g., to garbage collect older accounts that are no longer in use.

[0123] According to one embodiment, the creation of a user account by the control data center includes the following steps: The control data center accesses a declarative specification for a tenant data center. The declarative specification may be stored as metadata describing the tenant data center. The control data center processes the service definition in the declarative specification of the tenant data center. For example, if a new service definition is identified in the declarative specification of the tenant data center, the control data center determines the user account required to configure the new service and creates the new user account. The user account may be required to access computing resources, e.g., databases, networking resources, file systems, processing resources, load balancers, Kubernetes clusters, etc. The control data center configures the relevant computing resources of the tenant data center's cloud platform to provide the requested functionality to the user account. For example, if the service requires database access, the control data center may create a user account in the database and configure one or more tablespaces in the database to allow this new user account to store data in the database. The control data center executes any generated pipelines to deploy the service and configures and manages the service and related infrastructure on the tenant data center.

[0124] The created user accounts are registered with the primary control data center. Registering the user accounts includes storing them in a data store from which the primary control data center can access the user account information and use them for tasks related to the continuous delivery of software artifacts for the tenant data centers. Registering the user account provides the control data center with information to perform various actions associated with the service, such as changing configurations, installing software artifacts, etc. When the control data center receives a request associated with the service, the control data center accesses the user account information to identify the user account associated with the service and uses the user account to perform any required actions, such as upgrades, patches, etc.

[0125] The primary control datacenter 1410 performs a transfer 1425 of information describing the configuration state of the tenant datacenter 1430 to the secondary control datacenter 1420. This causes the user accounts created by the primary control datacenter to be further registered in the secondary control datacenter. For example, the primary control datacenter 1410 sends information describing each user account created in the tenant datacenter 1430 and the credentials to access the user account to the secondary control datacenter 1420. A large organization or multi-tenant system may create thousands of user accounts when creating a datacenter in a cloud platform.

[0126] The secondary control datacenter 1420 receives metadata describing the tenant datacenter from the datacenter configuration module 1210 (1415b). The secondary control datacenter 1420 generates pipelines for the configuration of the tenant datacenter but does not execute them. The secondary control datacenter 1420 simply stores the generated pipelines and tracks the execution of the pipelines based on state information received from the primary control datacenter 1410. The secondary control datacenter 1420 performs infrastructure validation 1445 based on the received state information. For example, the secondary control datacenter 1420 accesses each user account created by the primary control datacenter 1410 received via state transfer 1425 and validates whether the user account has access to any computing resources specified by the declarative specification of the tenant datacenter and whether the appropriate computing resources are configured in the tenant datacenter.

[0127] FIG. 14B illustrates a configuration in which the secondary control datacenter is in control of executing the process of configuration of the tenant datacenter 1430. Thus, in FIG. 14B, the secondary control datacenter 1420 is executing the pipeline and running the infrastructure configuration 1455. The secondary control datacenter 1420 is forwarding (1475) state information, e.g., any user accounts created, to the primary control datacenter 1410, which is running infrastructure validation 1465 to ensure that the user accounts being created by the secondary control datacenter 1420 have access to the computing resources specified by the declarative specification of the tenant datacenter 1420. Thus, the roles of the primary control datacenter 1410 and the secondary control datacenter 1420 are reversed in FIG. 14B compared to FIG. 14A. This change in configuration from FIG. 14A to FIG. 14B may have occurred due to some failure of the primary control datacenter 1410. The secondary control data center 1420 may wait for the failure of the primary control data center 1410 to be corrected before sending (1475) the status information to the primary control data center 1410. The secondary control data center 1420 collects status information for the duration that the primary control data center 1410 is unavailable. The secondary control data center 1420 periodically checks whether the primary control data center 1410 is available, i.e., whether any failures have been corrected (i.e., repaired) or whether scheduled downtime has ended. Once the primary control data center 1410 becomes available, the secondary control data center 1420 sends the collected status information as a batch to the primary control data center 1410. Thereafter, the secondary control data center 1420 continues to send status information as long as infrastructure configuration is performed (1455) by the secondary control data center 1420.

[0128] Once the primary control datacenter becomes fully operational, the fault tolerant continuous delivery module 350 can switch control of the overall process of configuration of the tenant datacenters to the primary control datacenter 1410, making it the active control datacenter, and the secondary control datacenter 1420 the standby control datacenter, as shown in FIG. 14A.

[0129] In one embodiment, various steps are performed to perform the switchover from the primary control datacenter to the secondary control datacenter. The fault-tolerant continuous delivery module 351 first ensures that no new pipelines are triggered for execution in the primary control datacenter. The fault-tolerant continuous delivery module 350 then sends instructions to the primary control datacenter to complete all currently executing pipelines. Specifically, the fault-tolerant continuous delivery module 350 identifies all pipelines that are in a running state and sends instructions to complete their execution. The fault-tolerant continuous delivery module 350 changes the configuration of the continuous delivery request router 1220 to start directing all requests associated with continuous delivery and configuration of datacenters in the cloud platform to the secondary control datacenter instead of the primary control datacenter.

[0130] If a failure occurs in the primary control data center that prevents the primary data center from completing the execution of a pipeline, the fault-tolerant continuous delivery module 350 atomically fails the entire pipeline. The fault-tolerant continuous delivery module 350 causes the secondary control data center to execute all pipelines that failed to complete execution in the primary control data center. The operations performed during pipeline execution are idempotent. Thus, if an operation is performed multiple times, the effect of performing the operation on the system is the same as performing the operation once. For example, an operation to create a user account checks whether the account already exists and has the necessary access to system resources specified in the metadata of the tenant data center. If the account already exists and has the necessary access, the control data center takes no further action. If the account does not exist, the control data center creates the account. Similarly, when the system performs an action to configure a service, the system checks whether the configuration was performed before. If the configuration was performed before, the control data center skips the remaining steps. If the configuration has not been previously performed, the control data center performs steps to perform the configuration.

[0131] A process for fault-tolerant continuous delivery FIG. 15 illustrates a process for configuring a data center on a cloud platform using the fault-tolerant architecture of the control data center shown in FIG. 14, according to one embodiment.

[0132] The fault tolerant continuous delivery module 350 configures 1510 the primary control datacenter 1410 and the secondary control datacenter 1420 on a cloud platform. The fault tolerant continuous delivery module 350 accesses declarative specifications for the primary control datacenter 1410 and the secondary control datacenter 1420 and configures them on the cloud platform. The primary control datacenter 1410 and the secondary control datacenter 1420 may be configured on two different cloud platforms.

[0133] The fault tolerant continuous delivery module 350 receives 1520 a request to configure a tenant data center 1430 on a cloud platform. The tenant data center is associated with a tenant of a multi-tenant system. Although the process described in FIG. 15 is shown in the context of a multi-tenant system, the technique may be applied to any online system, for example, an online system of a single organization.

[0134] The fault tolerant continuous delivery module 350 sends 1530 instructions to the primary control datacenter 1410 to configure the tenant datacenter. The instructions sent to the primary control datacenter 1410 cause the primary control datacenter 1410 to perform the following steps: The primary control datacenter 1410 configures infrastructure for the tenant datacenter on the cloud platform, e.g., by creating user accounts according to the declarative specification and configuring computing resources of the cloud platform for access by the user accounts according to the declarative specification. The primary control datacenter 1410 periodically sends 1540 the state of the infrastructure configured for the tenant datacenter to the secondary control datacenter, e.g., the primary control datacenter 1410 periodically communicates information describing created user accounts and associated credentials to the secondary control datacenter 1420.

[0135] The fault tolerant continuous delivery module 350 sends a transmission command to the secondary control datacenter 1420 causing the secondary control datacenter to verify (1540) the infrastructure of the tenant datacenters configured by the primary control datacenter. For example, the secondary control datacenter 1420 verifies whether any user accounts created by the primary control datacenter 1410 and sent (1540) to the secondary control datacenter 1420 are accessible and have access to the required computing resources of the cloud platform.

[0136] FIG. 16 illustrates a process for handling a failure in a primary control data center, according to one embodiment.

[0137] The fault tolerant continuous delivery module 350 receives 1610 a request to transfer control of a configuration of a tenant datacenter on the cloud platform from a primary control datacenter to a secondary control datacenter. In response to receiving the request to transfer control, the fault tolerant continuous delivery module 350 redirects 1620 requests associated with the configuration of the tenant datacenter from the primary control datacenter to the secondary control datacenter.

[0138] The fault-tolerant continuous delivery module 350 sends 1630 an instruction to the secondary control datacenter 1420 to take over the process of configuration of the tenant datacenter. Thus, the secondary control datacenter 1420 performs the configuration of the tenant datacenter, for example, by creating user accounts and configuring computing resources of the cloud platform according to the declarative specification of the tenant datacenter. The secondary control datacenter 1420 sends 1640 the state of the configuration of the tenant datacenter to the primary control datacenter 1410. The primary control datacenter 1410 validates 1640 the infrastructure configured on the tenant datacenter by the secondary control datacenter 1420 to ensure that the created user accounts have the necessary access to computing resources of the cloud platform according to the declarative specification of the tenant datacenter.

[0139] The transfer of the configuration state of one control data center D1 to the other control data center D2 makes the process of transferring control from the control data center D1 to the other control data center D2 efficient, since the other control data center D2 does not have to repeat operations already performed by the control data center D1. The other control data center D2 can resume the configuration process from where the first control data center stopped the process.

[0140] Computer Architecture 17 is a high-level block diagram illustrating a functional view of an exemplary computer system for use as one of the entities depicted in the environment 100 of FIG. 1, according to one embodiment. Shown is at least one processor 1702 coupled to a chipset 1704. Further coupled to the chipset 1704 are memory 1706, storage 1708, keyboard 1710, graphics adapter 1712, pointing device 1714, and network adapter 1716. A display 1718 is coupled to the graphics adapter 1712. In one embodiment, the functionality of the chipset 1704 is provided by a memory controller hub 1720 and an I / O controller hub 1722. In another embodiment, the memory 1706 is coupled directly to the processor 1702 instead of the chipset 1704.

[0141] The storage device 1708 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 1706 holds instructions and data used by the processor 1702. The pointing device 1714, which may be a mouse, a trackball, or other type of pointing device, is used in combination with the keyboard 1710 to input data into the computer system 200. The graphics adapter 1712 displays images and other information on the display 1718. The network adapter 1716 couples the computer system 1700 to a network.

[0142] As is known in the art, computer 1700 may have different and / or other components than those depicted in Figure 17. Additionally, computer 1700 may lack certain illustrated components. For example, a computer system 1700 operating as a multi-tenant system 110 may lack keyboard 1710 and pointing device 1714. Additionally, storage device 1708 may be local and / or remote from computer 1700 (e.g., embodied within a storage area network (SAN)).

[0143] The computer 1700 is adapted to execute computer modules for providing the functions described herein. As used herein, the term "module" refers to computer program instructions and other logic for providing a specified 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 in the storage device 1708, loaded into the memory 1706, and executed by the processor 1702.

[0144] The type of computer system 1700 used by an entity in the system environment can vary depending on the embodiment and the processing power used by the entity. For example, a client device may be a mobile phone with limited processing power, a small display 1718, and no pointing device 1714. In contrast, a multi-tenant system or cloud platform may include multiple blade servers that work together to provide the functionality described herein.

[0145] Further considerations The particular naming of components, capitalization of terms, attributes, data structures, or any 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 system may be implemented through a combination of hardware and software as described, or entirely in hardware elements. Furthermore, 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.

[0146] 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. It will be understood that these operations, while described in functional or logical terms, are 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.

[0147] As is evident from the above discussion, unless specifically indicated otherwise, throughout the description, discussions utilizing terms such as "processing" or "calculating" or "computing" or "determining" or "displaying" are 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 memory or registers of the computer system, or other such information storage, transmission, or display device.

[0148] Certain embodiments described herein include process steps and instructions that are described 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 be downloaded to reside on and be operated from different platforms used by the real-time network operating system.

[0149] The described embodiments also relate to an 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 a computer program may be stored on a non-transitory computer-readable storage medium, such as, but not limited to, a floppy disk, an optical disk, a CD-ROM, any type of disk including a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an 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 for increased computing power.

[0150] The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct a 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. Moreover, 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 described herein.

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

[0152] Finally, it should be noted that the language used herein has been chosen primarily for ease of reading and instructional purposes, and may not have been chosen to delineate or limit the inventive subject matter. Accordingly, the disclosure of the embodiments is intended to be illustrative and not limiting.< / version> < / service>

Claims

1. 1. A computer-implemented method for configuring a data center on a cloud platform, comprising: configuring a primary control data center and a secondary control data center on the cloud platform; receiving a declarative specification for configuring a tenant datacenter on the cloud platform, the tenant datacenter being associated with a tenant of a multi-tenant system, the declarative specification describing a hierarchy of datacenter entities, one or more datacenter entities in the hierarchy representing service groups and one or more other datacenter entities in the hierarchy representing services for execution on the cloud platform; sending instructions to the primary control datacenter to configure the tenant datacenter, the instructions including instructions to the primary control datacenter to: configuring infrastructure for the tenant datacenter on the cloud platform, the infrastructure being configured for particular services represented by datacenter entities of the hierarchy of datacenter entities specified by the declarative specification; periodically transmitting a state of the infrastructure configured for the tenant datacenter to the secondary control datacenter; and executing a step including: receiving a request to transfer control of the tenant datacenter's configuration from the primary control datacenter to the secondary control datacenter; in response to receiving the request to transfer control, redirecting requests associated with configuration of the tenant datacenter from the primary control datacenter to the secondary control datacenter; A computer-implemented method comprising:

2. sending instructions to the secondary control datacenter, the instructions causing the secondary control datacenter to verify the infrastructure of the tenant datacenter configured by the primary control datacenter; The computer-implemented method of claim 1 , further comprising:

3. 2. The computer-implemented method of claim 1, wherein in response to receiving a request to transfer control, the secondary control datacenter resumes configuration of the infrastructure of the tenant datacenter from a current state received by the secondary control datacenter from the primary control datacenter.

4. 4. The computer-implemented method of claim 3, wherein resuming configuration of the infrastructure of one or more tenant datacenters from the current state causes the secondary control datacenter to perform operations previously performed by the primary control datacenter.

5. Configuring the tenant data center comprises: compiling the declarative specification to generate a pipeline for deploying the particular service on the cloud platform, the primary control data center executing the pipeline; 2. The computer-implemented method of claim 1, comprising:

6. 2. The computer-implemented method of claim 1, wherein configuring infrastructure for one or more tenant data centers includes creating a number of accounts on a cloud platform, each account configured according to a declarative specification of the tenant data center.

7. 2. The computer-implemented method of claim 1, wherein configuring infrastructure for one or more tenant datacenters includes creating one or more pipelines, each pipeline including a stage for configuring one or more datacenter entities for the tenant datacenter.

8. The computer-implemented method of claim 1 , wherein the tenant data center includes one or more service groups, each service group including a set of services.

9. The computer-implemented method of claim 1 , wherein a tenant datacenter comprises a hierarchy of datacenter entities, the datacenter entities comprising services or service groups, and each service group comprising a set of services.

10. 2. The computer-implemented method of claim 1, wherein in response to resuming configuration of the infrastructure of one or more tenant datacenters by the secondary control datacenter, the secondary control datacenter periodically transmits to the primary control datacenter a state of infrastructure configured for the tenant datacenters.

11. The request to transfer control of a configuration of one or more data centers on the cloud platform from the primary control data center to the secondary control data center includes: a failure of one or more services of said primary control data center; planned maintenance of one or more services of said primary control data center; data corruption in the data store of the primary control data center; or A security breach at the primary control data center 13. The computer-implemented method of claim 1, wherein the method is received in response to one or more of:

12. The computer-implemented method of claim 1 , wherein the primary control data center is in a first cloud platform and the secondary control data center is in a second cloud platform.

13. 1. A non-transitory computer-readable storage medium for storing instructions that, when executed by one or more computer processors, cause the one or more computer processors to perform steps for configuring a data center on a cloud platform, the steps comprising: configuring a primary control data center and a secondary control data center on the cloud platform; receiving a declarative specification for configuring a tenant datacenter on the cloud platform, the tenant datacenter associated with a tenant of a multi-tenant system, the declarative specification describing a hierarchy of datacenter entities, one or more datacenter entities in the hierarchy representing service groups and one or more other datacenter entities in the hierarchy representing services for execution on the cloud platform; and transmitting instructions to the primary control datacenter to configure the tenant datacenter, the instructions including instructions to the primary control datacenter to: configuring infrastructure for the tenant datacenter on the cloud platform, the infrastructure being configured for particular services represented by datacenter entities of the hierarchy of datacenter entities specified by the declarative specification; periodically transmitting a state of the infrastructure configured for the tenant datacenter to the secondary control datacenter; and causing the device to execute steps including: receiving a request to transfer control of the tenant datacenter's configuration from the primary control datacenter to the secondary control datacenter; in response to receiving the request to transfer control, redirecting requests associated with configuration of the tenant datacenter from the primary control datacenter to the secondary control datacenter; A non-transitory computer readable storage medium comprising:

14. The instructions further cause the one or more computer processors to: sending instructions to the secondary control datacenter, the instructions causing the secondary control datacenter to verify the infrastructure of the tenant datacenter configured by the primary control datacenter; 14. The non-transitory computer-readable storage medium of claim 13, further comprising:

15. 14. The non-transitory computer-readable storage medium of claim 13, wherein in response to receiving a request to transfer control, the secondary control datacenter resumes configuration of the infrastructure of the tenant datacenter from a current state received by the secondary control datacenter from the primary control datacenter.

16. 20. The non-transitory computer-readable storage medium of claim 15, wherein resuming configuration of the infrastructure of one or more tenant datacenters from the current state causes the secondary control datacenter to perform operations previously performed by the primary control datacenter.

17. 14. The non-transitory computer-readable storage medium of claim 13, wherein configuring infrastructure for one or more tenant data centers includes creating a number of accounts on a cloud platform, each account configured according to a declarative specification for the tenant data center.

18. 14. The non-transitory computer-readable storage medium of claim 13, in response to resuming configuration of the infrastructure of one or more tenant datacenters by the secondary control datacenter, periodically transmitting a state of infrastructure configured for the tenant datacenters by the secondary control datacenter to the primary control datacenter.

19. The request to transfer control of a configuration of one or more data centers on the cloud platform from the primary control data center to the secondary control data center includes: a failure of one or more services of said primary control data center; planned maintenance of one or more services of said primary control data center; data corruption in the data store of the primary control data center; or A security breach at the primary control data center 14. The non-transitory computer-readable storage medium of claim 13, received in response to one or more of:

20. 1. A computing system comprising: one or more computer processors; a non-transitory computer-readable storage medium for storing instructions that, when executed by the one or more computer processors, cause the one or more computer processors to perform steps for configuring a data center on a cloud platform; and The steps include: configuring a primary control data center and a secondary control data center on the cloud platform; receiving a declarative specification for configuring a tenant datacenter on the cloud platform, the tenant datacenter associated with a tenant of a multi-tenant system, the declarative specification describing a hierarchy of datacenter entities, one or more datacenter entities in the hierarchy representing service groups and one or more other datacenter entities in the hierarchy representing services for execution on the cloud platform; and transmitting instructions to the primary control datacenter to configure the tenant datacenter, the instructions including instructions to the primary control datacenter to: configuring infrastructure for the tenant datacenter on the cloud platform, the infrastructure being configured for particular services represented by datacenter entities of the hierarchy of datacenter entities specified by the declarative specification; periodically transmitting a state of the infrastructure configured for the tenant datacenter to the secondary control datacenter; and causing the device to execute steps including: receiving a request to transfer control of the tenant datacenter's configuration from the primary control datacenter to the secondary control datacenter; in response to receiving the request to transfer control, redirecting requests associated with configuration of the tenant datacenter from the primary control datacenter to the secondary control datacenter; A computing system comprising:

Images