Techniques for building data centers using skill services

Abstract

A cloud computing service (e.g., a "Puffin service") is described. The service may maintain service and skill directories corresponding to various services to be deployed to the area (e.g., during area build). The service may hosting multiple user interfaces through which various service and skill metadata may be provided. In some embodiments, such data may include one or more dependencies between skills. Data managed by the cloud computing service may be used to construct a dependency graph. Navigation of the dependency graph may be performed via one or more user interfaces hosted by the cloud computing service. An orchestration service (e.g., a multi-group orchestrator) may manage the bootstrap work of any suitable number of services during area build based at least in part on dependencies between skills.

Description

[0001] Cross-reference to related applications

[0002] This non-provisional application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 503,143, filed May 18, 2023, entitled “Techniques for Validating and Tracking Region Build Skills,” and U.S. Non-Provisional Patent Application No. 18 / 498,964, filed October 31, 2023, entitled “Techniques for Building a Data Center using a SkillsService,” the disclosures of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This disclosure relates to technologies for constructing data centers (e.g., orchestrating various resources within a data center). These technologies may leverage a skills service configured to track builds using constructs called “skills.” Skills may be scoped (e.g., controlled via access and authorization policies), versioned, affixed to specific services or contacts, associated with a lifecycle, and their health may be monitored during the processing of build data inputs. The skills service may provide an authoritative registry of these skills and may maintain dependencies between skills. The skills service may generate blueprints of build-time and runtime dependencies. These blueprints may be used to validate build plans, drive orchestration decisions, and improve time-to-engage and time-to-diagnose metrics during regional builds and / or large-scale events (LSEs) (e.g., power outages, network failures, etc.). Background Technology

[0004] Today, cloud infrastructure services utilize many separate services to build data centers (e.g., orchestrating various resources within data centers in a specific geographic region). In some examples, a region is a logical abstraction corresponding to a local geographic area where one or more data centers are located (or will be located). Building a data center may include provisioning and configuring infrastructure resources and deploying code to those resources (e.g., for various services). The operations used to build a data center can be collectively referred to as performing a "region build." A region can include any suitable number of data centers, so a region build may include operations for building multiple data centers. The orchestration operation for a service may depend on other features and / or services that may not yet be available in that region. As the number of service teams and regions grows, the tasks performed for orchestration provisioning and deployment increase dramatically. Conventional tools for building regions require significant manual work, or automation technologies are deficient in terms of overhead, accuracy, and ease of use. Improvements are possible. Summary of the Invention

[0005] Embodiments of this disclosure relate to techniques for performing automated region construction (e.g., guiding (e.g., provisioning and / or deployment) of resources (e.g., infrastructure components, artifacts, etc.) within a region (e.g., a geographic location associated with one or more data centers) for any suitable number of services.

[0006] At least one embodiment relates to a computer-implemented method. The method may include preparing a user interface by a cloud computing service (e.g., a cloud computing service in a cloud computing environment), the user interface being configured to receive corresponding skill metadata defining multiple skills corresponding to multiple services to be bootstrapped during the construction of a region corresponding to a data center. The method may also include (e.g., by the cloud computing service) maintaining a first skill among the multiple skills and a second skill among the multiple skills. In some embodiments, the first skill corresponds to a first service function, and the second skill corresponds to a second service function. The first skill may indicate a dependency on the second skill. The method may also include generating a dependency graph by the cloud computing service based at least in part on the multiple skills corresponding to the multiple services. In some embodiments, the dependency graph indicates a dependency between the first skill and the second skill. The method may also include providing at least a portion of the dependency graph to a user device by the cloud computing service for presentation at a user interface. In some embodiments, the user interface provides navigation options associated with navigation within the dependency graph. In some embodiments, the dependency graph represents a construction dependency graph used by an orchestrator to bootstrap multiple services during data center construction. The method may include constructing the data center using an orchestrator. The method may include traversing the dependency graph to manage the order in which multiple services are bootstrapped. The orchestrator can identify when it can bootstrap a service among multiple services, when to block bootstrap, and / or when to resume bootstrap operations associated with a previously blocked service. The orchestrator can identify one or more circular dependencies in the dependency graph. The orchestrator can transmit bootstrap instructions to the central component of the cloud infrastructure orchestration system. Instructions may include multiple sets of instructions for breaking one or more circular dependencies identified in the graph.

[0007] In some embodiments, each of a plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states. In some embodiments, at least one lifecycle state is associated with one or more lifecycle sub-states, and each lifecycle sub-state indicates a health status corresponding to a skill.

[0008] In some embodiments, the computer-implemented method may further include verifying the build dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

[0009] In some embodiments, cloud service management may present a service catalog at one or more user interfaces hosted by cloud service management. In some embodiments, cloud service management may present a skills catalog at one or more user interfaces hosted by cloud service management.

[0010] In some embodiments, the computer-implemented method further includes identifying obstacles in building a data center using a cloud computing service. The method may also include identifying potential contributors to a second skill being an obstacle, based at least in part on a dependency graph generated by the cloud computing service. The method may also include presenting indications that a second skill is a potential contributor to an obstacle.

[0011] In some embodiments, the computer-implemented method further includes monitoring one or more indications that the status corresponding to an individual skill among a plurality of skills has changed. The method may also include updating one or more attributes associated with the individual skill by a cloud computing service to reflect the status change. In some embodiments, the orchestrator initiates bootstrapping operations associated with bootstrapping multiple services during data center construction, based at least in part on the status change corresponding to the individual skill.

[0012] Another embodiment relates to a cloud computing service including one or more processors and a memory storing instructions that, when executed by one or more processors, cause the cloud computing service to perform one or more methods disclosed herein.

[0013] Another embodiment relates to a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a cloud computing service, cause the cloud computing service to perform one or more methods disclosed herein. Attached Figure Description

[0014] To facilitate identification of any discussion of a particular element or action, the leftmost one or more numbers in the reference numbering refer to the figure number in which the element was first introduced.

[0015] Figure 1 It is a block diagram of an environment in which a cloud infrastructure orchestration system (CIOS) including multiple components (e.g., Puffin hub and Puffin region) of skill services, according to at least one embodiment, can operate to dynamically provide bootstrapping services in a region.

[0016] Figure 2 It is a block diagram illustrating an environment and method for constructing a Virtual Boot Environment (ViBE) according to at least one embodiment.

[0017] Figure 3 This is a block diagram illustrating an environment and method for routing services to a target area using ViBE, according to at least one embodiment.

[0018] Figure 4 It is a block diagram depicting a data model representing various metadata related to skills according to at least one embodiment.

[0019] Figure 5This is a block diagram depicting an example user interface configured to present a service catalog according to at least one embodiment.

[0020] Figure 6 This is a block diagram depicting an example user interface configured to present metadata associated with a single service, according to at least one embodiment.

[0021] Figure 7 It is a block diagram depicting an example user interface related to a skills catalog according to at least one embodiment.

[0022] Figures 8-12 This includes corresponding block diagrams depicting several example user interfaces related to creation skills according to at least one embodiment.

[0023] Figure 13 It is a block diagram depicting an example user interface for creating skill groups according to at least one embodiment.

[0024] Figure 14 This is a block diagram depicting an example user interface for editing skill groups according to at least one embodiment.

[0025] Figure 15 It is a block diagram depicting an example user interface that presents information associated with a selected skill according to at least one embodiment.

[0026] Figure 16 It is a block diagram depicting an example lifecycle of a skill according to at least one embodiment.

[0027] Figure 17 This is a flowchart illustrating an example method of performing region construction using components of a skill service (e.g., Puffin Hub and Puffin Region) according to at least one embodiment.

[0028] Figure 18 This is a block diagram illustrating a pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0029] Figure 19 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0030] Figure 20 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0031] Figure 21 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0032] Figure 22This is a block diagram illustrating an example computer system according to at least one embodiment. Detailed Implementation

[0033] In the following description, specific details are set forth for purposes of explanation in order to provide a thorough understanding of certain embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and descriptions are not intended to be limiting. The word “exemplary” as used herein means “serving as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” is not necessarily to be construed as preferred or superior to other embodiments or designs.

[0034] Example of automated data center construction (regional construction) infrastructure

[0035] The adoption of cloud services has increased rapidly recently. Currently, various cloud service providers (CSPs) offer a wide range of cloud services. The term "cloud service" generally refers to services or functions provided by a CSP to users or customers on demand (e.g., via a subscription model) using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that constitute the CSP's infrastructure and are used to provide cloud services to customers are separate from the customer's own on-premises servers and systems. Therefore, customers can utilize cloud services provided by the CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide subscribers with simple, scalable, and on-demand access to applications and computing resources without requiring customers to invest in the infrastructure used to provide the services or functions. Various types or models of cloud services can be provided, such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), etc. Customers can subscribe to one or more cloud services provided by a CSP. Customers can be any entity, such as individuals, organizations, enterprises, etc.

[0036] As described above, the CSP is responsible for providing the infrastructure and resources used to deliver cloud services to subscribers. The resources provided by the CSP can include hardware and software resources. These resources may include, for example, computing resources (e.g., virtual machines, containers, applications, processors), storage resources (e.g., databases, data repositories), networking resources (e.g., routers, host machines, load balancers), identity, and other resources. In some implementations, the resources provided by the CSP for delivering a set of cloud services are organized into a data center. A data center can be configured to provide a specific set of cloud services. The CSP is responsible for equipping the data center with the infrastructure and resources used to deliver that specific set of cloud services. The CSP may build one or more data centers.

[0037] Data centers provided by a CSP can be hosted in different regions. A region is a local geographic area and can be identified by its name. Regions are typically independent of each other and can be geographically distant, such as spanning countries or even continents. Regions are grouped into realms. Examples of regions provided by a CSP could include the western United States, the eastern United States, eastern Australia, southeastern Australia, etc.

[0038] A region can include one or more data centers located within a specific geographic area corresponding to that region. As an example, a data center within a region could be located in a city within that region. For instance, for a specific CSP, a data center for the Western United States region could be located in San Jose, California; a data center for the Eastern United States region could be located in Ashburn, Virginia; a data center for the Eastern Australia region could be located in Sydney, Australia; a data center for the Southeastern Australia region could be located in Melbourne, Australia; and so on.

[0039] Data centers within a region can be organized into one or more availability domains for high availability and disaster recovery purposes. An availability domain can include one or more data centers within the region. Availability domains within a region are isolated and fault-tolerant of each other, and their architecture is designed to make it unlikely that data centers in multiple availability domains will fail simultaneously. For example, availability domains within a region can be configured such that a failure in one availability domain within the region is unlikely to affect the availability of data centers in other availability domains within the same region.

[0040] When a customer or subscriber subscribes to or registers for one or more services offered by a CSP, the CSP creates a lease for the customer. A lease is like an account created for the customer. In some implementations, a customer's lease exists within a single domain and has access to all areas belonging to that domain. The customer's user can then access the services subscribed to under this lease.

[0041] As mentioned above, CSPs build or deploy data centers to provide cloud services to their customers. As a CSP's customer base grows, it typically builds new data centers in new regions or increases the capacity of existing data centers to meet growing customer demand and better serve them. Preferably, data centers are built in geographical locations very close to the customers served by the data center. Geographical proximity between the data center and the customers served by it facilitates more efficient resource utilization and provides faster and more reliable service. Therefore, CSPs often build new data centers in new regions geographically close to the customers served by the data center. For example, for a growing customer base in Germany, a CSP might build one or more data centers in new regions of Germany.

[0042] Building a data center (or multiple data centers) within a region is sometimes also referred to as building a region. The term "region building" is used to refer to building one or more data centers within a region. Building a data center within a region involves provisioning or creating a new set of resources that are required or used to provide a set of services that the data center is configured to offer. The end result of the region building process is the creation of a data center within a region, where the data center is capable of providing a set of services designed for that data center and includes a set of resources for providing those services.

[0043] Building a new data center within a region is a highly complex activity requiring coordination among various teams. At a high level, this involves executing and coordinating a variety of tasks, such as: identifying the set of services to be provided by the data center; identifying the various resources required to provide these services; creating, provisioning, and deploying the identified resources; properly connecting the resources so they can be used as intended; and so on. Each of these tasks further comprises sub-tasks requiring coordination, which further increases the complexity. Due to this complexity, building a data center within a region currently involves several manually initiated or controlled tasks that require careful manual coordination. Therefore, the task of building a new region (i.e., building one or more data centers within a region) is very time-consuming. Building a data center can take, for example, months. Furthermore, this process is highly error-prone, sometimes requiring several iterations to achieve the desired configuration of the data center, further increasing the time required for data center construction. These limitations and issues severely restrict the ability of CSPs to grow in a timely manner to respond to increasing customer demands.

[0044] Embodiments of this disclosure relate to techniques for performing automated region building (e.g., bootstrapping (e.g., provisioning and / or deploying) resources (e.g., infrastructure components, artifacts, etc.) of any suitable number of services within a region (e.g., a geographic location associated with one or more data centers). Bootstrapping operations can be coordinated and orchestrated by an orchestrator (e.g., a multi-flock orchestrator, orchestration service, etc.). In previous embodiments, the orchestrator attempted to automatically detect dependencies between operations. The orchestrator maintained various versions of configuration files and / or software artifacts and attempted to intelligently and automatically identify the specific set of versions to be performed on the region build. When building the region, the orchestrator leveraged capabilities (e.g., flags that can be turned on or off to indicate the availability of resources or features) to drive these operations. However, both the automatic detection techniques and the use of capabilities have drawbacks. Embodiments of this disclosure provide improvements over previous implementations.

[0045] Today, during large-scale incidents (LSEs) – such as incidents experiencing significant errors or delays during region builds – incident management and region build operators often incur extensive overhead and sometimes delays in areas such as status gathering, problem attribution, impact assessment, and service restoration, due to the heavy human-based and unsystematic nature of conventional methods. Identifying the contributing factors to an incident can be extremely difficult and time-consuming due to the complexity of various dependencies between services. This leads to delays in remediation and a reduced ability to assess when an incident will end. Similarly, region builds face challenges because human involvement may be required to troubleshoot and / or detect faults or prevent situations. Typically, service teams struggle to determine which dependencies exist within their services. Services may have dependencies on other services, and vice versa. Furthermore, service teams lack comprehensive metrics regarding whether their region build design will present serious problems that hinder or delay service builds (such as circular dependencies) prior to actual region builds.

[0046] Technical effect

[0047] The techniques discussed in this paper include leveraging new constructs (e.g., “skills”) that extend the previous concept of capabilities and enable improvements to previous capability-based implementations. For example, skills can be scoped (e.g., controlled via access and authorization policies), versioned, and affixed to specific services or contacts. Skills can be associated with a lifecycle, monitored for health, and designed to be more visible / accessible than capabilities. A skills service (e.g., called “Puffin”) can provide an authoritative registry for services. Various user interfaces managed by this service can be used to define, maintain, and manage the skills offered by each service and their dependencies on other services. Using this approach, Puffin can be used to declare and persist strongly defined metadata for services in a versioned manner. This metadata can be used to generate blueprints of build-time and runtime dependencies. These blueprints can be used to validate build plans, drive orchestration decisions during regional builds, and improve engagement and diagnostic time metrics during regional builds and / or LSE events. Puffin is designed to remove operational overhead, improve information accuracy, and present key data, including the ability to visually represent interconnected service skill dependencies. Puffin provides health information and stores runtime and build-time dependencies to infer service-to-service dependencies. These technologies improve error detection and facilitate root cause analysis, enhance understanding of services, builds, and / or events, reduce the risk of errors, shorten recovery time, and offer other benefits.

[0048] Some definitions

[0049] A "region" is a logical abstraction corresponding to a geographical location. A region can include any suitable number or more execution targets. In some embodiments, an execution target can correspond to a data center.

[0050] An "execution target" is a unit of change used to perform a release. A release is an indication of an intent to orchestrate specific changes to a service (e.g., deploying version 8, adding an internal DNS record, etc.). For most services, an execution target represents an "instance" of the service. A single service can be directed to each of one or more execution targets. Execution targets can be associated with a set of devices (e.g., a data center).

[0051] "Guidance" is intended to refer to a collective task associated with the provisioning and deployment of any appropriate number of resources (e.g., infrastructure components, artifacts, etc.) corresponding to a single service.

[0052] A "service" refers to functionality provided by a set of resources. This set of resources includes any suitable combination of infrastructure, platforms, or software (e.g., applications) hosted by a cloud provider and configured to provide the functionality. Services can be made available to users via the Internet.

[0053] "Artifacts" refer to code deployed to infrastructure components (e.g., physical or virtual hosts) or Kubernetes engine clusters, which may include, but are not limited to, software (e.g., applications), configuration information of infrastructure components (e.g., configuration files), etc.

[0054] A "group configuration" refers to a configuration file (or a set of configuration files) that describes a group of all resources (e.g., infrastructure components and artifacts, also known as a "group") associated with a single service. A group configuration may include declarative statements that specify one or more aspects corresponding to the desired state of the service's resources.

[0055] "Service status" refers to a point-in-time snapshot of each resource (e.g., infrastructure resources, artifacts, etc.) associated with a service. Service status indicates the condition of the provisioning and / or deployment tasks associated with the service resource.

[0056] IaaS provisioning (or "provisioning") refers to acquiring a computer or virtual host for use, and even installing necessary libraries or services on it. The phrase "provisioning device" refers to the state in which a device is evolved to the point where an end user can use it for their specific purpose. A device that has undergone provisioning can be called a "provisioned device." Preparing a provisioned device (installing libraries and daemons) can be part of provisioning; this preparation is different from deploying a new application or a new version of an application to a prepared device. In most cases, deployment does not include provisioning, and provisioning may need to be performed first. Once ready, the device can be called an "infrastructure component."

[0057] IaaS deployment (or "deployment") refers to the process of providing and / or installing new applications or new versions of applications on provisioned infrastructure components. Once the infrastructure components have been provisioned (e.g., acquired, assigned, prepared, etc.), additional software can be deployed (e.g., provided to and installed onto the infrastructure components). After provisioning and deployment are complete, the infrastructure components can be referred to as "resources". Examples of resources may include, but are not limited to, virtual machines, databases, object storage, block storage, load balancers, etc.

[0058] A Virtual Boot Environment (ViBE) is a virtual cloud network provisioned within the coverage of an existing region (e.g., a "host region"). Once provisioned, the ViBE connects to the new region using a communication channel (e.g., an IPSec tunnel VPN). Certain essential core services (or "seed" services), such as deployment orchestrators and public key infrastructure (PKI) services, can be provisioned in the ViBE. These services provide the capabilities needed to bring hardware online, establish a chain of trust to the new region, and deploy the remaining services in the new region. Utilizing a Virtual Boot Environment can prevent circular dependencies between boot resources by leveraging the resources of the host region. Services can be staging and tested in the ViBE before they become available in the physical region (e.g., the target region).

[0059] "Cloud Infrastructure Orchestration Service" (CIOS) can refer to a system configured to manage the provisioning and deployment operations of any appropriate number of services as part of a region's architecture.

[0060] "Host Zone" refers to the zone that hosts the Virtual Boot Environment (ViBE). The host zone can be used to boot the ViBE.

[0061] "Target area" refers to the area that is under construction.

[0062] A "capability" identifies resources used during the construction of an area, signaling the availability of another resource, service, or feature, or indicating that an event has occurred. For example, a capability can be published to indicate that a resource is available for authorization / authentication processing (e.g., a subset of functionality to be provided by the resource). As another example, a capability can be published to indicate that the full functionality of a service is available. Capabilities can be used to identify the functionality that a resource or service depends on and / or the functionality of the available resource or service. Capabilities can be associated with alphanumeric identifiers and can be used to indicate whether the capability is available or unavailable.

[0063] "Publish capability" refers to "publishing" as used in a publisher-subscriber computing design, or otherwise providing an indication that a particular capability is available (or unavailable). A capability is "published" (e.g., collected by a capability service, provided to a capability service, pushed, pulled, etc.) to provide an indication that a resource / service is available. In some embodiments, capabilities can be published / transmitted via events, notifications, data transfers, function calls, API calls, etc. Events (or other notifications / data transfers / etc.) indicating the availability of a particular capability can be broadcast / addressed (e.g., published) to the capability service.

[0064] A "capability service" can be a service configured to monitor dependencies between different groups. Capability services can be provided within cloud infrastructure orchestration services and can be used to identify which capabilities, services, and features are available in a region. The described capability service can serve as a central repository / authority for all capabilities published in a region (e.g., during region build).

[0065] An "orchestrator" is defined as a service or system that initiates and guides the tasks involved in one or more services during the construction of a region.

[0066] A Multi-Group Orchestrator (MFO) is an example of an orchestrator that can be a compute component (e.g., a service) configured to coordinate events between components of CIOS to automatically provision and deploy services to a target region (e.g., a new region). An MFO can track relevant events for each service built into a region (e.g., via capability indications) and take action in response to these events (e.g., based on capability releases or other indications of capability availability).

[0067] A "Real-Time Region Data Distributor" (RRDD) can be a service or system configured to manage region data. This region data can be injected into a group configuration to dynamically create execution targets for new regions.

[0068] A “skill service” (also known as a “Puffin”) can be a service or system that is configured as a unit of storage service, resource, or function (also known as a “service function”) with planned and / or actual dependencies. It should be recognized that a unit of function can involve functionality provided by computing components other than services.

[0069] "Telemetry service" can be a service or system that manages / monitors various alarms and their corresponding alarm statuses.

[0070] A Service Plan and Inventory (SPAM) is a deterministic specification of the processes used to build a service. In some embodiments, a SPAM details the combination and order of releases required to build the service. The SPAM inventory can define all the resources to be used, while the service plan specifies the execution plan based on dependencies (via skill expressions).

[0071] The term "skill" is intended to refer to an improved version of a capability. A skill can represent a functional unit that a service exposes and provides to users (e.g., other services). This functional unit (also referred to as a "service function") can include all or a subset of the functions associated with the service. In some embodiments, a skill can be scoped, where access is controlled based on access and / or authorization policies and / or association with a specific namespace. A skill can be provided in multiple versions, where one or more aspects of the skill differ from other versions, and each skill version represents a specific implementation of the skill. Each skill version can be identified using a unique skill identifier. In some embodiments, a skill can correspond to one or more previously defined capabilities to provide backward compatibility with previous capability-based region-based implementations. The health of a skill can be monitored, and skills can be configured to maintain health data. "Skill" can uniformly refer to any suitable number of data structures in which data defining the skill can be maintained (e.g., Figure 4 Skill metadata 404).

[0072] In some examples, this document describes technologies for implementing Cloud Infrastructure Orchestration Services (CIOS). As briefly described above, these technologies can be configured to manage the bootstrapping (e.g., provisioning and deployment of software) of infrastructure components within a cloud environment (e.g., a region). In some cases, CIOS may include compute components (e.g., CIOS hubs and CIOS regions, both described in further detail below) that can be configured to manage bootstrapping tasks (provisioning and deployment) for a given service, and orchestrators (e.g., multi-group orchestrators, also described in further detail below) configured to initiate / manage region builds (e.g., bootstrapping operations corresponding to multiple services within a region).

[0073] CIOS enables regional and global infrastructure building and code deployment with minimal manual runtime work from service teams (e.g., in some cases, beyond initial approval and / or physical transport of hardware). Advanced responsibilities of CIOS include, but are not limited to, coordinating regional builds in an automated manner with minimal human intervention, providing users with a view of the current state of resources managed by CIOS (e.g., regional, cross-regional, global, etc.), and managing bootstrap operations for bootstrap resources within a region.

[0074] CIOS can provide view reconciliation, where a view of the desired state (e.g., desired configuration) of a resource can be reconciled with the resource's current / actual state (e.g., current configuration). In some cases, view reconciliation may include obtaining state data to identify which resources are actually running and their current configuration and / or state. Reconciliation can be performed at various granularities, such as at the service level.

[0075] CIOS can perform plan generation, which involves identifying the difference between the desired state and the current state of a resource. Part of plan generation can include identifying the actions that need to be performed to change the resource from its current state to its desired state. Once the user is satisfied with the plan, it can be marked as approved or rejected. Therefore, users spend less time thinking about plans, and because the plans are machine-generated, they are more accurate. Plans are almost too detailed for human use; however, CIOS can provide this data through a sophisticated user interface (UI).

[0076] In some examples, CIOS can handle change management by automating the execution of approved plans. Once the execution plan is created and approved, engineers may no longer need to be involved in change management unless CIOS initiates a rollback. CIOS can handle rollbacks to previous service versions (e.g., when CIOS detects a decline in service health during execution) by automatically generating plans that revert the service to a previous (e.g., pre-release) state.

[0077] CIOS can measure service health by monitoring alerts and executing integration tests. CIOS helps teams quickly define rollback actions in the event of service degradation, which can then be executed automatically. CIOS can automatically generate and display plans and track approvals. CIOS combines provisioning and deployment capabilities into a single system that coordinates these tasks in region building. CIOS also supports automated discovery of groups (e.g., service resources, such as group configurations corresponding to any appropriate number of services), artifacts, resources, and dependencies. CIOS can discover dependencies between execution tasks at each level (e.g., resource level, execution target level, phase level, service level, etc.) through static analysis of one or more profiles (e.g., including parsing and processing content). Using these dependencies, CIOS can generate various data structures that can be used to drive task execution (e.g., tasks related to the provisioning of infrastructure resources and the deployment of artifacts across regions).

[0078] Figure 1 This is a block diagram of an environment 100 in which a Cloud Infrastructure Orchestration System (CIOS) 102, comprising multiple components including a Skills Service Center (Puffin Center) 118 and a Skills Service Region (Puffin Region) 120, can operate to dynamically provide guided services in regions, according to at least one embodiment. CIOS 102 may include, but is not limited to, the following components: Real-time Regional Data Distributor (RRDD) 104, Orchestrator 106, CIOS Center 108, CIOS Region 110, Capability Service 112, Puffin Center 118, and Puffin Region 120. Specific functionality provided by CIOS Center 108 and CIOS Region 110 is described in more detail in U.S. Application No. 17 / 016,754 entitled “Techniques for Deploying Infrastructure Resources with a Declarative Provisioning Tool,” the entire contents of which are incorporated herein by reference for all purposes. In some embodiments, any suitable combination of the components of CIOS 102 may be provided as a service. In some embodiments, a portion of CIOS 102 may be deployed to a region (e.g., a data center represented by host region 103). In some embodiments, CIOS 102 may include any suitable number of cloud services ( Figure 1 (Not shown in the image), these cloud services are listed in U.S. application No. 17 / 016,754 and below regarding... Figure 2 and Figure 3 A more detailed discussion was held.

[0079] The Real-Time Region Data Distributor (RRDD) 104 can be configured to maintain and provide region data that identifies domains, regions, execution targets, and availability domains. In some cases, region data can be in any suitable format (e.g., JSON, data objects / containers, XML, etc.). The region data maintained by RRDD 104 can include any suitable number of data subsets, which can be individually referenced by corresponding identifiers. For example, the identifier "all_regions" can be associated with a data structure (e.g., a list, structure, object, etc.) that includes metadata for all defined regions. As another example, identifiers (such as "realms") can be associated with a data structure that identifies several domains and a set of regions corresponding to each domain. Generally, region data can maintain any suitable attributes such as identifiers, DNS suffixes, status (e.g., region status), etc., for one or more domains, regions(one or more), availability domains (AD), execution targets(one or more) etc. RRDD 104 can be configured to manage region status as part of the region data. Region status can include any suitable information indicating the state of bootstrapping within a region. For example, some sample region states may include "Initial," "Build," "Production," "Paused," or "Deprecated." The "Initial" state may indicate a region that has not yet been bootstrapped. The "Build" state may indicate that bootstrapping for one or more groups within the region has begun. The "Production" state may indicate that bootstrapping has been completed and the region is ready for validation. The "Paused" state may indicate that CIOS Central 108 or CIOS Region 110 has paused internal interactions with the region stack, possibly due to operational issues. The "Deprecated" state may indicate that the region has been deprecated and may be unavailable and / or will not be contacted again.

[0080] CIOS Center 108 is configured to provide any suitable number of user interfaces through which users (e.g., user 109) can interact with CIOS 102. For example, a user can modify region data via the user interfaces provided by CIOS Center 108. CIOS Center 108 may also provide various interfaces that enable users to: view changes made to group configurations and / or artifacts, generate and view plans, approve / reject plans, and view the status of plan execution (e.g., tasks corresponding to the desired status of infrastructure provisioning, deployment, region building, and / or any suitable number of resources managed by CIOS 102). CIOS Center 108 may implement a control plane configured to manage any suitable number of CIOS Region 110 instances. CIOS Center 108 may provide one or more user interfaces to present region data, enabling user 109 to view and / or modify the region data. CIOS Center 108 may be configured to invoke the functions of RRDD 104 via any suitable number of interfaces. Generally, CIOS Center 108 (also known as the "Supply and Deployment Manager") can be configured to manage region data directly or indirectly (e.g., via RRDD 104). CIOS Center 108 can be configured to compile group configurations to inject region data as variables into the group configurations.

[0081] Each instance of CIOS Zone 110 may correspond to a module configured to perform bootstrapping tasks associated with a single service in the zone. CIOS Zone 110 may receive expected state data from CIOS Center 108. In some embodiments, expected state data may include group configurations that (e.g., via declarative statements) declare the expected state of resources associated with the service. CIOS Center 108 may maintain current state data that indicates any suitable aspect of the current state of resources associated with the service. In some embodiments, CIOS Zone 110 may identify the need for changes to one or more resources by comparing expected state data and current state data. For example, CIOS Zone 110 may determine that one or more infrastructure components need to be provisioned, one or more artifacts need to be deployed, or any suitable changes need to be made to the resources of the service to bring their state into alignment with the expected state. When CIOS Zone 110 performs bootstrapping operations, it may publish data indicating the capabilities of the resources as various capabilities become available. A “capability” identifies a functional unit associated with a service. A unit may be a subset or all of the functionality that the service will provide. For example, capabilities may be published to indicate that a resource is available for authorization / authentication processing (e.g., a subset of the functionality that the resource will provide). As another example, capabilities can be published to indicate that the full functionality of a service is available. Capabilities can be used to identify the functionality that a resource or service depends on and / or the functionality of the resource or service that is available for use.

[0082] Capability service 112 is configured to maintain capability data indicating 1) which capabilities of various services are currently available, 2) whether any resources / services are waiting for a specific capability, 3) which specific resources and / or services are waiting for a given capability, or any suitable combination of the above. Capability service 112 can provide an interface that can request capability data. Capability service 112 can provide one or more interfaces (e.g., application programming interfaces) that enable it to transfer capability data to orchestrator 106, CIOS region 110 (e.g., each instance of CIOS region 110), Puffin region 120, and / or Puffin center 118. In some embodiments, capability service 112 can store capability data in a data repository accessible to one or more components of CIOS 102. Orchestrator 106, CIOS region 110 (e.g., each instance of CIOS region 110), Puffin region 120 and / or Puffin center 118, and / or any suitable component or module of CIOS region 110 may be configured to request capability data from capability service 112, or otherwise obtain capability data (e.g., from a data repository configured to store capability data generated by capability service 112). While capability service 112 is depicted as a separate component of CIOS 102, it should be recognized that in some embodiments, the functionality provided by capability service 112 may be provided, in whole or in part, as part of a skill service via any suitable combination of Puffin center 118 and Puffin region 120.

[0083] In some embodiments, each region component (such as CIOS region 110, capability service 112, Puffin region 120, and / or virtual boot environment 116) can be one of many region components. Each region component can be specific to a given region (e.g., such as...). Figure 1 (As illustrated in the diagram, host region 103). Therefore, another region may include similar but separate region-specific components. In some embodiments, central components (e.g., orchestrator 106, CIOS center 108, RRDD 104, and Puffin center 118) may include one or more components configured to manage build operations corresponding to one or more regions. For example only, a single orchestrator (orchestrator 106) may be used to manage bootstrapping operations for building any suitable number of data centers, or multiple instances of orchestrator 106 may be used, each instance driving bootstrapping operations for a subset or a single data center of these data centers.

[0084] In some embodiments, orchestrator 106 (an example of which may be a multi-group orchestrator) may be configured to drive region building operations. In some embodiments, orchestrator 106 may manage information describing which groups / group configuration versions and / or artifact versions will be used to bootstrap a given service (or make cellular changes to a target region) within a region. In some embodiments, orchestrator 106 may be configured to monitor (or otherwise be notified) changes to region data managed by real-time region data distributor 104. In some embodiments, receiving an indication that region data has changed may cause orchestrator 106 to trigger region building. In some embodiments, orchestrator 106 may collect various group configurations and artifacts to be used for region building. Some or all of the group configurations may be configured to be region-agnostic. That is, the group configurations may not explicitly identify which regions the groups will be bootstrap to. In some embodiments, orchestrator 106 may trigger a data injection process, through which the collected group configurations are recompiled (e.g., by CIOS center 108). During recompilation, operations may be performed (e.g., by CIOS center 108) to inject region data maintained by real-time region data distributor 104 into the configuration file. Group configurations can reference region data via variables / parameters without requiring hard-coding of the region data. This data injection allows for dynamic modification of group configurations at runtime, rather than hard-coding the region data and thus making changes more difficult.

[0085] In some embodiments, the multi-group orchestrator 106 can perform static group analysis, wherein group configurations are parsed to identify dependencies between resources, execution targets, stages, and groups, particularly identifying circular dependencies that need to be removed. In some embodiments, the orchestrator 106 can generate any suitable number of data structures based on the identified dependencies. These data structures (e.g., one or more directed acyclic graphs, linked lists, etc.) can be used by CIOS 102 to drive the operation of execution region construction. For example, these data structures can collectively define the order in which services are bootstrapped within a region. The following will discuss... Figure 3The build dependency diagram 338 further illustrates examples of such data structures. If circular dependencies exist (e.g., service A requires service B, and vice versa), and are identified through static group analysis and / or a graph, then orchestrator 106 can be configured to notify any appropriate service team that changes to the corresponding group configurations are needed to correct these circular dependencies. Orchestrator 106 can be configured to traverse one or more data structures to manage the order in which services are bootstrapped to regions. Orchestrator 106 can (e.g., using data obtained from capability service 112) identify capabilities available in a given region at any given time. Orchestrator 106 can use this data to identify when it can boot a service, when it can block bootstrapping, and / or when it can resume boot operations associated with previously blocked services. Based on this traversal, orchestrator 106 can perform various releases, where instructions are transmitted by orchestrator 106 to CIOS center 108 to perform boot operations corresponding to any appropriate number of group configurations. In some examples, orchestrator 106 can be configured to identify one or more group configurations that may require multiple releases due to circular dependencies found in the graph. Therefore, orchestrator 106 can transmit multiple sets of instructions to CIOS center 108 for a given group configuration to break the circular dependencies identified in the graph.

[0086] In some embodiments, Puffin Center 118 may provide several user interfaces through which one or more skills can be defined. Puffin Center 118 may be configured to serve as a source of truth for services and may maintain metadata, including upstream and downstream dependencies for each service, as well as service team contact information and methods for each service across regions and domains (e.g., a set of regions). Each skill may represent a functional unit that a service exposes and provides to users (e.g., other services). In some embodiments, a skill may be scoped, where access is controlled based on access and / or authorization policies and / or association with a specific namespace. A skill may be associated with multiple versions, where one or more aspects of the skill differ from previous versions, and each skill version represents a specific implementation of the skill. Each skill version may be identified using a unique skill identifier. In some embodiments, Puffin Center 118 may be configured to generate skills corresponding to previously defined capabilities to provide backward compatibility with previous capability-based region-building implementations.

[0087] In some embodiments, skills can be mapped to one or more capabilities. Puffin region 120 can be configured to publish skills based on capabilities published by capability service 112, and / or Puffin region 120 can publish capabilities to capability service 112 at least in part based on published skills. In some embodiments, some services can utilize group configurations that use capabilities to express progress, while other services can utilize service plans and inventory lists that define deterministic build processes in which progress is expressed in terms of skills. Using the mapping between skills and capabilities, Puffin region 120 can enable the use of any suitable combination of capabilities and / or skills as progress metrics to perform region builds.

[0088] In some embodiments, any suitable computing component of the Puffin service (e.g., Puffin Center 118 and / or Puffin Area 120) may be configured to monitor the health and / or lifecycle of a skill according to a predefined skill lifecycle. Health monitoring may be performed using one or more alarms associated with a given skill. In some embodiments, when an alarm is triggered, a telemetry service (not shown) may utilize the application programming interface provided by the Puffin service (including Puffin Center 118 and Puffin Area 120). The Puffin service may present skill health-related information via one or more user interfaces, based on these triggered alarms and their corresponding associations with a given skill.

[0089] In some embodiments, the Puffin service (e.g., Puffin Hub 118 and / or Puffin Region 120) may expose one or more application programming interfaces (APIs) through which verification operations can be performed. For example, a SPAM describing build processes for one or more services may be provided via a given API. The Puffin service may perform any appropriate operations to verify that all services and skills identified in the SPAM have previously been registered with the Puffin service and that the build processes defined in the SPAM do not violate previously defined dependencies.

[0090] The specific user interface, data, and processing used to obtain and manage metadata related to all services and skills will be relevant. Figures 4-19 Let's have a more detailed discussion.

[0091] In some embodiments, a user can request the construction of a new region (e.g., target region 114). This may involve bootsting resources corresponding to various services. In some embodiments, target region 114 may be uncommunicative (and / or insecure) when the region construction request is initiated. Instead of delaying booting until target region 114 becomes available and is configured to perform boot operations, CIOS 102 can use a Virtual Boot Environment (ViBE) 116 to initiate region construction. The Virtual Boot Environment (ViBE) 116 can be an overlay network hosted by host region 103 (a pre-existing region that has been previously configured with a set of core services and is communicative and secure). Orchestrator 106 can utilize the resources of host region 103 to boot resources into ViBE 116 (often referred to as "building a ViBE"). For example, orchestrator 106 can provide instructions via CIOS hub 108 to boot another instance of CIOS region within ViBE 116 from an instance of CIOS region 110 within a host region (e.g., host region 103). Once the CIOS region within the ViBE is available for processing, services targeting the target region 114 can continue to be booted within the ViBE 116. When the target region 114 becomes available to perform boot operations, previously booted services within the ViBE 116 can be migrated to the target region 114. Utilizing these techniques, the CIOS 102 can significantly increase the speed of region building by drastically reducing the need for any manual input and / or configuration that would otherwise be required.

[0092] Figure 2 This is used to illustrate a method for constructing a virtual boot environment (ViBE) according to at least one embodiment 202 ( Figure 1 A block diagram of environment 200 and methods (example of ViBE 116). ViBE 202 represents an existing region (e.g., host region 204). Figure 1 Example of host region 103, and in one embodiment, a virtual cloud network provisioned within the coverage of a host region service enclave. ViBE 202 represents a target region (e.g., a region under construction, such as...) Figure 1 The environment that can temporarily serve the target area (114) before it becomes available.

[0093] In order to guide the new area (e.g., Figure 1 The target zone 114 can host a set of core services. While these core service sets exist in host zone 204, they do not yet exist in the ViBE (nor in the target zone). These basic core services provide the functionality needed to provision equipment, establish trust chains to the new zone, and deploy remaining services (e.g., groups) to the zone. ViBE 202 can be a lease deployed in host zone 204. It can be considered a virtual zone.

[0094] When a target region becomes available to provide bootstrapping operations, ViBE 202 can connect to it, allowing services in ViBE to interact with services and / or infrastructure components in the target region. This enables the deployment of production-level services, instead of deploying self-contained seed services as in previous systems, which would have required an internet connection to the target region. Typically, seed services are deployed as part of a collection of containers and used to bootstrap the dependencies needed to build the region. Using existing region infrastructure / tools, resources can be bootstrap (e.g., provisioned and deployed) into ViBE 202 and connected to the service territory of a region (e.g., host region 204) to provision hardware and deploy services until the target region is self-sufficient and can communicate directly. Utilizing ViBE 202 allows the establishment of necessary dependencies and services to enable the provisioning / preparation of infrastructure and the deployment of software, while leveraging the resources of the host region to break circular dependencies in core services.

[0095] Orchestrator 206 can be configured to perform operations to build (e.g., configure) ViBE 202. Orchestrator 206 can obtain applicable group configurations and / or SPAMs corresponding to various resources to be bootstrapped to the new region (in this case, the ViBE region, ViBE 202). For example, orchestrator 206 can obtain group configurations (e.g., "ViBE group configurations") that identify aspects of bootstrapping capability service 208 (e.g., an example of capability service 112) and worker 210. In some embodiments, orchestrator 206 can additionally obtain identification of bootstrapping skill service 209 (e.g., ... Figure 1 Group configurations for any suitable portion of the Puffin area 120. In some embodiments, one or more service plans and manifests (SPAMs) may be used to identify these aspects (e.g., one or more group profiles and / or resources / artifacts required to bootstrap services from start to finish) in order to bootstrap any suitable combination of capability services 208, workers 210, and / or skill services 209. As another example, orchestrator 206 may obtain another group configuration and / or SPAM corresponding to bootstrap Domain Name Service (DNS) 212 to ViBE 202.

[0096] At step 1, the arranger 206 may instruct the CIOS center 214 (e.g., respectively) Figure 1 and Figure 2Examples of CIOS Center 108 and CIOS Center 214. For example, orchestrator 206 may transmit requests (e.g., including ViBE group configurations) to request bootstrapping capability services 208 and workers 210 (and skill services 209 in some embodiments) that do not yet exist in ViBE 202. In some embodiments, CIOS Center 214 may have access to all group configurations and / or SPAMs. Thus, in some examples, orchestrator 206 may transmit identifiers of ViBE group configurations or SPAMs instead of the files themselves, and CIOS Center 214 may independently access storage (e.g., from...). Figure 3 Obtain it from the database (DB) 308 or DB 312.

[0097] In step 2, CIOS center 214 can provide ViBE group configuration to CIOS zone 216 via a corresponding request. In step 3, CIOS zone 216 can parse the ViBE group configuration to identify and perform specific infrastructure provisioning and deployment operations.

[0098] In some embodiments, CIOS region 216 may be provisioned and deployed using additional corresponding services. For example, at step 4, CIOS region 216 may instruct deployment orchestrator 218 (e.g., core services of host region 204 or other examples of writing, building, and deploying application software) to execute instructions that in turn cause capability service 208 and worker 210 to be bootstrapping within ViBE 202.

[0099] At step 5, capabilities can be transferred to capability service 208 (via worker 210 or otherwise from CIOS region 216, deployment orchestrator 218) to indicate the availability of resources corresponding to the ViBE group. Capability service 208 may persistently store this data. In some embodiments, capability service 208 adds this information to its maintained list of available ViBE capabilities. For example, the capabilities provided to capability service 208 at step 5 may indicate that capability service 208 and worker 210 are available for processing.

[0100] At step 6, the orchestrator 206 may identify capabilities and / or skills available to capability service 208 and worker 210 based on data (identifiers corresponding to capabilities) received or obtained from capability service 208 and / or Puffin area 209.

[0101] In some embodiments, the ability to publish can be determined by the Puffin region 209 (e.g., before being processed by the orchestrator 206). Figure 1The Puffin region 209 is processed by the orchestrator 209. In some embodiments, the Puffin region 209 can be configured to provide forward and backward compatibility between skills and abilities. For example, in some embodiments, if an ability is published to the Puffin region 209, the Puffin region 209 can (e.g., via a skills database table) query known skills to check if any skills are associated with that ability. If no skills are associated with that ability, the Puffin region 209 can be configured to create a skill (referred to as a "shadow skill") for that ability. When the orchestrator 209 publishes a skill during the build process, the Puffin region 209 can intercept the skill and identify one or more abilities associated with that skill. The Puffin region 209 can publish any abilities that are not yet published and are associated with that skill. In this way, the Puffin region 209 can support full compatibility between abilities and skills, allowing a mix of both to be leveraged to advance region building.

[0102] At step 7, as a result of receiving / acquiring data at step 6, orchestrator 206 may instruct CIOS center 214 to route DNS services (e.g., DNS 212) to ViBE 202. This instruction may identify or include specific group configurations corresponding to the DNS service.

[0103] At step 8, CIOS center 214 may instruct CIOS zone 216 to deploy DNS 212 to ViBE 202. In some embodiments, the DNS group configuration of DNS 212 is provided by CIOS center 214.

[0104] In step 9, worker 210 (now deployed in ViBE 202) can be assigned by CIOS zone 216 to the task of deploying DNS 212. The worker can then proceed as described above. Figure 3 The described approach executes a declarative infrastructure provider to identify a set of operations that need to be performed to deploy DNS 212, for example, by comparing the group configuration (desired state) with the current state of resources associated with the group (currently non-existent).

[0105] At step 10, deployment orchestrator 218 can instruct worker 210 to deploy DNS 212 according to the operation identified at step 9. As illustrated, worker 210 continues to perform the operation to deploy DNS 212 to ViBE 202 at step 11. At step 12, worker 210 can notify capability service 208 or Puffin zone 209 (directly or via capability service 208) that DNS 212 is available in ViBE 202. Orchestrator 206 can then identify the resources available associated with the ViBE group configuration and DNS group configuration, and can continue to route any appropriate number of additional resources to ViBE.

[0106] After steps 1-12 are completed, the process of building ViBE 202 can be considered complete, and ViBE 202 can be considered built and ready for additional boots (e.g., various cloud services such as...). Figure 20 (The cloud service 2056) guide).

[0107] Figure 3 This is a block diagram illustrating an environment 300 and a method for directing services to a target area using ViBE according to at least one embodiment.

[0108] At step 1, user 302 (e.g., a service team member) can communicate with Puffin center 340 (e.g., Figure 1 The Puffin Hub (118) hosts any suitable number of user interfaces for interaction. Some examples of these user interfaces will be provided below. Figures 4-19 This will be discussed further. The Puffin Center 340 can be configured to read service and / or skill metadata from a predefined file, or user 302 can enter service and / or skill metadata at one or more locations within the provided user interface. The Puffin Center 340 can store all service and skill metadata and serve as its centralized authority. Any suitable user can view the service and / or skill metadata at any appropriate time, such as before and / or during the execution of a region build.

[0109] In step 2, user 303 can utilize the CIOS center 304 (respectively) Figure 1 and Figure 2 (Examples of CIOS Center 108 and CIOS Center 214) provide any suitable user interface to modify zone data. For example, user 303 can create new zones to which several services will be routed.

[0110] At step 3, CIOS center 304 can perform an operation to send the changes to RRDD 306 (e.g., Figure 1(Example of RRDD 104). At step 4, RRDD 306 may store the received region data in database 308, which is a data repository configured to store region data, including any suitable identifiers, attributes, statuses, etc., such as region, AD, domain, ET, etc. In some embodiments, updater 307 may be used to store region data in database 308 or in any suitable data repository from which such updates can be accessed (e.g., by a service team). In some embodiments, updater 307 may be configured to notify updates made to database 308 (e.g., via any suitable electronic notification).

[0111] In step 5, the arranger 310 (respectively) Figure 1 and Figure 2 (Examples of orchestrators 106 and 206) can detect changes to region data. In some embodiments, orchestrator 310 can be configured to poll RRDD 306 to learn about changes to region data. In some embodiments, RRDD 306 can be configured to publish or otherwise notify orchestrator 310 of region data changes.

[0112] At step 6, detecting a change in the region data can trigger orchestrator 310 to obtain a version set (e.g., a version set associated with a specific identifier, such as a "gold version set" identifier) ​​for each group (e.g., a service) to be routed to the new region, and for each artifact corresponding to that group. This version set can be obtained from DB 312. As groups evolve and change, the versions of their corresponding configurations and artifacts used for region building may change. These changes can be persistently stored in DB 312, allowing orchestrator 310 to identify which versions of group configurations and artifacts to use for region building (e.g., ViBE region, target region / non-ViBE region, etc.). Group configurations (e.g., group configurations for all versions) and / or artifacts (e.g., artifacts for all versions) can be stored in DB 308, DB 312, or CIOS center 304 and / or any suitable data repository accessible to orchestrator 310.

[0113] At step 7, the orchestrator 310 may request the CIOS center 304 to recompile each group configuration associated with the version set using the current region data. In some embodiments, the request may indicate the version of each group configuration and / or the artifacts corresponding to those group configurations.

[0114] At step 8, CIOS center 304 can (e.g., directly or via real-time region data distributor 306) obtain current region data from DB 308 and retrieve any suitable group configurations and artifacts based on the version requested by orchestrator 310.

[0115] At step 9, CIOS center 304 can recompile the group configuration using the region data obtained at step 8 to inject the current region data into the group configuration. CIOS center 304 can return the compiled group configuration to orchestrator 310. In some embodiments, CIOS center 304 can simply indicate that compilation is complete, and orchestrator 310 can access the recompiled group configuration via RRDD 306.

[0116] In some embodiments, at step 10, orchestrator 310 may perform static analysis on the recompiled group configuration. As part of the static analysis, orchestrator 310 may resolve the group configuration (e.g., using libraries associated with declarative infrastructure providers (e.g., Terraform, etc.)) to identify dependencies between groups. Based on the analyzed and identified dependencies, orchestrator 310 may generate a build dependency graph 338. Build dependency graph 338 may be an acyclic directed graph that identifies the order in which groups are guided to new regions (and / or changes indicated in the group configuration are applied to the new regions). Each node in the graph may correspond to any suitable portion of guiding a particular group. A particular guiding order may be identified at least in part based on dependencies. In some embodiments, dependencies may be expressed as attributes of nodes and / or indicated via edges of the graph connecting the nodes. Orchestrator 310 may traverse the graph (e.g., starting from the starting node) to drive the region building operations.

[0117] In some embodiments, orchestrator 310 may utilize a cycle detection algorithm to detect the existence of cycles (e.g., service A depends on service B, and vice versa). Orchestrator 310 may identify orphaned capability dependencies. For example, orchestrator 310 may identify orphaned nodes in the dependency graph 338 that are not connected to any other nodes. Orchestrator 310 may identify erroneously published capabilities (e.g., when a capability is published prematurely, and the corresponding functionality is not yet available). Orchestrator 310 may detect from the graph the existence of one or more instances of the same capability being published. In some embodiments, any suitable number of these errors may be detected, and orchestrator 310 (or another suitable component, such as CIOS center 304) may be configured to notify or otherwise present this information to the user (e.g., via electronic notifications, user interface, etc.). In some embodiments, orchestrator 310 may be configured to force the deletion / recreation of resources to break circular dependencies and may again provide instructions to CIOS center 304 to perform bootstrapping operations for these resources and / or their corresponding group configurations.

[0118] In some embodiments, orchestrator 310 can generate a dependency build graph 338 from a set of one or more service plans and manifests (SPAMs) (also referred to as a “SPAM set”). Each SPAM in the SPAM set can identify deterministic processes for building a single service, including upstream and downstream dependencies on one or more other available resources, services, or features, or event-based dependencies (each of which can be expressed by publishing skills). Accordingly, in some embodiments, the dependency build graph 338 is generated by inferring at least some dependencies through static group analysis of one or more group configurations, while in other embodiments, the dependency build graph 338 is generated based on build processes explicitly defined within the SPAM set.

[0119] The starting node can correspond to the bootstrapping ViBE group, and the second node can correspond to the bootstrapping DNS. Steps 11-16 can correspond to placing the ViBE group (e.g., resources and / or artifacts identified in the ViBE group configuration) (via deployment orchestrator 317, Figure 2 Example of deployment orchestrator 218) deployed to ViBE 316 (e.g., respectively) Figure 1 and Figure 2 Examples of ViBE 116 and 202). That is, Figure 3 Steps 11-16 typically correspond to Figure 2 Steps 1-6. Once notified that the capability corresponding to the ViBE group being deployed exists (e.g., indicating that...), Figure 2 (If capability service 208 and worker 210, corresponding to capability service 318 and worker 320, are available), the orchestrator 310 then restarts traversing the dependency graph 338 to identify the next operation to be performed. In some embodiments, such as in combination Figure 2 As discussed, bootstrapping ViBE 316 may include deploying Puffin regions 342 (e.g., respectively) Figure 1 and Figure 2 Puffin regions 120 and 209).

[0120] For example, orchestrator 310 can continue traversing the dependency graph 338 to identify the DNS groups to be deployed. Steps 17-22 can be performed to deploy DNS 322 ( Figure 2 (Example of DNS 212). These operations can typically correspond to... Figure 2 Step 7 - Figure 12 .

[0121] At step 22, a capability indicating the availability of DNS 322 can be stored. After this capability is detected (e.g., via data provided by capability service 318 and / or Puffin zone 342), orchestrator 310 can restart the traversal of the dependency graph 338. During this traversal, orchestrator 310 can identify any suitable portions of an instance of a CIOS zone (e.g., an example of CIOS zone 314) that will be deployed to ViBE 316. In some embodiments, steps 17-22 can be substantially repeated to deploy CIOS zone (ViBE) 326 (an instance of CIOS zone 314) to ViBE 316. Figure 1 The CIOS region (ViBE) 326 and worker 328 are deployed to ViBE 316. Capabilities available in CIOS region (ViBE) 326 can be transferred to capability service 318.

[0122] After detecting that CIOS region (ViBE) 326 is available, orchestrator 310 can restart traversing the build dependency graph 338. During this traversal, orchestrator 310 can identify deployment orchestrators (e.g., deployment orchestrator 330, examples of deployment orchestrator 317) to be deployed to ViBE 316. In some embodiments, steps 16-21 can be substantially repeated to deploy deployment orchestrator 330. Information identifying capabilities can be transmitted to capability service 318 to indicate that deployment orchestrator 330 is available.

[0123] After deployment orchestrator 330 is deployed, ViBE 316 can be considered available to handle subsequent requests. Upon detecting the availability of deployment orchestrator 330, orchestrator 310 can instruct subsequent bootstrapping requests to be routed to ViBE components instead of utilizing host zone components (components of host zone 332). Therefore, orchestrator 310 can continue traversing the build dependency graph 338, instructing ViBE 316 to perform group deployments at each node via CIOS center 304. CIOS center 304 can then request CIOS zone (ViBE) 326 to deploy resources according to the group configuration.

[0124] At some point during this process, target area 334 may become available. Indication of target area availability can be identified from area data of target area 334 provided by user 303 (e.g., as an update to the area data). The availability of target area 334 may depend on establishing a network connection between target area 334 and an external network (e.g., the Internet). This network connection may be supported by a public network (e.g., the Internet), but may use software security tools (e.g., IPSec) to provide one or more encrypted tunnels (e.g., IPSec tunnels, such as tunnel 336) from ViBE 316 to target area 334. As used herein, “IPSec” refers to a suite of protocols used for authenticating and encrypting network traffic over networks using the Internet Protocol (IP), and may include one or more available implementations of this suite (e.g., Openswan, Libreswan, strongSwan, etc.). The network can connect ViBE 316 to the service territory of target area 334.

[0125] Before establishing an IPSec tunnel, the initial network connection to target area 334 can reside on a connection sufficient to allow bootstrapping of networking services (e.g., an out-of-band VPN tunnel) until the IPSec gateway can be deployed on an asset (e.g., a bare metal asset) within target area 334. To bootstrap network resources in target area 334, deployment orchestrator 330 can deploy the IPSec gateway at the asset within target area 334. Deployment orchestrator 330 can then deploy a VPN host in target area 334, configured to terminate the IPSec tunnel from ViBE 316. Once services in ViBE 316 (e.g., deployment orchestrator 330, service A, etc.) can establish an IPSec connection with the VPN host in target area 334, bootstrapping operations from ViBE 316 to target area 334 can begin.

[0126] In some embodiments, the bootstrapping operation can begin by providing resources in target region 334 from services in ViBE 316 to support managed instances of core services when deploying them from ViBE 316. For example, a host provisioning service can provision a hypervisor on infrastructure (e.g., a bare metal host) in target region 334 to allocate compute resources for VMs. When the host provisioning service completes the allocation of physical resources in target region 334, it can publish information indicating a capability that indicates the physical resources in target region 334 have been allocated. This capability can be published to capability service 318 via CIOS region (ViBE) 326 (e.g., by worker 328).

[0127] After establishing the hardware allocation for target region 334 and publishing it to capability service 318, CIOS region (ViBE) 326 can orchestrate the deployment of core service instances from ViBE 316 to target region 334. This deployment can be similar to the process described above for building ViBE 316, but uses ViBE components (e.g., CIOS region (ViBE) 326, worker 328, deployment orchestrator 330) instead of components from the service territory of host region 332. The deployment operation can typically correspond to steps 17-22 above.

[0128] When a service is deployed from ViBE 316 to target zone 334, the DNS records associated with that service can correspond to the service instance in ViBE 316. The DNS records associated with the service can be updated at a later time to complete the service deployment to target zone 334. In other words, the service instance in ViBE 316 can continue to receive service traffic (e.g., requests) until the DNS records are updated. A service can be partially deployed to target zone 334 and (e.g., to capability service 318) publish information indicating that the service is partially deployed. For example, a service running in ViBE 316 can be deployed to target zone 334 using the corresponding compute instance, load balancer, and associated applications and other software, but may need to wait for the database data to be migrated to target zone 334 before full deployment. The DNS records (e.g., managed by DNS 322) can still be associated with the service in ViBE 316. Once the service data migration is complete, the DNS records can be updated to point to the operational service deployed in target zone 334. Then, the service deployed in target region 334 can receive service traffic (e.g., requests), while the service instance in ViBE 316 can no longer receive service traffic.

[0130] Service and Skills Management

[0131] Figure 4 This is a block diagram depicting a data model 400 representing various metadata related to skills according to at least one embodiment. In some embodiments, service metadata 402 may include any suitable data corresponding to a service. Service metadata 402 may include any suitable attributes of the service and their corresponding values, while skill metadata 404 may similarly include any suitable attributes of the skill and their corresponding values. The association between service metadata 402 and skill metadata 404 may indicate a relationship between services and skills (e.g., a service is expected to release skills during construction or runtime). Figure 4As illustrated, service metadata 402 can be stored in multiple data structures (e.g., namespace data structure 406 and service data structure 408), but any suitable number or type of data structure can be utilized. Service metadata can include, but is not limited to, any suitable combination of service identifier (ID), service name, compartment ID (an identifier corresponding to the compartment to which the service is deployed), product part ID, namespace ID, namespace name, and / or the compartment ID corresponding to the namespace. In some embodiments, service metadata 402 can be processed (read from storage, uploaded to...). Figure 1 (e.g., Puffin Center 120). In some embodiments, service metadata 402 may be obtained by Puffin Center 120 from another system, or typically obtained using processing that does not include user input of the information through any user interface provided by Puffin Center.

[0132] Skill metadata 404 may include any suitable number of data structures (e.g., data structures 410-420). In some embodiments, skill data structure 410 may include attributes and values ​​corresponding to any suitable combination of skill ID, skill name, skill fleet, major version, isDeprecated indicator, a set of capabilities (e.g., a set of capability identifiers), useInstead indicator, compartment ID, producer ID, namespace ID, and recovery ring level. In some embodiments, the values ​​stored in skill data structure 410 for compartment ID, producer ID, and / or namespace ID may be matched with the compartment ID, service name, or namespace name of service metadata 402, respectively. Matching between one or more of these attribute values ​​can be used as an association between skill metadata 404 and service metadata 402 (indicating that the corresponding service is expected to release the skill at a certain point in time).

[0133] Skill version data structure 412 can be associated with skill data structure 410, at least in part, based on the matching of the skill ID value of skill version data structure 412 with the ID value of skill data structure 410. Skill version data structure 412 may include attributes and values ​​corresponding to any suitable combination of (skill version) ID, skill ID, minor version, patch version, deprecation indicator, health check indicator, installation status, and health status. Skill version data structure 412 can be associated with health check data structure 414, which can be configured to maintain any suitable number of alert tags associated with the skill.

[0134] Skill data structure 410 can be associated with skill metadata data structure 416. Skill metadata data structure 416 can include attributes and values ​​of any suitable combination of (an instance of skill metadata data structure 416) ID, Jira queue, owner contact, organization leader, and phone book ID. Phone book ID can be an identifier corresponding to a separate system configured to store contact data. Skill metadata data structure 416 can be used to store any suitable contact data (e.g., name, email, address, phone number, etc.) associated with the skill and the entity (e.g., service team member) of the service and its associated service.

[0135] Skill data structure 410 may be associated with skill user data structure 418. Skill user data structure 418 may include attributes and values ​​such as (skill user's) ID, type, status, usage region, version requirement, used skill ID, and used service ID, or any suitable combination thereof. Skill user data structure 418 may be configured to store any suitable information about services and / or skills that depend on the skills defined in skill metadata 404.

[0136] The skill data structure 410 can be associated with the skill group data structure 420. The skill group data structure may include the (skill group) ID, the skill group name, and any suitable combination of attributes and values ​​for a group or more skill IDs associated with that skill group.

[0137] Each of data structures 406-420 can be stored in one or more data repositories, and the data structures can be identified and obtained, at least in part, based on values ​​stored in another data structure through the associations discussed above (e.g., via lookup and / or query operations). For example, all skills associated with a service can be identified by querying all skill data structures associated with producer IDs that match the IDs in the service data structure 406 of the service metadata 402, located in one or more data repositories.

[0138] Although Figure 4 The document presents a certain number and specific combinations of data structures, but any suitable number or type of attributes and / or values ​​and / or data structures can be utilized. The relationships indicated between these data structures can be... Figure 4The associations shown may be similar, or they may be different. As a non-limiting example, data described using data structures 410-420 may be similarly stored across more or fewer data structures. For example, in some embodiments, data described using data structures 410-420 may be provided in a single data structure. Any suitable number of skill metadata 404 instances (corresponding to individual skills) may be associated with a single service metadata 402 instance. The collection of skill metadata 404 instances may be used to represent the processing of a deployment service, where the order of deployment tasks is represented by the instances of skill metadata 404. Each skill corresponding to an instance of service skill metadata 404 may be tracked, updated, or otherwise analyzed to present information about the deployment processing of the service, drive the deployment of the service, validate build plans, or... Figure 3 The dependency graph 338 shows the construction process, etc.

[0139] Figure 5 This is a block diagram depicting an example user interface 500 configured to present a service catalog according to at least one embodiment. The term "service catalog" is intended to refer to a registry / collection of service metadata corresponding to all previously defined services. In some embodiments, the data presented via user interface 500 may (e.g., by...) Figure 1 The Puffin Center 120 (which may host the user interface 500) obtains data from storage devices, another service, etc. In some embodiments, the presented data is curated from another system or curated through processing that does not include service metadata provided via user input using the user interface hosted by the Puffin Center 120. In some embodiments, a Software Architects Committee (or another suitable decision-making authority) may receive requests to define services (e.g., from one or more service teams). The Software Architects Committee may approve or reject such requests. If approved, then the service metadata data (e.g., Figure 4 The service metadata (402) may be generated (e.g., by a process or service outside of Puffin Center 120) and stored in a storage location accessible to Puffin Center 120. In some embodiments, the service metadata (e.g., Figure 4 Any appropriate portion of the service metadata (402) can be provided via the user interface hosted by Puffin Center 120.

[0140] As illustrated, user interface 500 may include user interface element 502 (e.g., depicted as a drop-down menu, but other user interface elements are expected). User interface element 502 may be pre-populated with any suitable number of service names obtained from any suitable number of predefined service metadata 402 instances. Each entry selectable from user interface element 502 may correspond to a different instance of service metadata 402. By default, user interface element 502 may present an "all" selection, indicating the option to present the service name (or any suitable portion of service metadata 402) corresponding to each unique instance of service metadata 402. Each instance of service metadata 402 may correspond to each known service that has been pre-registered (e.g., each service for which an instance of storage service metadata 402 has previously been created and stored). In some embodiments, the specific service selectable from user interface element 502 may depend on the selection of the region indicated in user interface element 504.

[0141] In some embodiments, the user interface element 504 may be populated with identifiers for all known areas (e.g., names, alphanumeric identifiers, etc.). In some embodiments, specific entries selectable from the user interface element 504 may be at least partially based on... Figure 1 The real-time regional data distributor 104 maintains regional data. Once selected via user interface element 504, the corresponding regional identifier can be used to populate entries selectable from user interface element 502 (e.g., using services associated with the selected region). In some embodiments, user interface element 504 may include an option to select "all" known regions.

[0142] Depending on the selections identified via user interface elements 502 and 504, region 506 can present any suitable service metadata associated with the instances of services corresponding to the services associated with the selected region, as defined in service metadata 402. Updates to the selections made to user interface elements 502 and 504 allow region 506 to be updated with entries corresponding to the selected values ​​of user interface elements 502 and 504. As illustrated, region 506 includes the service names corresponding to all services associated with region "Region_example". Although Figure 5 The service name values ​​are described, but it should be recognized that any suitable combination of service metadata 402 for each applicable service can be presented via region 506. In some embodiments, each entry in region 506 may include a navigation link corresponding to a specific service. For example, the selection of navigation link 508 can navigate the user to the services discussed below. Figure 6The user interface is drawn in section 506. Any suitable number of items can be presented in section 506. Section 506 may be scrollable, and / or the user interface 500 may include presentation options for configuring pagination options (e.g., presentation option 510), wherein a specific number (e.g., up to 100 items) can be initially presented within section 506. Navigation options 512 and 514 may be provided to navigate to the next page or the previous page, respectively.

[0143] The user interface 500 may include any suitable filtering options for filtering entries within region 506. For example, one or more keywords may be provided via search box 516. After selecting search button 518, the entries within region 506 may be updated to include entries that are related to, match, or otherwise correspond to the keywords provided via search box 516.

[0144] Because service metadata may be added to or changed over time, the user interface 500 may include a refresh option 520. After selecting refresh option 520, the Puffin center 118 can be configured to read, parse, or otherwise update the service metadata presented via the user interface 500. Any suitable previous selections provided via user interface elements 502 and 504, presentation option 510, or search box 516 can be applied to the updated service metadata, and the corresponding entries can be re-provided via region 506.

[0145] Figure 6 This is a block diagram depicting an example user interface 600 configured to present metadata associated with a single service according to at least one embodiment. The user interface 600 can be accessed via selection... Figure 5 Navigation link 508 is used for access, but other means of navigating to user interface 600 can be anticipated. User interface 600 can be configured to present multiple tabs. As illustrated, user interface 600 can be configured to present a Services tab (indicated at 602) and Skills and Groups tabs (not illustrated). In some embodiments, the Services tab may be presented by default.

[0146] Figure 6 The data depicted in the middle can correspond to Figure 4 Any appropriate portion of the service metadata 402 and / or skill metadata 404. Based on the current example, select... Figure 5Navigation link 508 allows the data presented via user interface 600 to include data associated with the "Foundry" service. For example, the service name can be described via user interface element 604. This value (e.g., "Foundry") can be populated into user interface element 604 upon selection of navigation link 508. In some embodiments, user interface element 604 (described herein as a drop-down menu) can be used to select any suitable known / registered service. Selecting another known service allows user interface 600 to be updated with service and / or skill metadata corresponding to the service selected via user interface element 604.

[0147] User interface 600 can present any suitable combination of user interface elements 606-612. User interface element 606 can correspond to an execution type (e.g., build time, runtime, etc.), indicating that the data presented via user interface 600 corresponds to a specific execution type. User interface element 608 can be used to select a region (e.g., “Region_example”). The data presented within user interface 600 can be updated using service and / or skill metadata corresponding to the selected service and the selected region (because services may be associated with different service and / or skill metadata depending on the region). User interface 600 can include user interface element 610, corresponding to a specific version of the service and / or skill metadata. In some embodiments, the options presented via user interface element 610 can include the latest version (the latest version of the service and / or skill metadata in chronological order), or a specific version can be selected via user interface element 610 based on one or more versions associated with the selected service. User interface element 612 can be used to select another skill version, to which the version of the skill metadata selected via user interface element 610 can be compared. The user interface 600 can be updated by selecting the user interface element 612 to display both the skill metadata corresponding to the version selected via the user interface element 610 and the skill metadata corresponding to the version selected via the user interface element 612.

[0148] User interface 600 may include time data 614. Time data 614 may indicate the date and / or time when the data presented by region 616 was identified. In some embodiments, option 618 may be presented via user interface 600. Selecting option 618 may cause user interface 600 to present audit data indicating the date and / or time when service and / or skill metadata corresponding to the selection made via user interface elements 604-610 was created and / or updated.

[0149] User interface 600 may include various options for region 620, such as tree tabs, chart tabs, user drop-down menus, dependency drop-down menus, and toggle buttons (e.g., toggle button 620) for filtering or displaying unhealthy skills within a region.

[0150] like Figure 6 The region 616 shown in the figure is presented in at least part based on the selection of the chart tab for region 620 to display chart 624. Chart 624 can (e.g., by...) Figure 1 The Puffin Center 118 is generated at least in part based on skill metadata of various services associated with the region. Specifically, Graph 624 may depict dependencies between various skills associated with a single service. Since the Foundry service is selected via user interface element 604, the graph may present a directed graph (e.g., a directed acyclic graph) and may include all skills or a subset of skills (e.g., nodes representing the graph) associated with the Foundry service represented by element 626. In some embodiments, Graph 624 may be a sub-part of a larger graph generated by Puffin Center 118. Thus, selections made via user interface elements 604-610 may limit the data presented within the region to skill metadata associated with the Foundry service (and indications of multiple or specific skills that depend on one or more skills associated with the Foundry service), or the region 616 may be able to present additional skill data associated with one or more other services, but with an initial focus on skill metadata associated with the Foundry service. In some embodiments, the larger graph may include elements / nodes corresponding to each skill associated with each service to be deployed within the selected region.

[0151] Data generated and / or selected for presentation in response to selections made via user interface elements 604-610 can be of concern in the following sense: the data includes skill information and dependencies corresponding to one or more skills of the selected service (e.g., the Foundry service), indications or skill metadata corresponding to one or more skills that at least one skill associated with the Foundry service depends on (referred to as "upstream dependencies"), and / or indications or skill metadata corresponding to skills of other services that ultimately depend on one or more skills associated with the Foundry service (referred to as "downstream dependencies"). Element 628 may indicate the existence of 30 downstream dependencies, or in other words, 30 other skills that use / depend on the "Cast Iron" skill associated with the Foundry service. In some embodiments, the element may include an option (e.g., option 630 corresponding to element 628), which, if selected, causes region 616 (or a separate window) to present additional details associated with the selected element. For example, selecting option 630 may cause region 616 (or a separate window) to present identifiers corresponding to thirty skills that depend on the "Cast Iron" skill associated with the Foundry service.

[0152] Element 626 can present any suitable combination of skill metadata corresponding to any suitable number of skills associated with the Foundry service. In the illustrated example, the Foundry service is associated with four skills (but a service can be associated with any suitable number of skills). In some embodiments, the skill metadata corresponding to a single skill (e.g., “Cast Iron”) can be initially presented within element 626, with options (e.g., option 632) available to display data corresponding to the remaining skills not initially depicted. Similarly, a single version identifier (e.g., “Version 1.0”) associated with the skill metadata corresponding to the “Cast Iron” skill can be initially presented, and option 634 can be provided. Selecting option 634 allows updating region 616 (and element 626) to present skill metadata corresponding to any suitable number of versions of the skill “Cast Iron”. Elements 636 and 638 can represent the “Carbon” and “Iron” skills that the “Cast Iron” skill depends on, respectively. As illustrated, both the “Carbon” and “Iron” skills can be associated with skill metadata indicating a dependency on the “Protons” skill. As illustrated, the "Carbon" and "Iron" skills can depend on different versions of the "Protons" skill represented by element 640.

[0153] In some embodiments, one or more skills may be indicated (e.g., via element 642), but these skills are initially hidden depending on the default or selected viewing area. For example, element 640 indicates that the "Carbon" skill depends on three additional upstream skills. In some embodiments, user interface element 644 may be used to modify the viewing area of ​​region 616. For example, a slider of user interface element 644 may move up to increase the viewing area (e.g., zoom out to present a larger portion of the chart / graph), or move down to decrease the viewing area (e.g., zoom in to present fewer elements corresponding to a smaller number of skills). In some embodiments, outward scaling may cause less information to be presented via the elements, while inward scaling may cause the elements to present additional information. As a non-limiting example, inward scaling may cause the three additional skills associated with the Foundry service to be displayed in a similar manner to... Figure 6 The diagram illustrates the way the "Cast Iron" skill is rendered. As another example, scaling outwards allows the individual elements corresponding to element 642 (e.g., the three skills the "Carbon" skill depends on) to be rendered. In the following diagrams, similar user interface elements can be used to scale inwards or outwards, or otherwise modify the focus of the rendered area (e.g., area 616). These user interface elements can be used and manipulated in a similar manner to those described in conjunction with user interface element 644 to modify their associated corresponding rendered areas, and for the sake of brevity, further detailed discussion is omitted.

[0154] User interface 600 may include user interface element 646, which can provide an alternative mechanism for modifying the scope of skill data presented within region 616. As illustrated, user interface element 646 may indicate three levels of the graph to be presented (in this example, the graph associated with the Foundry service and / or the portion of the graph indicating skill relationships between skills of any suitable number of services). Based on the values ​​selected using user interface element 646, region 616 may present three levels of the graph associated with the Foundry service. As illustrated, element 626 represents the first level, elements 636 and 638 represent the second level, and element 640 represents the third level of the graph. Different selections made via user interface element 646 can modify the number of levels of the graph presented within region 616. Region 648 may be configured to present a high-level view of the service, indicating several dependencies of the service (e.g., eight skills the service depends on) and several dependencies on the service (e.g., thirty users dependent on one or more skills associated with the service "Foundry").

[0155] In some embodiments, options 650 and 652 can be used to filter data presented within region 616. Skills can be associated with consumption during build time and / or runtime. Each of options 650 and 652 can be used to filter data within region 616 to present build-time associated information of skills when option 650 is selected, and to present runtime associated information of skills when option 652 is selected.

[0156] Figure 7 This is a block diagram depicting an example user interface 700 associated with a skill catalog according to at least one embodiment. The user interface 700 can be configured to present a skill catalog. The term "skill catalog" is intended to refer to a registry / collection of skill metadata corresponding to all previously defined skills. In some embodiments, instances of skill metadata (e.g., Figure 4 The skill metadata (any suitable portion of 404) can be accessed via a user interface hosted by Puffin Center 120 (e.g., via the interface discussed below). Figures 8-12 The user interface is provided.

[0157] As illustrated, user interface 700 may include user interface element 702 (e.g., depicted as a drop-down menu, but other user interface elements are expected). User interface element 702 may be pre-populated with any suitable number of skill names obtained from any suitable number of predefined skill metadata 404 instances. Each entry selectable from user interface element 702 may correspond to a different instance of skill metadata 404. By default, user interface element 702 may present an "all" selection, indicating the option to present the service name (or any suitable portion of skill metadata 404) corresponding to each unique instance of skill metadata 404. Each instance of skill metadata 404 may correspond to each previously defined skill. User interface element 702 may be one of a set of user interface elements (e.g., user interface element 704, which includes user interface elements corresponding to availability range, skill group, influence zone level, published service, region, skill status, and skill health). It should be recognized that the selection available via one user interface element 704 may depend on the value selected via one or more other user interface elements in user interface element 704. In some embodiments, some user interface elements may be disabled or enabled depending on the value selected via one or more other user interface elements. As a non-limiting example, unless a value has already been selected by the corresponding user interface element for the region, it may be impossible to input skill status and skill health values ​​via the drawn corresponding user interface element. User interface elements 706 and 708 can be configured to filter data presented within region 710. These elements can operate and perform actions related to those described above. Figure 5The search box 516 and search button 518 are similar functions that will be discussed in more detail, and therefore will not be discussed further for the sake of brevity.

[0158] Because skill metadata may be added to or changed over time, user interface 700 may include a refresh option 712. After selecting refresh option 712, Puffin Center 118 can be configured to read, parse, or otherwise update the skill metadata presented via user interface 700. Any suitable previous selections provided via user interface elements 704, 706, and / or 708 can be applied to the updated skill metadata, and the corresponding entries can be re-presented via region 710. User interface element 714 corresponds to, operates on, and performs functions similar to those discussed above in more detail regarding presentation options 510 and navigation options 512 and 514, and therefore will not be discussed further for the sake of brevity.

[0159] Specific data presented via region 710 can be customized via user interface element 716. Selecting user interface element 716 can cause a window or pop-up to appear, where columns corresponding to specific skill metadata attributes can be selected or deselected. In some embodiments, user interface 700 may include user interface option 718. After selecting user interface option 718, the data presented via region 710 can be formatted and saved to a file according to a predefined format. In some embodiments, the data can be downloaded in any suitable format (e.g., locally saved on the user's device). Additional windows or interfaces may be presented to the user for selecting the storage location and / or format of the downloaded data.

[0160] In some embodiments, options 720 and 722 can be selected from user interface element 724. Selecting option 720 will navigate the user to... Figure 8 The user interface 800, while selecting option 722 allows navigation to... Figure 13 User interface 1300.

[0161] Figures 8-12 This includes corresponding block diagrams depicting several example user interfaces related to skill creation according to at least one embodiment. (By...) Figures 8-12 Data obtained from the user interface can be used to generate Figure 4 An instance of skill metadata 404.

[0162] Figure 8 This is a block diagram depicting an example user interface 800 for obtaining metadata for creating a skill, according to at least one embodiment. In some embodiments, the user interface 800 may be configured to obtain any suitable skill metadata, such as... Figure 4The skill metadata data structure 416 is associated with the data. The user interface 800 can be at least partially based on selection. Figure 7 Option 720 is presented (via a window that is the same as or different from the user interface 700).

[0163] User interface 800 may include any suitable combination of user interface elements for obtaining values ​​for any suitable number of attributes corresponding to skill metadata 404. For example, user interface 800 may include a label 802 and a corresponding user interface element 804. Label 802 may correspond to an attribute of the skill metadata (e.g., "Name"), and in some embodiments, when the attribute is a required field, label 802 may include an indicator ("*" in this example). Attribute values ​​may be provided via user interface element 804 (depicted as an edit box in this example), but other elements for providing attribute values ​​are contemplated.

[0164] As another example, user interface 800 may include user interface elements (e.g., drop-down menus) to select services that possess skills identified in user interface element 804. In some embodiments, values ​​selectable via user interface element 806 may be based at least in part on all known service names (e.g., from...). Figure 4 The service metadata (names of all known instances) is used to populate the service.

[0165] User interface 800 may include a toggle button 808. In some embodiments, selecting toggle button 808 may configure the user interface element depicted below to import data from a system independent of the Puffin service. For example, selecting toggle button 808 may cause user interface element 810 to be populated with known contacts initially obtained and / or managed by a phonebook system configured to maintain such information. Alternatively, selecting toggle button 808 may cause Puffin Center 118 to populate user interface element 810 with data initially obtained from the phonebook system but stored in a location accessible to Puffin service 118. Selecting a value via user interface element 810 may update user interface 800 to include data 812. Data 812 may include any suitable contact information maintained and / or provided by the phonebook system and associated with the service selected via user interface element 810. If toggle button 808 is not selected (not depicted), additional user interface elements may be provided to manually enter the service owner's value and one or more contact methods.

[0166] User interface 800 may include navigation options 814 and 816. Selecting navigation option 814 can close user interface 800 or otherwise navigate the user back to user interface 700. Selecting navigation option 816 can navigate the user to the subsequent user interface series to which user interface 800 belongs. For example, selecting option 816 can navigate the user to... Figure 9 User interface 900. About Figure 12 User interfaces 900-1200 present similar navigation options, and these options provide similar navigation functionality. For simplicity, these options will not be discussed in detail. User interfaces 900-1200 may include additional navigation options corresponding to navigating to the previous user interface in the series. For example, selecting... Figure 9 Navigation option 902 allows the user to be navigated away from user interface 900 and presented with user interface 800 (e.g., the previous user interface in user interface series 800-1200). For the sake of brevity, this option will not be discussed in detail.

[0167] Figure 9 This is a block diagram depicting an example user interface 900 for obtaining classification data for creating skills according to at least one embodiment. The user interface 900 may include any suitable combination of user interface elements for obtaining values ​​of any suitable number of attributes corresponding to skill metadata 404. For example, the user interface 900 may include a label 904 and a corresponding user interface element 906. The label 904 may correspond to... Figure 4 The attribute of the skill metadata 404 (e.g., if it is) Figure 4 This corresponds to "namespaceType" in skill data structure 410, and in some embodiments, when the attribute is a required field, label 904 may include an indicator ("*" in this example). The value of the attribute may be provided via user interface element 906 (depicted as a dropdown menu in this example), but other elements can be expected for providing the attribute value. The value selectable from user interface element 906 may include a set of predefined values ​​(e.g., public, OCI internal, private, etc.). In some embodiments, user interface 900 may present information related to the value selection. For example, information about a specific namespace type may be presented at 908.

[0168] As illustrated, the user interface 900 may include a user interface element 910 for selecting a value corresponding to the attribute influence ring level (e.g., corresponding to...). Figure 4The recoveryRingLevel property of the skill data structure 410. User interface element 912 (here, an edit box) can be used to provide one or more aliases and / or descriptors to aid skill discovery. In some embodiments, this input is optional and is indicated in the user interface 900. If input is provided, these values ​​can be associated with a set of names corresponding to the name property of the skill data structure 410.

[0169] User interface element 914, depicted as a drop-down menu in user interface 900, can be used to select one or more skill groups that, if a skill is created, will be associated with it. A skill group can be a logical group of skills associated with a common skill group identifier (e.g., a name). In some embodiments, the value selectable within user interface element 914 can be populated with a previously defined list of skill group names. In some embodiments, input to user interface element 914 is optional, and is thus indicated in user interface 900.

[0170] Figure 10 This is a block diagram depicting an example user interface 1000 for obtaining dependency data for creating skills, according to at least one embodiment. The user interface 1000 may include any suitable combination of user interface elements for obtaining data related to... Figure 4 The values ​​of any suitable number of attributes corresponding to the skill metadata 404. For example, user interface 1000 may include user interface element 1002 from which another skill can be selected. In some embodiments, the values ​​selectable via user interface element 1002 may include any suitable previously known skills (e.g., skills associated with the selected namespace and / or region). In some embodiments, user interface 1000 may include user interface element 1004 for selecting a known version of the skill selected via user interface element 1002.

[0171] User interface element 1006 can be selected to indicate that the skill being created / defined will be applied during region construction, while user interface element 1008 can be selected to indicate that the skill will be applied at runtime. Selecting user interface element 1008 allows user interface 1000 to be updated with additional options (e.g., additional option 1010) related to aspects / attributes of the defined skill's runtime impact. This can be (e.g., via...) Figure 4 The skill user data structure 418 stores one or more values ​​representing the selection of user interface elements 1006 and 1008 and any appropriate selection made for the additional option 1010.

[0172] The user interface 1000 can initially include region 1012, but additional regions (e.g., region 1014, region 1016, etc.) can be added by selecting option 1018. Previously added regions can be deleted, at least in part, based on selecting a removal option. For example, region 1014 can be removed by selecting the corresponding removal option 1020.

[0173] Regions 1012, 1014, and 1016 each represent dependencies associated with the current skill (e.g., block storage control plane skill 1) and provide information related to the skills the current skill depends on, the circumstances under which the dependencies apply (e.g., during build time, during runtime), and one or more potential runtime effects when the dependencies apply at runtime. In some embodiments, region 1022 may be used to present a graphical representation of the dependencies defined within regions 1012, 1014, and 1016 for the current skill (e.g., block storage control plane skill 1) being created. Each element shown in region 1022 may include options for displaying additional data associated with that skill. For example, selecting option 1024 may cause the user to be navigated to a location similar to... Figure 16 The user interface is 1600, but it points to the skill associated with the name "Flamingo Skill 2". (This is in conjunction with...) Figure 5 The options discussed are similar; user interface 1000 may include option 1026, which, if selected, may cause element 1028 to be updated to display all versions associated with block storage control plane skill 1 (skill versions with the same name as the skill currently being created).

[0174] In some embodiments, the user interface 1000 includes an orientation option 1028. As illustrated, the value currently selected via the orientation option 1028 indicates a horizontal orientation. However, option 1028 may provide a mechanism for the user to adjust to a vertical orientation.

[0175] Figure 11 This is a block diagram depicting an example user interface 1100 for obtaining observability data for creating skills, according to at least one embodiment. The user interface 1100 may include any suitable combination of user interface elements for obtaining observability data for creating skills. Figure 4 The skill metadata 404 corresponds to the values ​​of any suitable number of attributes. For example, the user interface 1100 may include a user interface element 1102 through which alert labels (e.g., name, identifier, etc.) can be entered. In some embodiments, the values ​​provided via user interface element 1102 may correspond to... Figure 4The attribute values ​​are stored within the health check data structure 414. Any suitable number of alarm tags can be added via selection option 1104. In some embodiments, a backup alarm system (referred to as a "sentinel") can be utilized when the typical alarm service is unavailable / off. In some embodiments, user interface element 1106 can be used to provide values ​​corresponding to the alarm tags of the additional alarm service. Option 1108 can be selected any suitable number of times to insert additional user interface elements, through which any suitable number of alarm tags can be provided to the additional alarm service.

[0176] In some embodiments, region 1110 may provide any suitable number of user interface elements, wherein several attribute values ​​corresponding to the service health data log can be specified. Region 1112 may present... Figure 10 The data presented in region 1022 is similar to the data presented in other regions.

[0177] Figure 12 This is a block diagram depicting an example user interface 1200 for publishing / creating a skill, as described according to at least one embodiment. The user interface 1200 may present attributes (keys) and attribute values ​​(values) corresponding to user input provided via user interfaces 800-1100 within region 1202. In some embodiments, the user interface 1200 may include option 1204. Selecting option 1204 allows data to be formatted according to a predetermined data serialization language or markup language (e.g., YAML, XML, etc.) and stored in a predefined or user-defined storage location. In some embodiments, the user interface 1200 may include option 1206. Selecting option 1206 allows the skill to be published or otherwise made available. When the namespace type provided for the skill is "private," selecting option 1206 allows the skill to be published immediately. In some embodiments, private skills will not be subject to review committee constraints. However, if the namespace type provided for the skill is "public" or "OCI internal," a similar option may be provided, if selected, to provide the skill metadata provided via user interfaces 800-1100 to the review committee for review. Providing this data to the review committee may include transmitting and / or storing data according to a predefined protocol, so that the review committee can access this data via one or more documents and / or one or more user interfaces provided by CIOS 102 or a completely independent system.

[0178] Figure 13 This is a block diagram depicting an example user interface 1300 for creating skill groups according to at least one embodiment. In response to selection... Figure 7Option 722 can present user interface 1300 to the user. User interface 1300 may include user interface element 1302, through which the skill group name can be provided as input. Similarly, user interface element 1304 can be used to provide user input corresponding to the skill group description.

[0179] In some embodiments, one or more skills can be assigned to a defined skill group. In some embodiments, user interface element 1306 can be used to assign skills to the group. Values ​​presented via user interface element 1306 can include any previously defined skills. In some embodiments, user interface element 1306 can be configured to enable the selection of a single skill. User interface element 1308 can be used to specify a particular version of the selected skill. Values ​​selectable from user interface element 1308 can be determined based on previously identified versions associated with the selected skill. User interface element 1310 can be selected to add additional user interface elements (e.g., additional user interface elements similar to user interface elements 1302-1308), which can be used to identify additional skills associated with the defined skill group. Any suitable number of skills can be associated with a single skill group.

[0180] User interface 1300 may include option 1312, selecting which cancels the operation associated with creating the skill set, and user interface 1300 can be removed from the display. User interface element 1314 may be provided as an option to continue creating the skill set. Selecting user interface element 1314 allows Puffin Center 118 to perform any appropriate operation to create the skill set (e.g., by...). Figure 4 (An instance representation of the skill set data structure 420). For example, the Puffin Center 118 can generate a new instance of the skill set data structure 420 and store the attribute values ​​provided via the user interface 1300 in the newly generated data structure for later use.

[0181] Figure 14This is a block diagram depicting an example user interface 1400 for editing skill groups associated with a skill, according to at least one embodiment. User interface 1400 may be presented in response to the selection of option 726, for example (e.g., the option corresponding to a skill titled "Skill 2"). Options 1402 and 1404 (or any suitable number of options) may be used to present the corresponding group associated with "Skill 2". Selecting a removal option (e.g., removal option 1406) may cause the corresponding user interface element (e.g., user interface element 1402) to be removed from user interface 1400. A skill may be associated with any suitable number of additional skill groups based at least in part on selection option 1408. Selecting option 1408 may cause user interface 1400 to be updated using an additional user interface element similar to user interface element 1402, through which additional associations with skill groups may be specified. Selecting option 1410 may cancel the removal of user interface 1400 from the display without making any changes to the skill group associations corresponding to the skill. Selecting option 1412 allows the application to update the skill group association corresponding to the skill via any changes to the user interface elements of user interface 1400 (e.g., update the association between one or more skill group data structure instances and the instance of skill data structure 410 corresponding to the "Skill 2" skill).

[0182] Figure 15 This is a block diagram depicting an example user interface 1500 that presents information associated with a selected skill according to at least one embodiment. In some embodiments, the user interface 1500 may be at least partially based on information from... Figure 1 Select from the skill catalog hosted in Puffin Center 118 Figure 7 Option 728 is used to present the selected skill. Generally, the user interface 1500 can be configured to present the skill corresponding to the selected skill (e.g., Block Storage Control Plane Skill 2 in this example). Figure 4 Any suitable skill metadata 404. Data presented via user interface 1500 can be compared with... Figure 15 The examples drawn in the text are presented or formatted in different ways.

[0183] Region 1502 can present any suitable combination of attributes and their corresponding values ​​according to a predefined format. As a non-limiting example, Region 1502 includes creation date, update data, compartment identifier, unique system identifier (e.g., OCID), influence ring level, namespace type, one or more health alert labels associated with the selected skill, and description.

[0184] Region 1504 may provide one or more user interface elements corresponding to the selection filter options. Values ​​selected via the user interface elements of region 1504 can be used to update or modify user interface 1500 to include attributes and values ​​associated with the version and / or region of the selected skill. User interface 1500 may include user interface element 1506, which can be configured to display the health status associated with the skill (e.g., stored in...). Figure 4 The health status (in the skill version data structure 412) is indicated. Similarly, user interface element 1508 can be used to present an indication of the lifecycle status associated with the skill (e.g., "Installed"). (e.g., the installation status stored in the skill version data structure 412 and associated with the selected skill). The presented lifecycle status can correspond to the following combination... Figure 16 One of the lifecycle states discussed.

[0185] User interface 1500 may include refresh option 1510. Selecting this option allows Puffin Center 118 to be re-obtained and rendered. Figure 15 The values ​​corresponding to the attributes described in the text.

[0186] User interface 1500 may include region 1512, which can be configured to present any suitable combination of attributes and corresponding values ​​in skill version data structure 412. Option 1513 can be selected to extend the regions of user interface 1500 to present data in regions 1516 and 1522. Region 1516 may present a health dependency tree generated for the selected skill. In some embodiments, the health dependency tree may be generated by the Puffin service in response to receiving an indication (e.g., from an alarm service) that one or more alarms associated with the selected skill have been triggered. As a non-limiting example, the Puffin service may identify BSCP skill 2 as unhealthy (e.g., due to receiving an indication that a specific alarm has been triggered). The health dependency tree presented in region 1516 may be generated at least in part based on an up- or down-down traversal of a dependency graph based on all service metadata 402 instances and skill metadata 404 instances corresponding to each service and skill associated with the same build, operation, or region associated with BSCP skill 2.

[0187] By traversing up and down the dependency graph and determining the corresponding health status of nodes in the graph that correspond to other skills, one or more skills can be identified as potential causes of the health status of BSCP skill 2. For example, the Puffin service can traverse the dependency graph upwards to identify IDDP skill 1, which is also unhealthy (v.1.0.0.1), but higher-level skills in the graph that are used by IDDP skill 1 (meaning the skills that IDDP skill 1 depends on) are healthy. At least in part, based on the determination that IDDP skill 1 is unhealthy and is the highest-level skill in the dependency graph starting from the node corresponding to BSCP skill 2, IDDP skill 1 can be identified as a potential cause of the current health status associated with BSCP skill 2. Similarly, additional affected skills can be identified at lower levels in the dependency graph (e.g., based on the health status of using (dependent on) one or more skills (e.g., BSCP skill 2), which are identified as the possible cause of the health status indicated at user interface element 1506). Region 1516 can identify several skill users (skills dependent on the possible cause skill, i.e., IDDP skill 1, v.1.0.0.1) as "Level 1 effects," thereby indicating skills that directly depend on the possible cause skill. Region 1516 can also identify several skill users (e.g., skills that ultimately and indirectly depend on the possible cause skill). These skills further downstream than the Level 1 affected skills can be referred to as "Level 2 effects" within Region 1516.

[0188] In some embodiments, region 1522 may include any suitable additional data related to the causal analysis of the unhealthy state of the currently selected skill (e.g., identifying one or more possible causes). In some embodiments, the user can select option 1514 to rerun the tracing (e.g., an operation performed by the Puffin service to traverse the dependency graph and check the health status of each node to determine one or more skills that may be contributing factors to the current health status of the selected skill). In some embodiments, region 1522 may enable any suitable portions of the contact information (e.g., previously accessed via...). Figure 8 (Data recognized by the user interface 800). Selecting one of the options provided within region 1522 allows contact information to be copied and / or used to communicate any appropriate portion of the unhealthy condition and / or facilitate cause analysis data. For example, selecting option 1524 allows previously specified contact information to be used to request the service team associated with IDDP skill 1, v.1.0.0.1 to report to the specified location to troubleshoot a failure in the current status of its corresponding skill.

[0189] In some embodiments, additional options are provided within region 1526. These additional options may correspond to tracking alert labels, viewing dependency graphs (e.g., similar to...). Figure 6The graph generated and presented within region 616 presents skill metadata corresponding to the direct user (e.g., skills that directly depend on the selected skill) and the transferred capabilities associated with the selected skill.

[0190] Figure 16 This is a block diagram depicting an example lifecycle 1600 of a skill according to at least one embodiment. Lifecycle 1600 may include any suitable number of states. As illustrated, lifecycle 1600 includes states such as declared, selected, not selected, installing, installed, banned, retired, and uninstalling, but other combinations of lifecycle states are contemplated. In some embodiments, lifecycle states may be associated with several sub-states. For example, and as... Figure 16 As illustrated, skills associated with the "Installed" lifecycle state can be associated with one of three sub-states (e.g., "Unknown," "Unhealthy," and "Healthy"). Similarly, skills associated with the "Banned" state can be associated with either the "Healthy" or "Unhealthy" sub-state. A description of the conditions indicated by each state is provided below.

[0191]

[0192] In some embodiments, at step 1, after selecting option 1204 to publish a skill (e.g., a private skill), an instance of the skill version data structure 412 corresponding to the skill can be created and updated to indicate an "declared" installation status. At step 2, if and when orchestrator 106 selects to install the skill within a target region (e.g., target region 103), then the skill version data structure 412 can be updated to "selected." At step 3, if and when orchestrator begins deploying the resources of the service that generates the associated skill, then the skill's installation status can be updated to "installing." At step 4, when the installation of the service that generates the associated skill has been successfully completed, the skill's installation status can be updated to "installed." When a skill is associated with the "installed" status, the Puffin service can monitor the health of the skill. In some embodiments, monitoring the health of a skill may include indicating whether one or more alerts associated with the skill have been triggered. In some embodiments, if the alert service configured to provide these alerts is unavailable, the sub-state corresponding to the "healthState" property of the skill version data structure 412 can be updated to indicate an "unknown" health state of the installed skill. If no alerts are triggered for at least a threshold time period, the healthState property of the skill version can be updated to indicate a "healthy" state of the installed skill. Receiving an indication that an alert associated with the skill has been triggered can cause the Puffin service to update the healthState property of the skill version of the installed skill to "unhealthy".

[0193] At step 5, the installation status may be updated to "Blocked" (e.g., by the orchestrator and / or based on user input) to indicate that health monitoring should continue, but only skills that produce the same service should be considered as installed if they are blocked. In some embodiments, the installation status of a skill may be restored to "Installed".

[0194] In some embodiments, a skill version may be decommissioned at step 6 (e.g., via user input). When in a decommissioned state, the skill version cannot (or should not) be used by other skills and / or any builds or runs. In some embodiments, the installation state of a skill version cannot be changed once it is decommissioned.

[0195] In some embodiments, the installation status of a skill version can change from an "Installed" state to an "Uninstalling" state, at least in part, based on actions performed by the orchestrator and / or user input. In some embodiments, the orchestrator 106 can determine a service deployment to be undone. In these cases, the orchestrator 106 can "uninstall" one or more services. During these operations, when a service is uninstalled at step 7, the associated skill version can be updated to indicate an "Uninstalling" state. When the service associated with the skill version is successfully uninstalled, the installation status of the skill version can be updated to "Selected" at step 8.

[0196] Several transitions between various states and substates can be expected. Figure 16 The life cycle states and transitions depicted are illustrative and are not intended to limit the scope of this disclosure.

[0197] Figure 17 The diagram illustrates a component utilizing a skill service according to at least one embodiment (e.g., Figure 1 A flowchart of an example method 1700 for generating a dependency graph of skills (any suitable combination of Puffin center 118 and Puffin region 120). In some embodiments, the dependency graph can be used to verify the construction of the dependency graph (e.g., Figure 3 (Build dependency graph 338). In some embodiments, the dependency graph can be used in place of the build dependency graph 338. The operations of method 1700 can be performed in any suitable order. It is expected that method 1700 may include more than Figure 17 The number of operations shown is more or less.

[0198] Method 1700 can begin at 1702, where a cloud computing service (e.g., Puffin service) prepares a user interface configured to receive corresponding skill metadata that defines multiple skills corresponding to multiple services, which will be bootstrapping during the construction of the region corresponding to the data center. Figures 8-11 Each provides an example of a user interface, through which one can obtain... Figure 4 Any appropriate part of the skill metadata 404.

[0199] At point 1704, a first skill and a second skill are maintained among a plurality of skills. In some embodiments, the first skill corresponds to a first service function, and the second skill corresponds to a second service function. In some embodiments, the first skill indicates a dependency on the second skill. For example, the first skill may be associated with a skill user data structure (e.g., Figure 4This is associated with a skill user data structure 418, which can be used to indicate a dependency on another skill (e.g., via the consumingSkillID of the skill user data structure or any suitable attribute).

[0200] At point 1706, a cloud computing service can generate a dependency graph, at least in part, based on multiple skills corresponding to multiple services. In some embodiments, the dependency graph indicates the dependency relationship between a first skill and a second skill. An example of a portion of this graph can be found in... Figure 6 The region is described in area 616.

[0201] At point 1706, the cloud computing service can provide at least a portion of the dependency graph to the user device for use in the user interface (e.g., Figure 6 The user interface is presented at 600. In some embodiments, the user interface provides navigation options associated with navigation within the dependency graph (e.g., ...). Figure 6 (644 and 646). In some embodiments, the dependency graph represents building a dependency graph (e.g., building dependency graph 338), an orchestrator (e.g., Figure 1 The orchestrator 106) uses this build dependency graph to bootstrap multiple services during region build.

[0203] Example cloud service infrastructure architecture

[0204] As noted above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, cloud providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also offer various services to accompany these infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Therefore, because these services may be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

[0205] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create buckets for workloads and backups, and even install enterprise software into that VM. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0206] In most cases, cloud computing models will require the involvement of cloud providers. Cloud providers can, but are not necessarily, third-party providers specializing in (e.g., provisioning, renting, selling) IaaS services. Entities may also choose to deploy private clouds, thus becoming their own infrastructure service providers.

[0207] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the processing of server preparation (e.g., installation libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for processing (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

[0208] In some examples, IaaS provisioning can refer to acquiring computers or virtual hosts for use, or even installing necessary libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0209] In some cases, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning the initial infrastructure set before anything is operational. Second, once everything is provisioned, there's the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows for creating and / or managing the different components described in the configuration files can be generated.

[0210] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, one or more inbound / outbound traffic group rules may also be provided to define how inbound / outbound traffic to the network and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and / or more infrastructure elements are expected and added.

[0211] In some cases, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that they expect to deploy to one or more, but often many, different production environments (e.g., across various geographical locations, sometimes spanning the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed using deployment tools.

[0212] Figure 18This is a block diagram 1800 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service operator 1802 may communicatively couple to secure host lease 1804, which may include a virtual cloud network (VCN) 1806 and a secure host subnet 1808. In some examples, service operator 1802 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software (such as Microsoft Windows Mobile®) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supporting the Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices can be workstation computers running a variety of commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, client computing devices can be any other electronic device, such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices capable of communicating over a network that can access VCN 1806 and / or the internet.

[0213] VCN 1806 may include a local peering gateway (LPG) 1810, which may be communicatively coupled to a secure shell (SSH) VCN 1812 via LPG 1810 included in SSH VCN 1812. SSH VCN 1812 may include an SSH subnet 1814, and SSH VCN 1812 may be communicatively coupled to a control plane VCN 1816 via LPG 1810 included in control plane VCN 1816. Furthermore, SSH VCN 1812 may be communicatively coupled to a data plane VCN 1818 via LPG 1810. Control plane VCN 1816 and data plane VCN 1818 may be contained within a service lease 1819 that may be owned and / or operated by an IaaS provider.

[0214] The control plane VCN 1816 may include a control plane demilitarized zone (DMZ) layer 1820 that acts as a peripheral network (e.g., part of a corporate network between a corporate intranet and an external network). DMZ-based servers can assume limited liability and help control vulnerabilities. Furthermore, the DMZ layer 1820 may include one or more load balancer (LB) subnets 1822, a control plane application layer 1824 that may include one or more application subnets 1826, and a control plane data layer 1828 that may include one or more database (DB) subnets 1830 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets 1822 contained in the control plane DMZ layer 1820 may be communicatively coupled to one or more application subnets 1826 contained in the control plane application layer 1824 and an Internet gateway 1834 that may be contained in the control plane VCN 1816. The application subnets 1826 may be communicatively coupled to one or more DB subnets 1830 contained in the control plane data layer 1828, as well as a service gateway 1836 and a Network Address Translation (NAT) gateway 1838. The control plane VCN 1816 may include the service gateway 1836 and the NAT gateway 1838.

[0215] The control plane VCN 1816 may include a data plane mirror application layer 1840, which may include one or more application subnets 1826. The one or more application subnets 1826 included in the data plane mirror application layer 1840 may include a virtual network interface controller (VNIC) 1842 capable of executing a compute instance 1844. The compute instance 1844 may communicatively couple the one or more application subnets 1826 of the data plane mirror application layer 1840 to the one or more application subnets 1826 that may be included in the data plane application layer 1846.

[0216] Data plane VCN 1818 may include data plane application layer 1846, data plane DMZ layer 1848, and data plane data layer 1850. Data plane DMZ layer 1848 may include one or more LB subnets 1822 communicatively coupled to one or more application subnets 1826 of data plane application layer 1846 and Internet gateway 1834 of data plane VCN 1818. One or more application subnets 1826 may be communicatively coupled to service gateway 1836 and NAT gateway 1838 of data plane VCN 1818. Data plane data layer 1850 may also include one or more DB subnets 1830 communicatively coupled to one or more application subnets 1826 of data plane application layer 1846.

[0217] The Internet gateway 1834 of the control plane VCN 1816 and data plane VCN 1818 can be communicatively coupled to the metadata management service 1852, which can be communicatively coupled to the public Internet 1854. The public Internet 1854 can be communicatively coupled to the NAT gateway 1838 of the control plane VCN 1816 and data plane VCN 1818. The service gateway 1836 of the control plane VCN 1816 and data plane VCN 1818 can be communicatively coupled to the cloud service 1856.

[0218] In some examples, the service gateway 1836 of the control plane VCN 1816 or data plane VCN 1818 can make application programming interface (API) calls to the cloud service 1856 without traversing the public internet 1854. API calls from the service gateway 1836 to the cloud service 1856 can be unidirectional: the service gateway 1836 can make API calls to the cloud service 1856, and the cloud service 1856 can send requested data to the service gateway 1836. However, the cloud service 1856 may not initiate API calls to the service gateway 1836.

[0219] In some examples, secure host lease 1804 can be directly connected to service lease 1819, which would otherwise be isolated. Secure host subnet 1808 can communicate with SSH subnet 1814 via LPG 1810, which enables bidirectional communication between otherwise isolated systems. Connecting secure host subnet 1808 to SSH subnet 1814 allows secure host subnet 1808 to access other entities within service lease 1819.

[0220] Control plane VCN 1816 may allow users of service lease 1819 to configure or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1816 may be deployed or otherwise used in data plane VCN 1818. In some examples, control plane VCN 1816 may be isolated from data plane VCN 1818, and the data plane mirror application layer 1840 of control plane VCN 1816 may communicate with the data plane application layer 1846 of data plane VCN 1818 via VNIC 1842, which may be included in both the data plane mirror application layer 1840 and the data plane application layer 1846.

[0221] In some examples, users or clients of the system can make requests, such as create, read, update, or delete (CRUD) operations, via the public internet 1854, which can transmit requests to the metadata management service 1852. The metadata management service 1852 can transmit requests to the control plane VCN 1816 via internet gateway 1834. Requests can be received by one or more LB subnets 1822 contained in the control plane DMZ layer 1820. The LB subnets 1822 can determine that the request is valid, and in response to this determination, they can transmit the request to one or more application subnets 1826 contained in the control plane application layer 1824. If the request is validated and requires a call to the public internet 1854, the call to the public internet 1854 can be transmitted to a NAT gateway 1838 that can make calls to the public internet 1854. The request may expect stored metadata to be stored in one or more DB subnets 1830.

[0222] In some examples, the data plane mirroring application layer 1840 can facilitate direct communication between the control plane VCN 1816 and the data plane VCN 1818. For example, it might be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN 1818. Through VNIC 1842, the control plane VCN 1816 can communicate directly with the resources contained in the data plane VCN 1818, and thus can perform configuration changes, updates, or other appropriate modifications.

[0223] In some embodiments, the control plane VCN 1816 and data plane VCN 1818 may be included in service lease 1819. In this case, the system's users or customers may not own or operate the control plane VCN 1816 or data plane VCN 1818. Alternatively, the IaaS provider may own or operate both the control plane VCN 1816 and data plane VCN 1818, and both planes may be included in service lease 1819. This embodiment can enable the isolation of networks that might prevent users or customers from interacting with resources from other users or customers. Furthermore, this embodiment can allow users or customers of the system to privately store databases without relying on the public Internet 1854, which may not have the desired level of threat prevention for storage.

[0224] In other embodiments, one or more LB subnets 1822 included in the control plane VCN 1816 may be configured to receive signals from the service gateway 1836. In this embodiment, the control plane VCN 1816 and the data plane VCN 1818 may be configured to be invoked by the IaaS provider's customers without invoking the public internet 1854. The IaaS provider's customers may expect this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on a service lease 1819, which may be isolated from the public internet 1854.

[0225] Figure 19 This is a block diagram 1900 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1902 (e.g., Figure 18 Service providers (1802) can communicatively couple to secure host leases (1904, e.g., Figure 18 Secure hosting lease 1804), the secure hosting lease 1904 may include a virtual cloud network (VCN) 1906 (e.g., Figure 18 VCN 1806) and Secure Host Subnet 1908 (e.g., Figure 18 The secure host subnet 1808). VCN 1906 may include a local peering gateway (LPG) 1910 (e.g., Figure 18 The LPG 1810), which can be communicatively coupled to the Secure Shell (SSH) VCN 1912 (e.g., via the LPG 1810 contained in the SSH VCN 1912) Figure 18 SSH VCN 1812). SSH VCN 1912 can include SSH subnet 1914 (e.g., Figure 18 SSH subnet 1814), and SSH VCN 1912 can be communicatively coupled to control plane VCN 1916 via LPG 1910 contained in control plane VCN 1916 (e.g., Figure 18 Control plane VCN 1816). Control plane VCN 1916 may be included in service lease 1919 (e.g., Figure 18 In the service lease 1819), and the data plane VCN 1918 (e.g., Figure 18 The data plane (VCN 1818) may be included in a customer lease 1921 that may be owned or operated by the system's users or customers.

[0226] Control plane VCN 1916 may include control plane DMZ layer 1920 (e.g., Figure 18 The control plane DMZ layer 1820), which may include one or more LB subnets 1922 (e.g., Figure 18 (One or more) LB subnets 1822), may include (one or more) application subnets 1926 (e.g., Figure 18 The control plane application layer 1924 of (one or more) application subnets 1826 (e.g., Figure 18 The control plane application layer 1824) may include one or more database (DB) subnets 1930 (e.g., similar to...). Figure 18 The control plane data layer 1928 of (one or more) DB subnets 1830 (e.g., Figure 18 The control plane data layer 1828). One or more LB subnets 1922 contained in the control plane DMZ layer 1920 can be communicatively coupled to one or more application subnets 1926 contained in the control plane application layer 1924 and an Internet gateway 1934 that can be contained in the control plane VCN 1916 (e.g., Figure 18 Internet gateway 1834), and application subnet(s) 1926 can communicatively couple to DB subnet(s) 1930 contained in control plane data layer 1928 and service gateway 1936 (e.g., Figure 18 Service gateway 1836) and Network Address Translation (NAT) gateway 1938 (e.g., Figure 18 (NAT gateway 1838). The control plane VCN 1916 may include the service gateway 1936 and the NAT gateway 1938.

[0227] The control plane VCN 1916 may include a data plane mirror of the application layer 1940, which may contain one or more application subnets 1926 (e.g., Figure 18 The data plane mirror application layer 1840). One or more application subnets 1926 contained in the data plane mirror application layer 1940 may include computational instances 1944 (e.g., similar to...). Figure 18 The virtual network interface controller (VNIC) 1942 (e.g., the VNIC of 1842) of the computing instance 1844. The computing instance 1944 may facilitate the mirroring of the application subnet(s) 1926 of the application layer 1940 in the data plane and may be included in the application layer 1946 in the data plane (e.g., Figure 18 Communication between one or more application subnets 1926 in the data plane application layer 1846 via VNIC 1942 contained in the data plane mirror application layer 1940 and VNIC 1942 contained in the data plane application layer 1946.

[0228] The Internet gateway 1934, included in the control plane VCN 1916, can be communicatively coupled to the metadata management service 1952 (e.g., Figure 18 Metadata management service 1852), which can communicatively couple to the public Internet 1954 (e.g., Figure 18 The public internet 1954 can communicatively couple to a NAT gateway 1938 contained in a control plane VCN 1916. A service gateway 1936 contained in a control plane VCN 1916 can communicatively couple to a cloud service 1956 (e.g., ...). Figure 18 Cloud services (1856).

[0229] In some examples, data plane VCN 1918 may be included in customer lease 1921. In this case, the IaaS provider may provide control plane VCN 1916 for each customer, and the IaaS provider may set up a unique compute instance 1944 for each customer, included in service lease 1919. Each compute instance 1944 may allow communication between control plane VCN 1916 included in service lease 1919 and data plane VCN 1918 included in customer lease 1921. Compute instance 1944 may allow resources provisioned in control plane VCN 1916 included in service lease 1919 to be deployed or otherwise used in data plane VCN 1918 included in customer lease 1921.

[0230] In other examples, an IaaS provider's customer may have a database residing in customer lease 1921. In this example, control plane VCN 1916 may include data plane mirror application layer 1940, which may include one or more application subnets 1926. Data plane mirror application layer 1940 may reside in data plane VCN 1918, but may not reside in data plane VCN 1918. That is, data plane mirror application layer 1940 may have access to customer lease 1921, but may not reside in data plane VCN 1918 or be owned or operated by an IaaS provider's customer. Data plane mirror application layer 1940 may be configured to invoke data plane VCN 1918, but may not be configured to invoke any entity contained in control plane VCN 1916. Customers may expect to deploy or otherwise use resources provisioned in the control plane VCN 1916 in the data plane VCN 1918, and the data plane mirroring application layer 1940 can facilitate customers' desired deployments or other uses of resources.

[0231] In some embodiments, an IaaS provider's customer can apply filters to data plane VCN 1918. In this embodiment, the customer can determine what data plane VCN 1918 can access, and the customer can restrict access from data plane VCN 1918 to the public Internet 1954. The IaaS provider may not be able to apply filters or otherwise control data plane VCN 1918's access to any external networks or databases. Applying filters and controls to data plane VCN 1918, which is included in customer lease 1921, can help isolate data plane VCN 1918 from other customers and the public Internet 1954.

[0232] In some embodiments, cloud service 1956 may be invoked by service gateway 1936 to access services that may not exist on public internet 1954, control plane VCN 1916, or data plane VCN 1918. The connection between cloud service 1956 and control plane VCN 1916 or data plane VCN 1918 may not be real-time or continuous. Cloud service 1956 may reside on different networks owned or operated by an IaaS provider. Cloud service 1956 may be configured to receive calls from service gateway 1936 and may be configured not to receive calls from public internet 1954. Some cloud services 1956 may be isolated from other cloud services 1956, and control plane VCN 1916 may be isolated from cloud services 1956 that may not be in the same region as control plane VCN 1916. For example, control plane VCN 1916 may be located in "Region 1," and cloud service "Deployment 18" may be located in both "Region 1" and "Region 2." If the service gateway 1936, contained in the control plane VCN 1916 located in region 1, makes a call to deployment 18, then that call can be transmitted to deployment 18 in region 1. In this example, the control plane VCN 1916 or deployment 18 in region 1 may not be communicatively coupled to or otherwise communicate with deployment 18 in region 2.

[0233] Figure 20 This is a block diagram 2000 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 2002 (e.g., Figure 18 Service providers (1802) can communicatively couple to secure host rental (2004) (e.g., Figure 18 Secure hosting lease 1804), the secure hosting lease 2004 may include Virtual Cloud Network (VCN) 2006 (e.g., Figure 18 VCN 1806) and Secure Host Subnet 2008 (e.g., Figure 18 The secure host subnet 1808). VCN 2006 can include LPG 2010 (e.g., Figure 18 The LPG 1810), which can be communicatively coupled to SSH VCN 2012 via the LPG 2010 included in SSH VCN 2012 (e.g., Figure 18 SSH VCN 1812). SSH VCN 2012 can include SSH subnets 2014 (e.g., Figure 18 SSH subnet 1814), and SSH VCN 2012 can be communicatively coupled to control plane VCN 2016 via LPG 2010 included in control plane VCN 2016 (e.g., Figure 18 The control plane VCN 1816) and coupled to the data plane VCN 2018 via the LPG 2010 contained in the data plane VCN 2018 (e.g., Figure 18 Data plane 1818). Control plane VCN 2016 and data plane VCN 2018 can be included in service lease 2019 (e.g., Figure 18 In the service rental (1819).

[0234] The control plane VCN 2016 may include one or more load balancer (LB) subnets 2022 (e.g., Figure 18 The control plane DMZ layer of (one or more) LB subnets 1822) 2020 (e.g., Figure 18 The control plane DMZ layer 1820 may include one or more application subnets 2026 (e.g., similar to...). Figure 18 The control plane application layer 2024 of (one or more) application subnets 1826 (e.g., Figure 18 The control plane application layer 1824), which may include (one or more) DB subnets 2030, and the control plane data layer 2028 (e.g., Figure 18 The control plane data layer 1828). One or more LB subnets 2022 contained in the control plane DMZ layer 2020 can be communicatively coupled to one or more application subnets 2026 contained in the control plane application layer 2024 and an Internet gateway 2034 that can be contained in the control plane VCN 2016 (e.g., Figure 18 Internet gateway 1834), and application subnet(s) 2026 can communicatively couple to DB subnet(s) 2030 contained in control plane data layer 2028 and service gateway 2036 (e.g., Figure 18 The service gateway) and Network Address Translation (NAT) gateway 2038 (e.g., Figure 18 (NAT gateway 1838). The control plane VCN 2016 may include service gateway 2036 and NAT gateway 2038.

[0235] Data plane VCN 2018 may include data plane application layer 2046 (e.g., Figure 18 Data plane application layer 1846), data plane DMZ layer 2048 (e.g., Figure 18 Data plane DMZ layer 1848), and data plane data layer 2050 (e.g., Figure 18 The data plane data layer 1850). The data plane DMZ layer 2048 may include one or more trusted application subnets 2060 and one or more untrusted application subnets 2062 that are communicatively coupled to the data plane application layer 2046, and one or more LB subnets 2022 that are included in the Internet gateway 2034 in the data plane VCN 2018. One or more trusted application subnets 2060 may be communicatively coupled to the service gateway 2036, the NAT gateway 2038, and the DB subnets 2030 included in the data plane VCN 2018. One or more untrusted application subnets 2062 may be communicatively coupled to the service gateway 2036 and the DB subnets 2030 included in the data plane VCN 2018. The data plane data layer 2050 may include one or more DB subnets 2030 that can be communicatively coupled to the service gateway 2036 contained in the data plane VCN 2018.

[0236] One or more untrusted application subnets 2062 may include one or more primary VNICs 2064(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 2066(1)-(N). Each tenant VM 2066(1)-(N) may be communicatively coupled to a corresponding application subnet 2067(1)-(N) that may be contained in a corresponding container egress VCN 2068(1)-(N), which may be contained in a corresponding customer lease 2070(1)-(N). A corresponding secondary VNIC 2072(1)-(N) may facilitate communication between one or more untrusted application subnets 2062 contained in the data plane VCN 2018 and the application subnets contained in the container egress VCN 2068(1)-(N). Each container egress VCN 2068(1)-(N) may include a NAT gateway 2038, which may communicatively couple to the public Internet 2054 (e.g., Figure 18 The public internet (1854).

[0237] The Internet gateway 2034, contained in the control plane VCN 2016 and the data plane VCN 2018, can communicatively couple to the metadata management service 2052 (e.g., Figure 18 A metadata management system 1852 is provided, which can communicatively couple to the public internet 2054. The public internet 2054 can communicatively couple to a NAT gateway 2038 contained in a control plane VCN 2016 and a data plane VCN 2018. A service gateway 2036 contained in a control plane VCN 2016 and a data plane VCN 2018 can communicatively couple to a cloud service 2056.

[0238] In some embodiments, the data plane VCN 2018 can be integrated with customer leases 2070. Such integration may be useful or desired by the IaaS provider's customers in certain situations, such as when support may be expected during code execution. Customers may provide code that could be destructive, might communicate with other customer resources, or might otherwise cause undesirable effects. In response, the IaaS provider can determine whether to run the code provided by the customer to the IaaS provider.

[0239] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be attached to a data plane layer application 2046. The code running this functionality may execute in VMs 2066(1)-(N) and may not be configured to run anywhere else on the data plane VCN 2018. Each VM 2066(1)-(N) may be connected to a customer lease 2070. The corresponding container 2071(1)-(N) contained in VMs 2066(1)-(N) may be configured to run the code. In this case, there may be dual isolation (e.g., container 2071(1)-(N) running the code, where container 2071(1)-(N) may be contained in at least one VM 2066(1)-(N) contained in an untrusted application subnet 2062), which can help prevent incorrect or otherwise unintended code from corrupting the IaaS provider's network or the networks of different customers. Container 2071(1)-(N) may be communicatively coupled to customer lease 2070 and may be configured to transmit or receive data from customer lease 2070. Container 2071(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN 2018. After the code execution is complete, the IaaS provider may terminate or otherwise dispose of container 2071(1)-(N).

[0240] In some embodiments, one or more trusted application subnets 2060 may run code that can be owned or operated by an IaaS provider. In this embodiment, one or more trusted application subnets 2060 may be communicatively coupled to one or more database subnets 2030 and configured to perform CRUD operations in one or more database subnets 2030. One or more untrusted application subnets 2062 may be communicatively coupled to one or more database subnets 2030, but in this embodiment, one or more untrusted application subnets may be configured to perform read operations in one or more database subnets 2030. Containers 2071(1)-(N) that may be contained in each customer's VM 2066(1)-(N) and may run code from the customer may not be communicatively coupled to one or more database subnets 2030.

[0241] In other embodiments, the control plane VCN 2016 and the data plane VCN 2018 may be coupled without direct communication. In this embodiment, there may be no direct communication between the control plane VCN 2016 and the data plane VCN 2018. However, communication can occur indirectly through at least one method. LPG 2010 may be established by an IaaS provider, which can facilitate communication between the control plane VCN 2016 and the data plane VCN 2018. In another example, the control plane VCN 2016 or the data plane VCN 2018 may invoke cloud service 2056 via service gateway 2036. For example, an invocation of cloud service 2056 from the control plane VCN 2016 may include a request for a service that can communicate with the data plane VCN 2018.

[0242] Figure 21 This is a block diagram 2100 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 2102 (e.g., Figure 18 The service provider 1802) can communicatively couple to the secure host lease 2104 (e.g., Figure 18 Secure hosting lease 1804), the secure hosting lease 2104 may include a virtual cloud network (VCN) 2106 (e.g., Figure 18 VCN 1806) and Secure Host Subnet 2108 (e.g., Figure 18 The secure host subnet 1808). VCN 2106 may include LPG 2110 (e.g., Figure 18 LPG 1810), the LPG 2110 can be contained in SSH VCN 2112 (e.g., Figure 18LPG 2110 in SSH VCN 2112 is communicatively coupled to SSH VCN 2112. SSH VCN 2112 may include SSH subnet 2114 (e.g., Figure 18 SSH subnet 1814), and SSH VCN 2112 can be communicatively coupled to control plane VCN 2116 via LPG 2110 included in control plane VCN 2116 (e.g., Figure 18 The control plane VCN 1816) and coupled to the data plane VCN 2118 via the LPG 2110 contained in the data plane VCN 2118 (e.g., Figure 18 Data plane 1818). Control plane VCN 2116 and data plane VCN 2118 may be contained in service lease 2119 (e.g., Figure 18 In the service rental (1819).

[0243] The control plane VCN 2116 may include one or more LB subnets 2122 (e.g., Figure 18 The control plane DMZ layer 2120 of (one or more) LB subnets 1822) (e.g., Figure 18 The control plane DMZ layer 1820 may include (one or more) application subnets 2126 (e.g., Figure 18 The control plane application layer 2124 of (one or more) application subnets 1826 (e.g., Figure 18 The control plane application layer 1824) may include one or more DB subnets 2130 (e.g., Figure 20 The control plane data layer 2128 of (one or more) DB subnets 2030 (e.g., Figure 18 The control plane data layer 1828). One or more LB subnets 2122 contained in the control plane DMZ layer 2120 can be communicatively coupled to one or more application subnets 2126 contained in the control plane application layer 2124 and an Internet gateway 2134 that can be contained in the control plane VCN 2116 (e.g., Figure 18 Internet gateway 1834), and application subnet(s) 2126 can communicatively couple to DB subnet(s) 2130 contained in control plane data layer 2128 and service gateway 2136 (e.g., Figure 18 The service gateway) and the Network Address Translation (NAT) gateway 2138 (e.g., Figure 18 (NAT gateway 1838). The control plane VCN 2116 may include the service gateway 2136 and the NAT gateway 2138.

[0244] Data plane VCN 2118 may include data plane application layer 2146 (e.g., Figure 18 Data plane application layer 1846), data plane DMZ layer 2148 (e.g., Figure 18 Data plane DMZ layer 1848), and data plane data layer 2150 (e.g., Figure 18 The data plane data layer 1850). The data plane DMZ layer 2148 may include one or more trusted application subnets 2160 that can be communicatively coupled to the data plane application layer 2146 (e.g., Figure 20 (one or more) trusted application subnets 2060) and (one or more) untrusted application subnets 2162 (e.g., Figure 20 The data plane VCN 2118 may include one or more untrusted application subnets 2062 and one or more LB subnets 2122 of Internet gateway 2134. One or more trusted application subnets 2160 may communicatively couple to service gateway 2136, NAT gateway 2138, and DB subnets 2130 in data plane VCN 2118. One or more untrusted application subnets 2162 may communicatively couple to service gateway 2136 and DB subnets 2130 in data plane VCN 2118. Data plane VCN 2150 may include one or more DB subnets 2130 that may communicatively couple to service gateway 2136 in data plane VCN 2118.

[0245] One or more untrusted application subnets 2162 may include a primary VNIC 2164(1)-(N) communicatively coupled to tenant virtual machines (VMs) 2166(1)-(N) residing within one or more untrusted application subnets 2162. Each tenant VM 2166(1)-(N) may run code in a corresponding container 2167(1)-(N) and is communicatively coupled to an application subnet 2126 that may be contained in a data plane application layer 2146 contained in a container egress VCN 2168. A corresponding secondary VNIC 2172(1)-(N) may facilitate communication between one or more untrusted application subnets 2162 contained in a data plane VCN 2118 and the application subnets contained in a container egress VCN 2168. The container egress VCN may include a public internet 2154 (e.g., Figure 18 The public internet (1854) uses NAT gateway 2138.

[0246] Internet gateway 2134, contained in control plane VCN 2116 and data plane VCN 2118, can be communicatively coupled to metadata management service 2152 (e.g., Figure 18 The metadata management system 1852 can communicatively couple to the public internet 2154. The public internet 2154 can communicatively couple to a NAT gateway 2138 contained in a control plane VCN 2116 and a data plane VCN 2118. The service gateway 2136 contained in a control plane VCN 2116 and a data plane VCN 2118 can communicatively couple to a cloud service 2156.

[0247] In some examples, Figure 21 The architecture shown in block diagram 2100 can be considered as... Figure 20 This is an exception to the pattern shown in the architecture diagram 2000, and this pattern may be what the IaaS provider's customers would expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer can access in real time the corresponding container 2167(1)-(N) contained in each customer's VM 2166(1)-(N). Container 2167(1)-(N) can be configured to invoke the corresponding auxiliary VNIC 2172(1)-(N) contained in one or more application subnets 2126 of the data plane application layer 2146, which may be contained in the container egress VCN 2168. The auxiliary VNIC 2172(1)-(N) can transmit the call to the NAT gateway 2138, which can then transmit the call to the public internet 2154. In this example, containers 2167(1)-(N), which can be accessed by clients in real time, can be isolated from the control plane VCN 2116 and from other entities contained in the data plane VCN 2118. Containers 2167(1)-(N) can also be isolated from resources from other clients.

[0248] In other examples, a client may use container 2167(1)-(N) to invoke cloud service 2156. In this example, the client may run code within container 2167(1)-(N) requesting a service from cloud service 2156. Container 2167(1)-(N) may transmit the request to auxiliary VNIC 2172(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public internet 2154. Public internet 2154 may transmit the request via internet gateway 2134 to one or more LB subnets 2122 contained in control plane VCN 2116. In response to determining that the request is valid, one or more LB subnets may transmit the request to one or more application subnets 2126, which may transmit the request to cloud service 2156 via service gateway 2136.

[0249] It should be recognized that the IaaS architectures 1800, 1900, 2000, and 2100 depicted in the figures may have other components besides those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be incorporated into embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different configurations or component arrangements.

[0250] In some embodiments, the IaaS system described herein may include application suites, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is the Oracle Cloud Infrastructure (OCI) provided by this assignee.

[0251] Figure 22 An example computer system 2200, in which various embodiments can be implemented, is illustrated. System 2200 can be used to implement any of the computer systems described above. As shown, computer system 2200 includes a processing unit 2204 that communicates with a plurality of peripheral subsystems via a bus subsystem 2202. These peripheral subsystems may include a processing acceleration unit 2206, an I / O subsystem 2208, a storage subsystem 2218, and a communication subsystem 2224. Storage subsystem 2218 includes a tangible computer-readable storage medium 2222 and system memory 2210.

[0252] Bus subsystem 2202 provides a mechanism for allowing various components and subsystems of computer system 2200 to communicate with each other as intended. While bus subsystem 2202 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 2202 can be any of several types of bus architectures, including memory buses or memory controllers, peripheral buses, and local buses using any of the various bus architectures. For example, such architectures may include Industry Standard Architecture (ISA) buses, Microchannel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses, which may be implemented as Mezzanine buses manufactured according to the IEEE P1386.1 standard.

[0253] A processing unit 2204, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 2200. One or more processors may be included in the processing unit 2204. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 2204 may be implemented as one or more independent processing units 2232 and / or 2234, each including a single-core or multi-core processor. In other embodiments, the processing unit 2204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0254] In various embodiments, processing unit 2204 can execute various programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in processor(s) 2204 and / or storage subsystem 2218. With appropriate programming, processor(s) 2204 can provide the various functions described above. Computer system 2200 may additionally include processing acceleration unit 2206, which may include digital signal processor (DSP), dedicated processor, etc.

[0255] I / O subsystem 2208 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into a display, scroll wheels, click wheels, dials, buttons, switches, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor, which enables users to control and interact with input devices such as the Microsoft Xbox® 360 game controller via a natural user interface using gestures and voice commands. User interface input devices may also include eye posture recognition devices, such as the Google Glass® blink detector, which detects eye activity from the user (e.g., “blinking” when taking a photo and / or making menu selections) and translates the eye posture into input in an input device (e.g., Google Glass®). Furthermore, user interface input devices may include voice recognition sensing devices that enable users to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0256] User interface input devices may also include, but are not limited to, 3D mice, joysticks or pointing sticks, game panels and drawing tablets, as well as audio / video devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positron emission tomography (PET), and medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0257] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices, etc. Display subsystems may be cathode ray tubes (CRTs), flat panel devices such as those using liquid crystal displays (LCDs) or plasma displays, projection devices, touchscreens, etc. Generally, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 2200 to a user or other computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0258] Computer system 2200 may include storage subsystem 2218, which provides a tangible, non-transitory, computer-readable storage medium for storing software and data constructs that provide the functionality described in the embodiments of this disclosure. The software may include programs, code modules, instructions, scripts, etc., which, when executed by one or more cores or processors of processing unit 2204, provide the aforementioned functionality. Storage subsystem 2218 may also provide a repository for storing data used according to this disclosure.

[0259] like Figure 22 As illustrated in the example, storage subsystem 2218 may include various components, including system memory 2210, computer-readable storage medium 2222, and computer-readable storage medium reader 2220. System memory 2210 may store program instructions that can be loaded and executed by processing unit 2204. System memory 2210 may also store data used during instruction execution and / or data generated during program instruction execution. Various types of programs may be loaded into system memory 2210, including but not limited to client applications, web browsers, middleware applications, relational database management systems (RDBMS), virtual machines, containers, etc.

[0260] System memory 2210 may also store operating system 2216. Examples of operating system 2216 may include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.) and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS. In some implementations where computer system 2200 executes one or more virtual machines, the virtual machine and its guest operating system (GOS) may be loaded into system memory 2210 and executed by the core of one or more processors or processing unit 2204.

[0261] System memory 2210 can have different configurations depending on the type of computer system 2200. For example, system memory 2210 can be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM), flash memory, etc.). Different types of RAM configurations can be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), etc. In some embodiments, system memory 2210 may include a basic input / output system (BIOS), which contains basic routines that facilitate the transfer of information between components within computer system 2200, such as during startup.

[0262] Computer-readable storage medium 2222 may represent remote, local, fixed and / or removable storage devices and storage media for temporarily and / or more permanently containing and storing computer-readable information for use by computer system 2200, including instructions executable by processing unit 2204 of computer system 2200.

[0263] Computer-readable storage medium 2222 may include any suitable medium known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage devices, or other tangible computer-readable media.

[0264] For example, computer-readable storage medium 2222 may include hard disk drives that read from or write to non-removable non-volatile magnetic media, disk drives that read from or write to removable non-volatile magnetic disks, and optical disc drives that read from or write to removable non-volatile optical discs (such as CD ROMs, DVDs, and Blu-ray® discs or other optical media). Computer-readable storage medium 2222 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash memory drives, Secure Digital (SD) cards, DVD discs, digital audio tapes, and so on. Computer-readable storage medium 2222 may also include solid-state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, etc.), volatile memory-based SSDs (such as solid-state RAM, dynamic RAM, static RAM), DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs using a combination of DRAM-based and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage for computer-readable instructions, data structures, program modules and other data for computer system 2200.

[0265] Machine-readable instructions executable by one or more processors or cores of processing unit 2204 may be stored on a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile memory devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard disk drives, floppy disk drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0266] The communication subsystem 2224 provides an interface to other computer systems and networks. The communication subsystem 2224 serves as an interface for receiving data from other systems and sending data from computer system 2200 to other systems. For example, the communication subsystem 2224 enables computer system 2200 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 2224 may include radio frequency (RF) transceiver components (e.g., advanced data network technologies using cellular telephone technologies, such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), GPS receiver components, and / or other components for accessing wireless voice and / or data networks. In some embodiments, as an addition to or alternative to the wireless interface, the communication subsystem 2224 may provide a wired network connection (e.g., Ethernet).

[0267] In some embodiments, the communication subsystem 2224 may also represent one or more users who may use the computer system 2200 to receive input communications in the form of structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, etc.

[0268] For example, the communication subsystem 2224 can be configured to receive data feeds 2226 in real time from users of social networks and / or other communication services, such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0269] Furthermore, the communication subsystem 2224 can also be configured to receive data in the form of a continuous data stream, which may include event streams 2228 and / or event updates 2230 that are essentially continuous or unbounded real-time events without a clearly defined termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and so on.

[0270] The communication subsystem 2224 can also be configured to output structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, etc. to one or more databases, which can communicate with one or more streaming data source computers coupled to the computer system 2200.

[0271] The computer system 2200 can be one of a variety of types, including handheld portable devices (e.g., iPhone® cellular phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google® Glass head-mounted displays), PCs, workstations, mainframes, information stations, server racks, or any other data processing system.

[0272] Due to the constantly evolving nature of computers and networks, the description of the computer system 2200 depicted in the figures is merely a concrete example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may be used and / or specific elements may be implemented using hardware, firmware, software (including applets), or combinations thereof. Additionally, connections to other computing devices, such as network input / output devices, may also be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods for implementing the various embodiments.

[0273] The embodiments may be implemented using a computer program product comprising a computer program / instructions that, when executed by a processor, cause the processor to perform any of the methods described in this disclosure.

[0274] While specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within certain specific data processing environments, but can be freely operated within multiple data processing environments. Furthermore, although the embodiments have been described using a specific series of transactions and steps, those skilled in the art will understand that the scope of this disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above embodiments can be used individually or in combination.

[0275] Furthermore, while embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments may be implemented using only hardware, or only software, or a combination thereof. The various processes described herein can be implemented in any combination on the same processor or on different processors. Accordingly, where a component or service is described as being configured to perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits to perform operations, by programming programmable electronic circuits (such as microprocessors), or any combination thereof. Processes may communicate using a variety of technologies, including but not limited to conventional technologies for inter-process communication, and different pairs of processes may use different technologies, or the same pair of processes may use different technologies at different times.

[0276] Accordingly, the specification and drawings are intended to be illustrative rather than restrictive. However, it will be apparent that additions, omissions, deletions, and other modifications and alterations may be made thereto without departing from the broader spirit and scope set forth in the claims. Thus, while specific disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0277] In the context of describing the disclosed embodiments (particularly in the context of the following claims), the terms “a,” “an,” and “the,” and similar designations, are to be interpreted as encompassing both singular and plural, unless otherwise indicated herein or clearly contradicted by the context. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” are to be interpreted as open-ended terms (i.e., meaning “including but not limited to”). The term “connected” should be interpreted as partially or wholly contained in, attached to, or joined together, even if something exists in between. Unless otherwise indicated herein, the enumeration of value ranges herein is intended only as a shorthand method for individually referencing each individual value falling within that range, and each individual value is incorporated into the specification as if it were individually enumerated herein. Unless otherwise indicated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended only to better illustrate the embodiments and does not constitute a limitation on the scope of this disclosure, unless otherwise stated. Nothing in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0278] Disjunctive language, such as the phrase “at least one of X, Y, or Z”, unless otherwise explicitly stated, is intended to be understood in the context generally used to represent items, terms, etc., and may be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is generally not intended to, and should not, imply that some embodiments require the presence of at least one of X, at least one of Y, or at least one of Z, each individually.

[0279] This document describes preferred embodiments of the present disclosure, including the best modes known for carrying out the present disclosure. Variations of those preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to suitably employ such variations and may practice the present disclosure in ways other than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents to the subject matter recited in the appended claims, where permitted by applicable law. Furthermore, unless otherwise indicated herein, the present disclosure includes any combination of the foregoing elements in all its possible variations.

[0280] Exemplary embodiments of this disclosure may be described in accordance with the following terms.

[0281] Clause 1. A computer-implemented method is disclosed. This computer-implemented method may include preparing a user interface by a cloud computing service, the user interface being configured to receive corresponding skill metadata, the skill metadata defining multiple skills corresponding to multiple services to be bootstrapped during data center construction. The computer-implemented method may include maintaining a first skill and a second skill among the multiple skills by the cloud computing service. In some embodiments, the first skill corresponds to a first service function, and the second skill corresponds to a second service function. The first skill may indicate a dependency on the second skill. The computer-implemented method may include generating a dependency graph by the cloud computing service based at least in part on the multiple skills corresponding to the multiple services. In some embodiments, the dependency graph indicates a dependency between the first skill and the second skill. The computer-implemented method may include providing at least a portion of the dependency graph to a user device by the cloud computing service for presentation at a user interface. In some embodiments, the user interface provides navigation options associated with navigation within the dependency graph. The dependency graph may represent a build dependency graph used by an orchestrator to bootstrap multiple services during data center construction.

[0282] Clause 2. A computer-implemented method as described in Clause 1, wherein each of a plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle sub-states, each lifecycle sub-state indicating a health status corresponding to the skill.

[0283] Clause 3. The computer-implemented method as described in Clause 1 or 2 further includes verifying the build dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

[0284] Clause 4. A computer-implemented method as described in any of Clauses 1 to 3, wherein cloud computing service management may be presented at one or more user interfaces hosted by a cloud computing service.

[0285] Clause 5. A computer-implemented method as described in any of Clauses 1 to 4, wherein cloud computing service management may present a catalog of skills at one or more user interfaces hosted by a cloud computing service.

[0286] Clause 6. The computer-implemented method as described in any one of Clauses 1 to 5 further includes identifying obstacles in the construction of a data center. In some embodiments, the computer-implemented method may include identifying potential contributors to a second skill being an obstacle, based at least in part on a dependency graph generated by a cloud computing service. In some embodiments, the computer-implemented method may include instructions presented by the cloud computing service indicating potential contributors to a second skill being an obstacle.

[0287] Clause 7. The computer-implemented method as described in any one of Clauses 1 to 6 further includes monitoring by a cloud computing service for one or more indications that the status corresponding to a single skill among a plurality of skills has changed. In some embodiments, the computer-implemented method may include updating by the cloud computing service one or more attributes associated with the single skill to reflect the change in status, wherein the orchestrator initiates a bootstrapping operation associated with bootstrapping multiple services when building a data center, based at least in part on the change in status corresponding to the single skill.

[0288] Clause 8. A cloud computing service is disclosed. The cloud computing service may include one or more processors and one or more memories storing computer-executable instructions, which, when executed by the one or more processors, cause the cloud computing service of the cloud computing system to perform operations. Operations may include preparing a user interface configured to receive corresponding skill metadata, the skill metadata defining multiple skills corresponding to multiple services to be orchestrated during data center construction. Operations may include maintaining a first skill and a second skill among the multiple skills, the first skill corresponding to a first service function and the second skill corresponding to a second service function, the first skill indicating a dependency on the second skill. Operations may include generating a dependency graph, at least partially based on the multiple skills corresponding to the multiple services, the dependency graph indicating the dependency between the first skill and the second skill. Operations may include providing at least a portion of the dependency graph to a user device for presentation at a user interface, the user interface providing navigation options associated with navigation within the dependency graph, the dependency graph representing a build dependency graph used by an orchestrator to orchestrate multiple services during data center construction.

[0289] Clause 9. A cloud computing service as described in Clause 8, wherein each of a plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle sub-states, each lifecycle sub-state indicating a health status corresponding to the skill.

[0290] Clause 10. A cloud computing service as described in Clause 8 or 9, wherein the execution instructions further cause the cloud computing service to verify the dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

[0291] Clause 11. The cloud computing service as described in any of Clauses 8 to 10, wherein the cloud computing service management may be presented in one or more user interfaces hosted by the cloud computing service.

[0292] Clause 12. The cloud computing service as described in any of Clauses 8 to 11, wherein the cloud computing service manages a catalog of skills that may be presented at one or more user interfaces hosted by the cloud computing service.

[0293] Clause 13. A cloud computing service as described in any one of Clauses 8 to 12, wherein the execution instructions further cause the cloud computing service to 1) identify obstacles in building a data center; 2) identify, at least in part, a potential contributor of a second skill to an obstacle based on a dependency graph generated by the cloud computing service; and 3) present instructions that a second skill is a potential contributor of an obstacle.

[0294] Clause 14. A cloud computing service as described in any one of Clauses 8 to 13, wherein the execution instructions further cause the cloud computing service to 1) monitor one or more indications that the status corresponding to a single skill among a plurality of skills has changed; and 2) update one or more attributes associated with the single skill to reflect the change in status, wherein the orchestrator initiates a bootstrapping operation associated with bootstrapping a plurality of services when building a data center, based at least in part on the change in status corresponding to the single skill.

[0295] Clause 15. A non-transitory computer-readable medium storing computer-executable instructions is disclosed. When executed by one or more processors corresponding to a cloud computing service, the computer-executable instructions cause the cloud computing service to perform operations. In some embodiments, the operations may include preparing a user interface configured to receive corresponding skill metadata, which defines multiple skills corresponding to multiple services to be orchestrated during data center construction. In some embodiments, the operations may include maintaining a first skill and a second skill among the multiple skills, the first skill corresponding to a first service function and the second skill corresponding to a second service function, the first skill indicating a dependency on the second skill. In some embodiments, the operations may include generating a dependency graph at least partially based on the multiple skills corresponding to the multiple services, the dependency graph indicating the dependency between the first skill and the second skill. In some embodiments, the operations may include providing at least a portion of the dependency graph to a user device for presentation at a user interface, the user interface providing navigation options associated with navigation within the dependency graph, which represents a build dependency graph used by an orchestrator to orchestrate multiple services during data center construction.

[0296] Clause 16. A nontransitory computer-readable medium as described in Clause 15, wherein each of a plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle substates, each lifecycle substate indicating a health status corresponding to the skill.

[0297] Clause 17. A non-transitory computer-readable medium as described in Clause 15 or 16, wherein the execution instructions further cause the cloud computing service to verify the dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

[0298] Clause 18. A non-transitory computer-readable medium as described in any of Clauses 15 to 17, wherein the cloud computing service management may present a service catalog at one or more user interfaces hosted by the cloud computing service.

[0299] Clause 19. A non-transitory computer-readable medium as described in any of Clauses 15 to 18, wherein a skills catalog that cloud computing service management may present at one or more user interfaces hosted by a cloud computing service.

[0300] Clause 20. A nontransitory computer-readable medium as described in any one of Clauses 15 to 19, wherein executing the instructions further causes the cloud computing service to 1) identify obstacles in building a data center; 2) identify, at least in part, a potential contributor of a second skill to an obstacle based on a dependency graph generated by the cloud computing service; and 3) present instructions that a second skill is a potential contributor of an obstacle.

[0301] All references cited in this article, including publications, patent applications and patents, are incorporated into this article by reference to the same extent as if each reference individually and specifically indicated to be incorporated by reference and elaborated in full in this article.

[0302] In the foregoing specification, various aspects of this disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that this disclosure is not limited thereto. The various features and aspects of the foregoing disclosure may be used individually or in combination. Furthermore, embodiments may be used in any number of settings and applications other than those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

Claims

1. A computer-implemented method comprising: preparing, by a cloud computing service, a user interface configured to receive respective skill metadata, the skill metadata defining a plurality of skills corresponding to a plurality of services to be bootstrapped when building a data center; maintaining, by the cloud computing service, a first skill of the plurality of skills and a second skill of the plurality of skills, the first skill corresponding to a first service function and the second skill corresponding to a second service function, the first skill indicating a dependency relationship to the second skill; generating, by the cloud computing service, a dependency graph based at least in part on the plurality of skills corresponding to the plurality of services, the dependency graph indicating the dependency relationship between the first skill and the second skill; and providing, by the cloud computing service, at least a portion of the dependency graph to a user device for presentation at the user interface, the user interface providing a navigation option associated with navigation within the dependency graph, the dependency graph representing a build dependency graph used by an orchestrator to bootstrap the plurality of services when building the data center.

2. The computer-implemented method of claim 1, wherein each skill of the plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle sub-states, each lifecycle sub-state indicating a health status corresponding to a skill.

3. The computer-implemented method of claim 1 or 2, further comprising validating, by the cloud computing service, a build dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

4. The computer-implemented method of any of claims 1 to 3, wherein the cloud computing service manages a service catalog presentable at one or more user interfaces hosted by the cloud computing service.

5. The computer-implemented method of any of claims 1 to 4, wherein the cloud computing service manages a skill catalog presentable at one or more user interfaces hosted by the cloud computing service.

6. The computer-implemented method of any of claims 1 to 5, further comprising: identifying an impediment when building the data center; identifying, based at least in part on the dependency graph generated by the cloud computing service, that the second skill is a possible contributor to the impediment; presenting, by the cloud computing service, an indication that the second skill is a possible contributor to the impediment.

7. The computer-implemented method of any of claims 1 to 6, further comprising: monitoring, by the cloud computing service, one or more indications that a condition corresponding to a single skill of the plurality of skills has changed; and updating, by the cloud computing service, one or more attributes associated with the single skill to reflect the change in the condition, wherein the orchestrator initiates a bootstrap operation associated with bootstrapping the plurality of services when building the data center based at least in part on the change in the condition corresponding to the single skill.

8. A cloud computing service comprising: one or more processors; and ​ one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a cloud computing service of a cloud computing system to: prepare a user interface configured to receive respective skill metadata defining a plurality of skills corresponding to a plurality of services to be directed when building a data center; maintain a first skill of the plurality of skills and a second skill of the plurality of skills, the first skill corresponding to a first service function and the second skill corresponding to a second service function, the first skill indicating a dependency relationship to the second skill; generate a dependency graph based at least in part on the plurality of skills corresponding to the plurality of services, the dependency graph indicating the dependency relationship between the first skill and the second skill; and provide at least a portion of the dependency graph to a user device for presentation at the user interface, the user interface providing a navigation option associated with navigation within the dependency graph, the dependency graph representing a build dependency graph used by an orchestrator to direct the plurality of services when building the data center.

9. The cloud computing service of claim 8, wherein each skill of the plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle sub-states, each lifecycle sub-state indicating a health status corresponding to a skill.

10. The cloud computing service of claim 8 or 9, wherein the instructions further cause the cloud computing service to validate the dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

11. The cloud computing service of any one of claims 8 to 10, wherein the cloud computing service manages a service catalog presentable at one or more user interfaces hosted by the cloud computing service.

12. The cloud computing service of any one of claims 8 to 11, wherein the cloud computing service manages a skill catalog presentable at one or more user interfaces hosted by the cloud computing service.

13. The cloud computing service of any one of claims 8 to 12, wherein the instructions further cause the cloud computing service to: identify an impediment when building the data center; identify, based at least in part on the dependency graph generated by the cloud computing service, that the second skill is a likely contributor to the impediment; and present an indication that the second skill is the likely contributor to the impediment.

14. The cloud computing service of any one of claims 8 to 13, wherein the instructions further cause the cloud computing service to: monitor one or more indications that a condition corresponding to a single skill of the plurality of skills has changed; and update one or more attributes associated with the single skill to reflect the change in the condition, wherein the orchestrator initiates a direction operation associated with directing the plurality of services when building the data center based at least in part on the change in the condition corresponding to the single skill.

15. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors corresponding to a cloud computing service, cause the cloud computing service to: prepare a user interface configured to receive respective skill metadata defining a plurality of skills corresponding to a plurality of services to be directed when building a data center; maintain a first skill of the plurality of skills and a second skill of the plurality of skills, the first skill corresponding to a first service function and the second skill corresponding to a second service function, the first skill indicating a dependency relationship to the second skill; generate a dependency graph based at least in part on the plurality of skills corresponding to the plurality of services, the dependency graph indicating the dependency relationship between the first skill and the second skill; and provide at least a portion of the dependency graph to a user device for presentation at the user interface, the user interface providing a navigation option associated with navigation within the dependency graph, the dependency graph representing a build dependency graph used by an orchestrator to direct the plurality of services when building the data center.

16. The non-transitory computer-readable medium of claim 15, wherein each skill of the plurality of skills is associated with a lifecycle state selected from a plurality of lifecycle states, and wherein at least one lifecycle state is associated with one or more lifecycle sub-states, each lifecycle sub-state indicating a health status corresponding to a skill.

17. The non-transitory computer-readable medium of claim 15 or 16, wherein the instructions that are executed further cause the cloud computing service to validate a build dependency graph used by the orchestrator based at least in part on the dependency graph generated by the cloud computing service.

18. The non-transitory computer-readable medium of any of claims 15 to 17, wherein the cloud computing service manages a service catalog presentable at one or more user interfaces hosted by the cloud computing service.

19. The non-transitory computer-readable medium of any of claims 15 to 18, wherein the cloud computing service manages a skill catalog presentable at one or more user interfaces hosted by the cloud computing service.

20. The non-transitory computer-readable medium of any of claims 15 to 19, wherein the instructions that are executed further cause the cloud computing service to: identify an impediment when building the data center; identify, based at least in part on the dependency graph generated by the cloud computing service, that the second skill is a likely contributor to the impediment; and present an indication that the second skill is the likely contributor to the impediment.

Images