Obtaining deployment tokens for deploying workpieces to cloud environment

Abstract

Techniques for deploying a workpiece to a computing environment are disclosed. The system includes a workpiece deployment tool. The workpiece deployment tool determines that a workpiece is available for deployment to a target computing environment. The workpiece deployment tool obtains a deployment token representing verification that a set of one or more customer-specified conditions for deploying a workpiece to a target computing environment is satisfied. The workpiece deployment tool generates a deployment request for deploying a workpiece to a target computing environment. The deployment request includes a deployment token. The workpiece deployment tool directs a deployment request to a deployment service for deploying a workpiece to a target computing environment. The deployment service obtains an acknowledgement of the deployment token and deploys the workpiece to the target computing environment in response to obtaining the acknowledgement of the deployment token.

Description

[0001] Priority claims; related applications; incorporation by reference

[0002] This application claims the priority of U.S. Nonprovisional Patent Application Serial No. 18 / 647,825, filed April 26, 2024, and U.S. Provisional Patent Application Serial No. 63 / 462,875, filed April 28, 2023, which are hereby incorporated herein by reference.

[0003] U.S. Patent Application Serial No. 18 / 647,781, entitled "Consent-Driven Access Management For Cloud Resources", filed on April 26, 2024, is hereby incorporated herein by reference.

[0004] The applicant hereby withdraws any disclaimers regarding the scope of claims in one or more of the parent applications or their examination history, and informs the United States Patent and Trademark Office (USPTO) that the claims in this application may be more extensive than any of the claims in one or more of the parent applications. Technical Field

[0005] This disclosure relates to cloud computing environments. More specifically, this disclosure relates to systems and methods for deploying artifacts to cloud environments. Background Technology

[0006] Cloud computing environments can be used to provide access to a range of complementary cloud-based components, such as software applications or services, enabling organizations or enterprise customers to operate their applications and services in a highly available managed environment. The benefits of organizations moving their application and service needs to the cloud include reduced costs and complexity in designing, building, operating, and maintaining their own on-premises data centers, software application frameworks, or other IT infrastructure.

[0007] Organizations utilizing cloud environments can deploy artifacts to the cloud using various technologies. Artifacts deployed to the cloud include a variety of elements used to maintain the operation, performance, and security of the cloud environment. These artifacts include elements such as updates, upgrades, patches, configuration changes, code, applications, and other elements utilized within the cloud environment. Artifacts are deployed to the cloud environment periodically to keep its operation, performance, and security up-to-date, for example, as business needs and / or technologies change over time.

[0008] The methods described in this section are possible methods, but not necessarily methods that have been previously conceived or adopted. Therefore, unless otherwise indicated, no method described in this section should be assumed to qualify as prior art simply because it is included in this section. BRIEF DESCRIPTION OF DRAWINGS

[0009] Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which:

[0010] Figure 1 A system for providing a cloud infrastructure environment is illustrated in accordance with an embodiment.

[0011] Figure 2 Further illustrated is how a cloud-based application or service or service can be provided using a cloud infrastructure environment in accordance with an embodiment.

[0012] Figure 3 An example cloud infrastructure architecture is illustrated in accordance with an embodiment.

[0013] Figure 4 Another example of a cloud infrastructure architecture is illustrated in accordance with an embodiment.

[0014] Figure 5 Another example of a cloud infrastructure architecture is illustrated in accordance with an embodiment.

[0015] Figure 6 Another example of a cloud infrastructure architecture is illustrated in accordance with an embodiment.

[0016] Figure 7 Illustrated is how a system can provide a dedicated or private labeled cloud environment for use by tenants or customers of a cloud infrastructure environment in accordance with an embodiment.

[0017] Figure 8 Further illustrated is the use of a private labeled cloud domain for use by tenants or customers of a cloud infrastructure environment in accordance with an embodiment.

[0018] Figure 9 Further illustrated is the use of a private labeled cloud domain for use by tenants or customers of a cloud infrastructure environment in accordance with an embodiment.

[0019] Figure 10 Illustrated is a system for providing access to a software product or service in a cloud computing or other computing environment in accordance with an embodiment.

[0020] Figure 11A An example system including features for deploying artifacts to a cloud environment in accordance with one or more embodiments is illustrated;

[0021] Figure 11B An example system including features for deploying artifacts to a cloud environment in accordance with one or more embodiments is illustrated; Figure 11AFurther features of the example system of

[0022] Figure 12 illustrates an example data corpus that can be included in the system described with reference to Figure 11A and 11B FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0023] Figure 13A and 13B FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0024] Figure 14A illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0025] Figure 14B and 14C FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment. Figure 14A

[0026] Figure 15A illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0027] Figure 15B and 15C FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment. Figure 15A

[0028] Figure 16A illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0029] Figure 16B and 16C FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment. Figure 16A

[0030] Figure 17A illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment.

[0031] Figure 17B and 17C FIG. 1 illustrates an example system that includes a deployment service for deploying a workpiece to a target computing environment. Figure 17A DETAILED DESCRIPTION

[0032] ​​​​In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments can be practiced without these specific details. Features described in one embodiment can be combined with features described in a different embodiment. In some examples, well-known structures and devices are described with reference to block diagrams in order to avoid unnecessarily obscuring the present description.

[0033] 1. OVERALL SUMMARY

[0034] 2. EXAMPLE CLOUD ENVIRONMENT

[0035] 3. SYSTEM ARCHITECTURE FOR DEPLOYING ARTIFACTS TO A CLOUD ENVIRONMENT

[0036] 4. EXAMPLE OPERATION FOR DEPLOYING ARTIFACTS TO A CLOUD ENVIRONMENT

[0037] 5. EXAMPLE EMBODIMENTS

[0038] 6. OTHER MATTERS; EXTENSIONS

[0039] 1. OVERALL SUMMARY

[0040] One or more embodiments condition deployment of an artifact to a computing environment on verification that a set of one or more customer-specified conditions are satisfied. A system obtains a deployment token that represents verification that the set of customer-specified conditions for deployment of the artifact to a target computing environment are satisfied. The deployment token is presented for confirmation in connection with a deployment request to deploy the artifact to the target computing environment. If the deployment token is successfully confirmed, then the artifact can be deployed to the target computing environment. Alternatively, if there is no valid deployment token, then the artifact is not deployed to the target computing environment.

[0041] Various customers can specify different conditions for deploying artifacts to their computing environments. The conditions specified by a customer for deploying artifacts to their computing environments can depend on the particular concerns of the customer. The concerns of a customer can relate to one or more of the following: security, regulatory compliance, performance, scalability, cost management, data sovereignty, reliability, availability, resource utilization, operational performance, internal policy, or business objectives. The conditions specified by a customer for a particular customer can correspond to one or more of these concerns. Additionally or alternatively, the conditions specified by a customer can correspond to obligations specified in a service level agreement (SLA) of the customer. In one example, a customer is a private labeled cloud (PLC) operator that operates a cloud environment provided by a cloud infrastructure provider. The cloud infrastructure provider can deploy artifacts to the cloud environment, and the PLC operator or customer can specify conditions for the cloud infrastructure provider to deploy artifacts to the cloud environment. The conditions specified by the PLC operator can correspond to one or more of the above concerns, and / or to an SLA between the PLC operator and the cloud infrastructure provider. Additionally or alternatively, the conditions specified by the PLC operator can correspond to concerns associated with cloud services provided by the PLC operator to its customers via the cloud environment. In one example, the conditions specified by the PLC operator can correspond to concerns associated with an SLA between the PLC operator and one or more customers of the PLC operator.

[0042] The deployment token represents that the conditions specified by a particular customer are verified to be satisfied prior to deploying an artifact. The conditions specified by a customer can include verifying that approval to deploy the artifact has been obtained from the customer according to a customer-defined approval workflow. Additionally or alternatively, the conditions specified by a customer can include verifying that a set of one or more deployment states of a target computing environment specified by the customer are satisfied. The particular conditions specified by a customer can depend on the particular type of artifact to be deployed and / or the particular target computing environment of the artifact to be deployed.

[0043] In one example, to deploy an artifact to a target computing environment, an artifact deployment tool obtains a deployment token for the artifact, generates a deployment request, and directs the deployment request and the deployment token to a deployment service for deploying the artifact to the target computing environment. The deployment service obtains validation of the deployment token, and in response to obtaining validation of the deployment token, the deployment service deploys the artifact to the target computing environment. The deployment token can be obtained by a validation service that is a component of the artifact deployment tool. Additionally or alternatively, the artifact deployment tool can obtain the deployment token by directing a token request to a validation service that processes token requests from one or more artifact deployment tools.

[0044] In one example, a deployment service detects a request from a artifact deployment tool to deploy an artifact to a target computing environment, and in response to detecting the request, the deployment service obtains a deployment token for the artifact. The deployment service obtains validation of the deployment token, and in response to successfully obtaining validation of the deployment token, the deployment service directs the artifact to a destination address in the target computing environment. The artifact is received at the destination address and deployed in the target computing environment. The deployment token can be obtained by a validation service that is a component of the deployment service. Additionally or alternatively, the deployment service can obtain the deployment token by directing a token request to a validation service that handles token requests from one or more deployment services.

[0045] The system can include one or more validation services, e.g., to obtain deployment tokens associated with various sources of artifacts to be deployed to various target computing environments. In various embodiments, the validation service validates that a customer-specified condition is satisfied based at least in part on metadata related to an artifact to be deployed. In response to successfully validating that the customer-specified condition is satisfied, the validation service provides a deployment token representing validation that the customer-specified condition is satisfied. The deployment token can be generated by the validation service, and / or the validation service can obtain the deployment token from another service configured to generate deployment tokens, such as from an identity and access management service (IAM).

[0046] In various embodiments, the system conditions deployment of an artifact on successful validation of a deployment token corresponding to the artifact to be deployed. Additionally or alternatively, the system refrains from deploying an artifact when a deployment token is not provided and / or when a deployment token is not successfully validated. By conditioning deployment of an artifact on successful validation of a deployment token corresponding to the artifact, the system ensures that an artifact is not deployed unless a customer-specified deployment condition is satisfied. Additionally, the deployment token provides a mechanism for validating that a customer-specified condition for deploying an artifact has been satisfied prior to deploying the artifact. As such, the system accommodates different sets of conditions specified by different customers for deploying artifacts to respective computing environments corresponding to the different customers. Moreover, by allowing customers to specify conditions for deploying artifacts and utilizing deployment tokens to represent validation that the conditions are satisfied, customers can be confident that the system is satisfying the customers' particular concerns.

[0047] One or more embodiments described in this specification and / or recited in the claims can not be included in this general overview section.

[0048] 2. Example cloud environment

[0049] One or more embodiments provide features associated with cloud environments, including PLC environments. For example, customers or tenants of a cloud infrastructure provider or reseller can utilize a cloud environment to access software products, services, or other cloud offerings.

[0050] Cloud computing or cloud infrastructure environments can be used to provide access to a range of complementary cloud-based components, such as software applications or services, enabling organizations or enterprise customers to operate their applications and services in a highly available managed environment. The benefits of organizations moving their application and service needs to a cloud infrastructure environment include reduced costs and complexity in designing, building, operating, and maintaining their own on-premises data centers, software application frameworks, or other IT infrastructure. Organizations utilizing cloud environments can leverage various operational tools to monitor the operation and performance of their cloud environments.

[0051] cloud infrastructure environment

[0052] Figure 1 and Figure 2 The illustration depicts a system for providing a cloud infrastructure environment according to an embodiment.

[0053] According to an embodiment, Figure 1 The components and processes shown herein, as well as those further described herein with respect to various embodiments, may be provided as software or program code executable by a computer system or other type of processing device (e.g., a cloud computing system).

[0054] The illustrated examples are provided to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for tenants of cloud infrastructure to use when accessing subscription-based software products, services, or other provisioning items associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0055] like Figure 1 As shown, according to an embodiment, cloud infrastructure environment 100 can operate on cloud computing infrastructure 102, which includes hardware (e.g., processors, memory), software resources, and one or more cloud interfaces 104 or other application programming interfaces (APIs) that provide access to shared cloud resources via one or more load balancers A 106, B 108. Cloud interface 102 includes user interfaces and APIs provided by cloud service providers for interacting with their cloud services. This includes tools and platforms that allow users and administrators to manage, configure, and monitor cloud resources and services. Cloud interface 102 may include a console, such as a web-based user interface, that provides a visual way to interact with and manage cloud resources. Through the console, users can, for example, create, configure, and monitor cloud services such as compute instances, databases, storage devices, and networking components. Cloud interface 102 may also include a command-line interface for users who prefer to operate the cloud infrastructure using command-line tools. In this embodiment, the CLI allows for scripting and automating cloud management tasks.

[0056] According to an embodiment, load balancer A 106 and load balancer B 108 are services that distribute incoming network traffic to a number of servers, instances, or other resources to ensure that no single resource is overwhelmed by demand. By distributing requests evenly across resources, load balancers enhance the responsiveness and availability of resources such as applications, websites, or databases. Load balancer A 106 and load balancer B 108 can be public load balancers, accessible from the internet and used to distribute external traffic, or private load balancers, used within a virtual cloud network (VCN) and not accessible from the public internet (and thus well suited for internal traffic distribution). In embodiments, load balancer A 106 and load balancer B 108 are designed for high availability and fault tolerance, and are implemented in a redundant configuration across multiple availability domains or fault domains.

[0057] According to an embodiment, the cloud infrastructure environment supports the use of availability domains (such as availability domain A 180 and availability domain B 182) that enable customers to create and access cloud networks 184, 186, and run cloud instances A 192, B 194. In an embodiment, availability domain A 180 and availability domain B 182 can represent a data center, or a group of data centers located within a region. These availability domains can be isolated from each other, meaning they can not share the same physical infrastructure, such as power or cooling systems. This design provides a high degree of fault independence and robustness. In an embodiment, fault domains can provide additional protection and resiliency within a single availability domain by grouping hardware and infrastructure into availability domains that are isolated from other fault domains. This isolation can involve power, cooling, and other potential sources of failure.

[0058] According to an embodiment, each cloud tenant / customer (e.g., tenants A 142 and B 144) can be created with a tenancy (a container of resources used by the tenant) that provides a secure and isolated partition within the cloud infrastructure environment in which the customer can create, organize, and manage their cloud resources. The cloud tenant / customer can access availability domains and cloud networks to access their cloud instances. The tenancy is isolated from other tenancies, ensuring that each customer’s data and resources are secure and inaccessible to other customers. Within the tenancy, the customer can create, manage, and organize various cloud resources, including compute instances, storage volumes, and networks. An identity and access management (IAM) service enables management of users, groups, and policies within the tenancy. Through the IAM, the customer can control who has access to their resources and what actions they can perform. The tenancy is also the level at which billing and subscription management are handled. Usage and costs associated with resources within the tenancy are tracked and billed uniformly under that tenancy. Each tenancy can be associated with specific service limits and quotas for various resources. These limits can be used to help manage capacity and facilitate resource allocation between each tenant.

[0059] According to embodiments, a computing device, such as a client device 120 having device hardware 122 (e.g., processor, memory) and a graphical user interface 126, can enable an administrator or other user to communicate with a cloud infrastructure environment via a network, such as a wide area network, local area network, or the Internet, to create or update a cloud service.

[0060] According to embodiments, the cloud infrastructure environment provides access to shared cloud resources 140 via, for example, a computing resource layer 150, a network resource layer 160, and / or a storage resource layer 170. A customer can launch cloud instances on demand to meet computing and application needs. After a customer provisions and launches a cloud instance, the provisioned cloud instance can be accessed from a client device, such as client device 120.

[0061] According to embodiments, computing resources 150 can include resources such as bare metal cloud instances 152, virtual machines 154, graphics processing unit (GPU) compute cloud instances 156, and / or containers 158. A bare metal instance represents a physical server with dedicated hardware that is fully allocated to a single tenant. Bare metal instances provide direct access to a server's processors, memory, storage, and other hardware resources. A virtual machine (VM) is a software emulation of a physical computer that runs an operating system and applications like a physical computer. VMs allow multiple operating systems to run on a single physical machine or across multiple physical machines. A hypervisor layer sits between the hardware and the virtual machines, allocating physical resources (like CPUs, memory, and storage) to each VM. In embodiments, GPU compute cloud instances provide GPUs in addition to traditional CPU resources. These instances are designed for tasks that require a large amount of parallel processing power, making them ideal for applications like machine learning, scientific computing, 3D rendering, and video processing. In embodiments, containers 158 use a virtualization approach that allows multiple isolated applications to run on a single control host, virtualizing the operating system. Each container shares the host system's kernel but runs in an isolated user space, making containers lightweight and efficient.

[0062] Components of computing resources 150 can be used to provision and manage bare metal compute cloud instances, or provision cloud instances on demand to deploy and run applications just as in an on-premises data center. For example, according to embodiments, a cloud infrastructure environment can provide control over physical host (bare metal) machines within the computing resource layer that run as compute cloud instances directly on bare metal servers without a hypervisor.

[0063] According to embodiments, the cloud infrastructure environment can also provide control of virtual machines within the compute resource layer, which can be launched from, for example, images, where the type and number of resources available to a virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine is launched.

[0064] According to embodiments, the network resource layer can include several network-related resources, such as virtual cloud networks (VCNs) 162, load balancers 164, edge services 166, and / or connection services 168. In embodiments, a virtual cloud network (VCN) is a customizable and private network within a cloud environment. A VCN provides a virtual version of a traditional network, including subnets, route tables, and gateways. It allows users to set up a cloud-based network architecture according to their requirements. In embodiments, edge services 166 include services and technologies designed to bring compute, data storage, and networking capabilities closer to where they are needed. Edge services 166 can be used to optimize traffic, reduce latency, or provide other advantages.

[0065] According to embodiments, the storage resource layer can include several resources, such as data / block volumes 172, file storage 174, object storage 176, and / or local storage 178. Data / block volumes 172 provide unformatted block-level storage, which can be used to create file systems that host databases or for other uses that require unformatted storage. File storage 174 provides file systems in embodiments, and can provision shared file systems that multiple instances can access simultaneously using standard file storage protocols. Object storage 176 manages data as objects within buckets. Objects have certain attributes, which can include data, metadata, and a unique identifier. Local storage 178 refers to storage devices that are physically attached to a host computer.

[0066] As Figure 2 As shown in FIG. 1C, according to embodiments, the cloud infrastructure environment can include a series of complementary cloud-based components, such as cloud infrastructure applications and services 200, which enable an organization or enterprise customer to operate their applications and services in a highly available managed environment.

[0067] According to embodiments, a self-contained cloud region can be provided as a complete Oracle Cloud Infrastructure (OCI) dedicated region within, for example, an organization’s data center, which supplies the flexibility, scalability, and economics of, for example, the OCI public cloud to data center operators, while retaining full control over their data and applications to meet security, regulatory, or data residency requirements.

[0068] For example, such an environment can include racks physically and logically managed by a cloud infrastructure provider (e.g., Oracle), customer’s racks, access rights to setup and hardware support by cloud operators, customer’s data center power and cooling, customer’s floor space, customer data center personnel’s location, and physical access cages, according to an embodiment.

[0069] According to an embodiment, the dedicated region provisions the same set of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) products or services, such as ERP, Financials, HCM, and SCM, to the tenant / customer as available in the public cloud region of the cloud infrastructure provider (e.g., Oracle). The customer can seamlessly lift and shift legacy workloads using the cloud infrastructure provider’s services (e.g., bare metal compute, VMs, and GPUs), database services (e.g., Oracle Autonomous Database), or container-based services (e.g., Oracle Kubernetes Container Engine).

[0070] According to an embodiment, the cloud infrastructure environment can operate according to an Infrastructure as a Service (IaaS) model that enables the environment to provide virtualized computing resources over a public network, such as the Internet.

[0071] In an IaaS model, a cloud infrastructure provider 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, the cloud infrastructure provider can also provision various services to work with these infrastructure components; example services include billing software, monitoring software, logging software, load balancing software, or clustering software. Thus, because these services can be policy driven, an IaaS user can be able to implement policies to drive load balancing, thereby maintaining availability and performance of applications.

[0072] According to an embodiment, an IaaS customer can access resources and services over a wide area network (WAN), such as the Internet, and can use the cloud infrastructure provider’s services to install the remaining elements of an application stack. For example, a user can log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and install enterprise software into that VM. The customer can then use the provider’s services to perform various functions, including balancing network traffic, troubleshooting applications, monitoring performance, or managing disaster recovery.

[0073] According to an embodiment, a cloud infrastructure provider can, but does not necessarily, be a third-party service that specializes in providing (e.g., provisioning, renting, selling) IaaS. An entity can also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

[0074] According to an embodiment, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It can also include the process of preparing a server (e.g., installing libraries or daemons). This is typically managed by the cloud infrastructure provider, below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer can be responsible for handling (OS), middleware, and / or application deployment (e.g., onto a self-service virtual machine, which can be launched on-demand, etc.).

[0075] According to an embodiment, IaaS provisioning can refer to acquiring computers or virtual hosts for use and installing the required libraries or services on them. In most cases, deployment does not include provisioning, and provisioning can need to be performed first.

[0076] According to an embodiment, challenges of IaaS provisioning include the initial challenge of provisioning a set of initial infrastructure before anything is running. Secondly, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, or removing services). In some cases, both challenges can be addressed by enabling a configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on other resources, and how they each work together) can be described in a declarative manner. In some cases, once the topology is defined, a workflow that creates and / or manages the different components described in the configuration file can be generated.

[0077] According to an embodiment, a cloud infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, one or more ingress / egress traffic group rules can also be provisioned to define how the network will be set up for one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., can also be provisioned. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve step-by-step.

[0078] According to embodiments, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. Moreover, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more, but typically many, different production environments (e.g., across various geographic locations). However, in some examples, the infrastructure to deploy the code needs to be provisioned. In some cases, provisioning can be done manually, resources can be provisioned with provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed with deployment tools.

[0079] Figure 3 FIGURE 1 illustrates an example cloud infrastructure architecture, according to an embodiment.

[0080] As Figure 3 As shown in the middle, according to embodiments, the service operator 202 can be communicatively coupled to a secure host tenancy 204 that can include a virtual cloud network (VCN) 206 and a secure host subnet 208.

[0081] In some examples, the service operator can use one or more client computing devices, which can be portable handheld devices (e.g., phones, tablet computers, personal digital assistants (PDAs)) or wearable devices (e.g., head-mounted displays), running software such as Microsoft Windows® and / or various mobile operating systems (such as iOS, Android, etc.) and capable of supporting Internet, e-mail, Short Message Service (SMS), or other communications protocols. Alternatively, the client computing devices can be general purpose personal computers including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. The client computing devices can be workstation computers running any of a variety of commercially-available UNIX® or UNIX-like operating systems, including, without limitation, the variety of GNU / Linux operating systems, such as Google Chrome OS. Alternatively, or additionally, client computing devices can be any other electronic device, such as a thin-client computer, an Internet-enabled game system (e.g., a Microsoft Xbox game console), and / or a personal messaging device, capable of communicating over a network.

[0082] According to embodiments, the VCN can include a local peering gateway (LPG) 210 that can be communicatively coupled to a secure shell (SSH) VCN 212 via an LPG contained in the SSH VCN. The SSH VCN can include an SSH subnet 214, and the SSH VCN can be communicatively coupled to a control plane VCN 216 via an LPG contained in the control plane VCN. Further, the SSH VCN can be communicatively coupled to a data plane VCN 218 via an LPG. The control plane VCN and the data plane VCN can be contained in a service tenancy 219 that can be owned and / or operated by a cloud infrastructure provider.

[0083] According to embodiments, the control plane VCN can include a control plane demilitarized zone (DMZ) tier 220 that acts as a perimeter network (e.g., a portion of an enterprise network between an enterprise intranet and an external network). DMZ-based servers can have limited responsibilities to help contain potential vulnerabilities. Further, the DMZ tier can include one or more load balancer (LB) subnets 222, a control plane application tier 224 that can include an application subnet 226, and a control plane data tier 228 that can include a database (DB) subnet 230 (e.g., a front-end DB subnet(s) and / or a back-end DB subnet(s)). The LB subnet(s) contained in the control plane DMZ tier can be communicatively coupled to the application subnet(s) contained in the control plane application tier and to an internet gateway 234 that can be contained in the control plane VCN. The application subnet(s) can be communicatively coupled to the DB subnet(s) contained in the control plane data tier, a service gateway 236, and a network address translation (NAT) gateway 238. The control plane VCN can include the service gateway and the NAT gateway.

[0084] According to embodiments, the control plane VCN can include a data plane mirror application tier 240 that can include application subnet(s). The application subnet(s) contained in the data plane mirror application tier can include virtual network interface controllers (VNICs) that can execute compute instances. The compute instances can communicatively couple the application subnet(s) of the data plane mirror application tier to application subnet(s) that can be contained in a data plane application tier.

[0085] According to an embodiment, the data plane VCN can include a data plane app tier, a data plane DMZ tier, and a data plane data tier. The data plane DMZ tier can include LB subnet(s) that can be communicatively coupled to app subnet(s) of the data plane app tier and an internet gateway of the data plane VCN. The app subnet(s) can be communicatively coupled to a service gateway of the data plane VCN and a NAT gateway of the data plane VCN. The data plane data tier can also include DB subnet(s) that can be communicatively coupled to the app subnet(s) of the data plane app tier.

[0086] According to an embodiment, the internet gateway of the control plane VCN and the data plane VCN can be communicatively coupled to a metadata management service 252 that can be communicatively coupled to a public internet 254. The public internet can be communicatively coupled to the NAT gateway of the control plane VCN and the data plane VCN. The service gateway of the control plane VCN and the data plane VCN can be communicatively coupled to cloud services 256.

[0087] According to an embodiment, the service gateway of the control plane VCN or the data plane VCN can make application programming interface (API) calls to cloud services without going through the public internet. The API calls from the service gateway to the cloud services can be one-way; the service gateway can make API calls to the cloud services and the cloud services can send requested data to the service gateway. Generally, the cloud services can not initiate API calls to the service gateway.

[0088] According to an embodiment, a secure host tenancy can be directly connected to a service tenancy that can otherwise be isolated. The secure host subnet can communicate with the SSH subnet through an LPG that can enable two-way communication on otherwise isolated systems. Connecting the secure host subnet to the SSH subnet can enable the secure host subnet to access other entities within the service tenancy.

[0089] According to an embodiment, the control plane VCN can allow users of the service tenancy to stand up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN can be deployed or otherwise used in the data plane VCN. In some examples, the control plane VCN can be isolated from the data plane VCN, and a data plane mirror app tier of the control plane VCN can communicate with a data plane app tier of the data plane VCN via a VNIC that can be contained in the data plane mirror app tier and the data plane app tier.

[0090] According to embodiments, a user or customer of the system can make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet that can communicate the request to the metadata management service. The metadata management service can communicate the request to the control plane VCN through the internet gateway. The request can be received by the LB subnet(s) contained in the control plane DMZ tier. The LB subnet(s) can determine that the request is valid, and in response to the determination, the LB subnet(s) can transmit the request to the application subnet(s) contained in the control plane application tier. If the request is confirmed and requires a call to the public internet, the call to the internet can be transmitted to the NAT gateway that can make the call to the internet. Metadata to be stored by the request can be stored in the DB subnet(s).

[0091] According to embodiments, the data plane mirror application tier can facilitate direct communication between the control plane VCN and the data plane VCN. For example, it can be desirable to apply changes, updates, or other appropriate modifications to configuration to resources contained in the data plane VCN. With the aid of the VNICs, the control plane VCN can directly communicate with the resources contained in the data plane VCN and, as a result, can perform the changes, updates, or other appropriate modifications to configuration.

[0092] According to embodiments, the control plane VCN and the data plane VCN can be contained in a service tenancy. In this case, a user or customer of the system can not own or operate the control plane VCN or the data plane VCN. Instead, the cloud infrastructure provider can own or operate the control plane VCN and the data plane VCN, both of which can be contained in a service tenancy. This embodiment can enable isolation of the network, which can prevent a user or customer from interacting with resources of other users or other customers. Moreover, this embodiment can allow a user or customer of the system to privately store databases without having to rely on the public internet for storage, which can not provide a desired level of threat protection.

[0093] According to embodiments, the LB subnet(s) contained in the control plane VCN can be configured to receive signals from the service gateway. In this embodiment, the control plane VCN and the data plane VCN can be configured to be invoked by a customer of the cloud infrastructure provider without invoking the public internet. This embodiment can be desirable by a customer of the cloud infrastructure provider because the database(s) used by the customer can be controlled by the cloud infrastructure provider and can be stored on a service tenancy that can be isolated from the public internet.

[0094] Figure 4 FIGURE 1 illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0095] As Figure 4 shown in

[0096] According to embodiments, a customer of a cloud infrastructure provider can have databases managed and operated within a customer tenancy. In this example, a control plane VCN can include a data plane mirror application tier, which can include application subnet(s). The data plane mirror application tier can reside in the data plane VCN, but the data plane mirror application tier can not be provisioned in the data plane VCN. That is, the data plane mirror application tier can have access to the customer tenancy, but the data plane mirror application tier can not exist in the data plane VCN, or be owned or operated by the customer. The data plane mirror application tier can be configured to make calls to the data plane VCN, but the data plane mirror application tier cannot be configured to make calls to any entity contained in the control plane VCN. The customer can desire to deploy or otherwise use resources provisioned in the control plane VCN in the data plane VCN, and the data plane mirror application tier can facilitate the customer's desired deployment or other use of the resources.

[0097] According to embodiments, a customer of a cloud infrastructure provider can apply filters to a data plane VCN. In this embodiment, the customer can determine what the data plane VCN can access, and can limit access from the data plane VCN to the public Internet. The cloud infrastructure provider can not be able to apply filters or otherwise control access by the data plane VCN to any external network or database. The customer's application of filters and controls to the data plane VCN contained in the customer tenancy can help isolate the data plane VCN from other customers and the public Internet.

[0098] According to embodiments, cloud services can be invoked by a service gateway to access services that may not exist on the public internet, the control plane VCN, or the data plane VCN. The connection between the cloud service and the control plane VCN or data plane VCN may not be contiguous. Cloud services can reside on different networks owned or operated by a cloud infrastructure provider. Cloud services can be configured to accept calls from the service gateway and can be configured not to accept calls from the public internet. Some cloud services may be isolated from other cloud services, and the control plane VCN may be isolated from cloud services that may not be in the same region as the control plane VCN.

[0099] For example, according to an embodiment, the control plane VCN may be located in "Region 1", and the cloud service "Deployment 1" may be located in both Region 1 and "Region 2". If a service gateway contained in the control plane VCN located in Region 1 makes a call to Deployment 1, then the call can be transmitted to Deployment 1 in Region 1. In this example, the control plane VCN or Deployment 1 in Region 1 may not be communicatively coupled to or otherwise communicate with Deployment 1 in Region 2.

[0100] Figure 5 The illustration shows another example of a cloud infrastructure architecture according to an embodiment.

[0101] like Figure 5 As shown, according to an embodiment, a trusted application subnet 260 can be communicatively coupled to a service gateway contained in a data plane VCN, a NAT gateway contained in a data plane VCN, and one or more DB subnets contained in a data plane data layer. An untrusted application subnet 264 can be communicatively coupled to a service gateway contained in a data plane VCN and one or more DB subnets contained in a data plane data layer. The data plane data layer may include one or more DB subnets that can be communicatively coupled to a service gateway contained in a data plane VCN.

[0102] According to an embodiment, one or more untrusted application subnets may include one or more primary VNICs (1)-(N) communicatively coupled to tenant virtual machines (VMs). Each tenant VM may be communicatively coupled to a corresponding application subnet 267 (1)-(N) that may be contained in a corresponding container egress VCN 268 (1)-(N), which may be contained in a corresponding customer lease 270 (1)-(N). A corresponding secondary VNIC may facilitate communication between the one or more untrusted application subnets contained in the data plane VCN and the application subnets contained in the container egress VCN. Each container egress VCN may include a NAT gateway communicatively coupled to the public internet.

[0103] According to an embodiment, the public Internet can be communicatively coupled to the NAT gateway contained in the control plane VCN and contained in the data plane VCN. The service gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to the cloud services.

[0104] According to an embodiment, the data plane VCN can be integrated with customer tenancies. This integration can be useful or desirable for customers of the cloud infrastructure provider in situations where additional support can be needed when executing code. For example, a customer can provide code to be run that can be potentially destructive, can communicate with other customer resources, or can otherwise cause undesirable effects.

[0105] According to an embodiment, a customer of the cloud infrastructure provider can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application tier. Code to run the functionality can be executed in a VM, and the code can not be configured to run anywhere else on the data plane VCN. Each VM can be connected to one customer tenancy. Respective containers (1)-(N) contained in the VM can be configured to run the code. In this case, there can be double isolation (e.g., the containers run code, where the containers can be contained in the VM contained in the untrusted application subnet(s)), which can help prevent incorrect or otherwise undesirable code from damaging the network of the cloud infrastructure provider or damaging the network of a different customer. The containers can be communicatively coupled to the customer tenancy and can be configured to transmit or receive data from the customer tenancy. The containers can be configured to not transmit or receive data from any other entity in the data plane VCN. Upon completion of running the code, the cloud infrastructure provider can dispose of the containers.

[0106] According to an embodiment, the trusted application subnet(s) can run code that can be owned or operated by the cloud infrastructure provider. In this embodiment, the trusted application subnet(s) can be communicatively coupled to the DB subnet(s) and configured to perform CRUD operations in the DB subnet(s). The untrusted application subnet(s) can be communicatively coupled to the DB subnet(s) and configured to perform read operations in the DB subnet(s). Containers that can be contained in a VM of each customer and that can run code from the customer can not be communicatively coupled to the DB subnet(s).

[0107] According to embodiments, the control plane VCN and the data plane VCN can not be directly communicatively coupled, or there can be no direct communication between the control plane VCN and the data plane VCN. However, communication can occur indirectly, where the cloud infrastructure provider can establish an LPG, which can facilitate communication between the control plane VCN and the data plane VCN. In another example, the control plane VCN or the data plane VCN can make calls to cloud services via a service gateway. For example, a call to a cloud service from the control plane VCN can include a request to a service that can communicate with the data plane VCN.

[0108] Figure 6 FIGURE 1 illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0109] As Figure 6 According to embodiments, as shown in FIGURE 1, the trusted application subnet(s) can be communicatively coupled to a service gateway contained in the data plane VCN, a NAT gateway contained in the data plane VCN, and the DB subnet(s) contained in the data plane data tier. The untrusted application subnet(s) can be communicatively coupled to the service gateway contained in the data plane VCN and the DB subnet(s) contained in the data plane data tier. The data plane data tier can include the DB subnet(s) that can be communicatively coupled to the service gateway contained in the data plane VCN.

[0110] According to embodiments, the untrusted application subnet(s) can include a primary VNIC that can be communicatively coupled to a tenant virtual machine (VM) that resides within the untrusted application subnet(s). Each tenant VM can run code in a respective container and can be communicatively coupled to an application subnet that can be contained in the data plane application tier, which can be contained in the container egress VCN 280. Respective secondary VNICs 282(1)- (N) can facilitate communication between the untrusted application subnet(s) contained in the data plane VCN and the application subnet contained in the container egress VCN. The container egress VCN can include a NAT gateway that can be communicatively coupled to the public Internet.

[0111] According to embodiments, the internet gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to a metadata management service that can be communicatively coupled to the public Internet. The public Internet can be communicatively coupled to the NAT gateway contained in the control plane VCN and contained in the data plane VCN. The service gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to cloud services.

[0112] According to embodiments,Figure 6 The pattern illustrated in FIG. 6 can be considered an exception to the pattern illustrated in FIG. 5, and can be desirable to customers if the cloud infrastructure provider cannot directly communicate with the customer (e.g., a disconnected region). The customer can access in real-time the respective containers contained in each customer’s VM. The containers can be configured to make calls to respective secondary VNICs contained in the application(s) subnet of the data plane application tier, which can be contained in the container egress VCN. The secondary VNICs can transmit the calls to the NAT gateway, which can transmit the calls to the public internet. In this example, the containers that the customer can access in real-time can be isolated from the control plane VCN, and can be isolated from other entities contained in the data plane VCN. The containers can also be isolated from resources from other customers. Figure 5 In other examples, a customer can use a container to call a cloud service. In this example, the customer can run code in the container that requests a service from the cloud service. The container can transmit the request to a secondary VNIC, which can transmit the request to a NAT gateway, which can transmit the request to the public internet. The public internet can be used to transmit the request to the LB(s) subnet contained in the control plane VCN via the internet gateway. Responsive to determining that the request is valid, the LB(s) subnet can transmit the request to the application(s) subnet, which can transmit the request to the cloud service via the service gateway.

[0113]

[0114] It should be appreciated that the IaaS architecture depicted in the above figures can have other components in addition to those depicted. Additionally, the embodiments illustrated in the figures are merely some examples of cloud infrastructure systems with which embodiments of the present disclosure can be practiced. In some other embodiments, an IaaS system can have more or fewer components than shown in the figures, can combine two or more components, or can have a different configuration or arrangement of components.

[0115] In certain embodiments, the IaaS systems described herein can include a suite of application, middleware and database

[0116] Private labeled cloud environments

[0117] According to embodiments, the cloud infrastructure environment can be used to provide a private cloud environment, e.g., as one or more private labeled cloud environments, for use by tenants of the cloud infrastructure environment in accessing subscription-based software products, services or other offerings associated with the cloud infrastructure environment. ​

[0118] Figure 7 FIGURE illustrates how the system can provide a private or private label cloud environment for use by tenants or customers of the cloud infrastructure environment, according to an embodiment.

[0119] As Figure 7 illustrated in FIGURE, according to an embodiment, a cloud infrastructure provider (e.g., OCI) can provision one or more private label cloud (PLC) environments to a PLC operator 320 (e.g., an OCI customer operating as a reseller). The PLC operator / reseller can then customize and extend the private label cloud for use by its customers 330 in accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0120] For purposes of illustration, examples of such subscription-based products, services, or other offerings can include various Oracle cloud infrastructure software products, Oracle Fusion Applications products, or other types of products or services that allow customers to subscribe to use these products or services.

[0121] Figure 8 Further illustrates the use of the private label cloud domain by tenants or customers of the cloud infrastructure environment, according to an embodiment.

[0122] As Figure 8 illustrated in FIGURE, according to an embodiment, the system can include a cloud subscription service or component, such as the Oracle Cloud Subscription (OCS) service or component, that exposes one or more subscription management APIs for creating orders to onboard new customers or to initiate the creation of subscriptions and orchestration of billing and pricing services or other components for the PLC domain 400.

[0123] According to an embodiment, when a PLC operator or its customers request a PLC environment, the system creates a PLC domain for use by one or more provider-owned tenancies. A domain is a logical collection of one or more cloud regions that are isolated from each other and do not allow customer content to cross the domain boundary to regions outside the domain. Each domain is accessed separately. The PLC operator accesses cloud resources and services through a cloud tenancy. A cloud tenancy is a secure and isolated partition of the cloud infrastructure environment, and it exists only in a single domain. Within that tenancy, the operator can access services and deploy workloads in all regions within the domain if policy allows.

[0124] According to embodiments, the first step of the process is to create an operator tenancy for the PLC operator, and then hand over the domain and associated regions to the PLC operator for subsequent management. The PLC operator then becomes the administrator of that tenancy, able to see and manage all that happens within that domain, including its customer accounts and the usage of cloud resources by those customers.

[0125] In general, once a domain is handed over or provisioned to a PLC operator, the cloud infrastructure provider cannot subsequently access data within the operator tenancy, unless the operator authorizes the cloud infrastructure provider to do so, for example to provide troubleshooting for issues that can arise.

[0126] According to embodiments, the PLC operator can then create additional internal tenancies, intended for its own internal use, such as for evaluating end customer experiences, providing sales demo tenancies, or operating databases for its own internal use. The operator can also create one or more customer tenancies, for which end customers will be the administrators. Cloud infrastructure usage metrics (e.g., compute usage, storage usage, and usage of other infrastructure resources) can be consolidated by the operator, reflecting usage by both the operator and the customers. Cloud infrastructure usage can be reported to the cloud infrastructure provider.

[0127] According to embodiments, a user interface or console can be provided that allows the PLC operator to manage its customer accounts and customer provisioned services. The cloud infrastructure provider can also use the cloud infrastructure tenancy (e.g., a converged application tenancy) to install any required infrastructure services for use by the operator and its customers.

[0128] Figure 9 Further illustrated is the use of a private labeled cloud domain by a tenant or customer of a cloud infrastructure environment, according to embodiments.

[0129] As Figure 9 As shown in FIG. 7, according to embodiments, a cloud subscription service or component exposes one or more subscription management APIs for creating orders to onboard new customers or to initiate workflows that create subscriptions and orchestrate billing and pricing services or other components.

[0130] According to embodiments, the system can also include a billing service or component that operates on a logical container of billing accounts or subscriptions and preferences for generating invoices for customers.

[0131] According to embodiments, the system can also include a subscription pricing service (SPS) or component that operates on a product catalog that defines the products that customers can purchase. The subscription pricing service can also be used to provide a price list (e.g., rate card) that the pricing service also owns.

[0132] According to embodiments, to support the sales process for creating a subscription in a PLC domain, a product can be selected from a product hub. Once an order is created, a subscription is created in a cloud subscription service, which thereafter manages the life cycle of the subscription and provisions what is needed to provision in downstream services. An SPS component then manages the pricing and usage aspects for the ability to charge the PLC operator for the final fees or for the operator to charge its customers. Usage events are forwarded to a billing service or component, where depending on the billing preferences of the subscription, an invoice is created and pushed to an accounts receivable component.

[0133] According to embodiments, while the services provisioned in a domain report their usage to a metering service or component, such usage does not have any price associated with it. A billing process determines, for example by applying a rate card, what the cost of each particular event is, determines the units and cost for that subscription, associates the cost with that record, and then forwards it to a billing service or component.

[0134] As Figure 9 Further shown, according to embodiments, a PLC operator can control multiple domains A and B. For example, an operator that operates in multiple countries can want to operate a data center completely isolated from the United States, and a separate data center completely isolated from Europe, for example to meet governance or regulatory requirements. According to embodiments, usage associated with these multiple domains can be aggregated for billing to the operator.

[0135] The examples of the various systems shown above are intended to illustrate a computing environment that can be used to provide a dedicated or private label cloud environment for tenants of a cloud infrastructure to use when accessing subscription-based software products, services, or other offerings associated with a cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0136] Private label cloud subscriptions

[0137] Figure 10 A system for providing access to software products or services in a cloud computing or other computing environment is illustrated, according to embodiments.

[0138] As Figure 10 As shown in the diagram in FIG. 1, according to embodiments, the system can be provided as a cloud computing or other computing environment, referred to herein in some embodiments as a platform, that supports the use of subscription-based products, services, or other offerings.

[0139] Examples of such subscription-based products, services, or other offerings can include various Oracle Cloud Infrastructure (OCI) software products, Oracle Fusion Applications products, or other types of products or services that allow customers to subscribe to the use of these products or services.

[0140] According to embodiments, a subscription can include artifacts such as products, commitments, billing models, and states. A cloud subscription service can expose one or more subscription management APIs for creating orders for onboarding new customers or for initiating workflows that create subscriptions and orchestrate the creation of appropriate footprints in billing and pricing services or components, as described further below.

[0141] According to embodiments, a billing service or component operates on logical containers of billing accounts or subscriptions and preferences for generating invoices. Each billing account generates one or more invoices per billing period. The billing service includes a first pipeline that accepts usage and costs from a metering service or component. Usage can be accepted through a REST API or other interface. The billing service writes usage to a database from which a billing service or other service can compute and aggregate balances. The billing service can include a second pipeline that is responsible for taking aggregated usage and commitments and computing charges for one or more billing intervals.

[0142] According to embodiments, a subscription pricing service (SPS) or component operates on a product catalog that defines products that customers can purchase. The product catalog forms the backbone of a price list (i.e., rate card) that the pricing service also possesses. Rate cards are modeled as pricing rules over published price lists. The pricing service maintains a single price list for each product; new product prices can be added, and existing prices can be changed. Price lists have a complete history, with the latest version being the current rate card. Since some contracts can require that snapshots of rate cards be taken, the pricing service handles this by recording the time at which a customer’s rate card was created and then querying the price list for that time.

[0143] According to embodiments, the SPS or pricing service is responsible for providing information about products, global price lists, and price lists and discounts specific to end-customer subscriptions. For example, according to embodiments, the SPS can synchronize product information from a product hub (e.g., Oracle Fusion Product Hub) and global price lists from a pricing hub (e.g., Oracle Fusion Pricing Hub).

[0144] According to embodiments, the cloud subscription service operates as an upstream service to receive, for example, new order requests from an Oracle Fusion Order Management environment. The cloud subscription service can provide subscription information to the SPS service. Subscription details such as the time of the quote, configuration, and subscription type (commitment, PayG) help the SPS determine the effective base price (rate card) for the subscription. The cloud subscription service can also send subscription discounts received, for example, from Oracle Fusion Order Management, which the SPS stores as pricing rules entities.

[0145] According to embodiments, the SPS service runs as a background process to manage a rate card service or component responsible for generating new rate cards for subscriptions and updating them when new changes in prices occur. The SPS service can expose APIs to access rate cards and pricing rules. The metering in-line charging engine can utilize these APIs to fetch subscription-specific rate cards and pricing rules, using this data for cost calculations.

[0146] According to embodiments, additional SPS components can include, for example, a pricing / product hub Oracle Integration Cloud (OIC) integration component that allows the PLC operator entity to provision subscription-based products, services, or other offerings within the environment to manage its product and price lists, for example, provided by Oracle Fusion Product Hub and Oracle Fusion Pricing Hub, respectively.

[0147] For example, according to such embodiments, the SPS OIC product integration flow can listen to create / update events in the product hub and make calls to the SPS product APIs. Similarly, the SPS OIC pricing integration flow can extract new price list creations from the pricing hub and call the corresponding SPS pricing APIs.

[0148] According to embodiments, the system can also include an SPS core module that provides APIs for managing and accessing pricing entities. Pricing can be accessed through internal services, such as the in-line charging engine.

[0149] According to embodiments, the system can also contain a rate card manager component. The SPS service maintains the single base price of a product at a given time. However, the product price of a subscription depends on the base price at the time of offer configuration and the price list change policy attributes of the subscription. The SPS service uses these properties to maintain internally the prices to be used for a subscription. These price lists are grouped in rate cards. The rate card manager can create and maintain rate cards, as well as listen to price list changes and update existing rate cards with new prices. It also listens to new subscriptions and assigns rate cards based on the subscription properties.

[0150] According to embodiments, the system can also include a rule decoder engine. The SPS service is responsible for managing the pricing rules of a subscription, including discounts offered to the end customer. Pricing rule applicability can be based on attributes of the product, such as discount groups, product categories, or specific SKUs. Internally, the SPS needs to identify the list of products for which these rules will apply. To achieve this, the rule decoder engine can compile the pricing rules into a format that makes it possible for the in-line charging engine to use it for cost calculations. This compilation process can be triggered when a product or pricing rule is created / updated.

[0151] As outlined above, the SPS service can be responsible for managing the pricing of a subscription, including the base price of the product and the discounts offered to the end customer. The SPS service can be responsible for managing the pricing of a subscription, including the base price of the product and the discounts offered to the end customer. Figure 10According to embodiments: At 441, product and price information managed, for example, in a converged application is sent to the SPS component. At 442, an order is sent to the cloud subscription service component to create a subscription, rate card, and billing account. At 443, pricing configuration and pricing rules for the new order are sent to the SPS. At 444, the cloud subscription service is used to stand up a billing account in a billing service or component. At 445, the cloud subscription service publishes events to a cloud infrastructure streaming component. At 446, expense data is sent to an accounts receivable component to generate an invoice. At 447, the cloud subscription service uses reclaim and subscription lifecycle (RASL) events from cloud infrastructure streaming. At 448, an activation service reads the cloud subscription service event stream. At 449, a customer gets activation data from a portal. At 450, a tenancy lifecycle service provisions a tenancy as part of subscription activation. At 451, the tenancy lifecycle service creates an account footprint during account provisioning. At 452, the tenancy lifecycle service sets up limit templates during account provisioning. At 453, an account component acts as a downstream RASL client to handle legacy reclaim. At 454, aggregated cost and usage is sent to a billing service or component. At 455, an organization can use the tenancy lifecycle service to create subtenancies. At 456, a metering service or component gets subscription mapping data. At 457, a subscription service gets organization data for subscription mapping. At 458, RASL reads the cloud subscription service event stream. At 459, a subscription service reads the cloud subscription service event stream; and at 460, a metering service or component gets rate card data for each subscription, which can then be used for the ability for a PLC operator to charge end fees or PLC operators to charge their customers.

[0152] The above examples are provided to illustrate a computing environment that can be used to provide a dedicated or private label cloud environment for tenants of a cloud infrastructure to use when accessing subscription-based software products, services, or other offerings associated with a cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0153] 3. System architecture for deploying artifacts to a cloud environment

[0154] Figure 11A and 11B FIG. 1 illustrates features of a system 1100. According to one or more embodiments, the system 1100 includes features for setting conditions for deploying artifacts to a computing environment as a verification that a set of one or more customer-specified conditions are satisfied. In one or more embodiments, the system 1100 refers to hardware and / or software configured to perform the operations described herein. Examples of operations are described below with reference to Figure 13A and 13B FIGS. 1-10. In addition to referring to FIGS. 1-10, the following description refers to the example shown in FIG. 1.Figure 11A and 11B In addition to the features described, system 1100 can also include one or more features described in Section 2, entitled “Specialized or Private Tag Cloud Environment.”

[0155] In one or more embodiments, system 1100 can include more or fewer components than those shown in the reference Figure 11A and 11B The components described in reference Figure 11A and 11B may be located on the same or different machines as one another. The components described in reference Figure 11A and 11B may be implemented in software and / or hardware. The components of system 1100 can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. Operations described with respect to one component can be performed by another component.

[0156] A. Example Artifact Deployment Architecture

[0157] In reference to Figure 11A , system 1100 includes a virtual cloud network 1102 in which a set of partitions 1104 are deployed. One or more of the partitions 1104 can be assigned to a PLC operator or customer. Additionally or alternatively, one or more of the partitions can be assigned to a cloud infrastructure provider. In one example, partition 1104a is assigned to a cloud infrastructure provider and partition 1104n is assigned to a PLC operator or customer. The partitions 1104 represent logically or physically isolated portions of the virtual cloud network 1102. In one example, the partitions include realms (such as PLC realms) that isolate portions of the virtual cloud network 1102 between different entities (such as different PLC operators or customers). Additionally or alternatively, the partitions 1104 can include tenant partitions or leases that isolate portions of the virtual cloud network 1102 between different entities or tenants (such as PLC operators or customers). Additionally or alternatively, the partitions 1104 can include one or more of the following: service partitions that isolate different services or workloads; geographic partitions that isolate a portion of the virtual cloud network 1102 that corresponds to a particular geographic region; or network partitions that isolate the virtual cloud network 1102 into separate segments or subnets.

[0158] As shown in Figure 11A , one or more of the partitions 1104 respectively include one or more artifact deployment tools 1106 for deploying artifacts to a target computing environment 1108. In one example, as shown in Figure 11AAs shown in FIG. 11, partition 1104a includes artifact deployment tool 1106a and artifact deployment tool 1106n, and partition 1104n includes artifact deployment tool 1106p and artifact deployment tool 1106z. Artifact deployment tools 1106 can deploy artifacts to target computing environments 1108 that are in the same partition 1104 and / or different partitions 1104 as artifact deployment tools 1106. Partitions 1104 can include one or more target computing environments 1108. In one example, partition 1104n includes target computing environment 1108. Target computing environments 1108 can include one or more resources 1110. In one example, as shown in FIG. 11, target computing environment 1108 includes resource 1110a and resource 1110n. Figure 11A As shown in FIG. 11, partition 1104n includes resource 1110a and resource 1110n. Artifact deployment tools 1106 can deploy one or more artifacts to one or more target computing environments 1108. Additionally or alternatively, artifact deployment tools 1106 can deploy one or more artifacts to one or more resources 1110 of a target computing environment 1108. One or more artifacts can be deployed to a particular resource 1110 of a target computing environment 1108, a subset of resources 1110 of a target computing environment 1108, or all resources 1110 of a target computing environment 1108. A target computing environment 1108 for deploying an artifact can include a set of one or more resources 1110 located in a particular partition 1104 of virtual cloud network 1102. In one example, artifact deployment tool 1106a and / or artifact deployment tool 1106n located in partition 1104a can deploy artifacts to one or more resources 1110 located in partition 1104n. Additionally or alternatively, artifact deployment tool 1106p and / or artifact deployment tool 1106z located in partition 1104n can deploy artifacts to one or more resources 1110 located in partition 1104n.

[0159] In one example, one or more partitions 1104 include a deployment service 1112 that directs artifacts to target computing environments 1108 (such as resources 1110) for deployment. Deployment service 1112 can direct artifacts to target computing environments 1108 for deployment in response to a deployment request from an artifact deployment tool 1106. As shown in FIG. 11, deployment service 1112 is located in partition 1104n. In one example, deployment service 1112 is located in a partition 1104 that is different from a partition 1104 in which an artifact deployment tool 1106 is located. In one example, deployment service 1112 is located in a partition 1104 that is different from a partition 1104 in which a target computing environment 1108 is located. Figure 11AAs shown in FIG. 11, partition 1104n includes a deployment service 1112 that directs artifacts to resources 1110 located in partition 1104n. To deploy an artifact to a target computing environment 1108, such as resource 1110, artifact deployment tool 1106 generates a deployment request and directs the deployment request to a destination address in deployment service 1112 and / or target computing environment 1108. The deployment request can include a request from artifact deployment tool 1106 to deploy an artifact to target computing environment 1108. Additionally or alternatively, the deployment request can include an artifact for deployment to target computing environment 1108 and / or a network address at which the artifact is located. In one example, the deployment request includes a deployment token that represents verification that a set of one or more customer-specified conditions for deploying the artifact to target computing environment 1108 are satisfied. Additionally or alternatively, artifact deployment tool 1106 can provide a deployment token corresponding to the artifact to deployment service 1112 separately from the deployment request.

[0160] In one example, artifact deployment tool 1106 directs the deployment request to deployment service 1112 and deployment service 1112 receives the deployment request. Additionally or alternatively, artifact deployment tool 1106 directs the deployment request to a destination address in target computing environment 1108 and deployment service 1112 intercepts the deployment request. In one example, deployment service 1112 receives a deployment token that is attached to or included in the deployment request. Additionally or alternatively, deployment service 1112 obtains a deployment token in response to receiving the deployment request. Upon successfully validating the deployment token corresponding to the deployment request, deployment service 1112 directs the artifact to the destination address in target computing environment 1108. The artifact is received at the destination address and deployed in target computing environment 1108.

[0161] i. Example Artifacts

[0162] As used herein, the term "artifact" refers to a component or digital asset that is deployable in a computing environment. An artifact can include one or more of a code file, a configuration file, a database, a binary file, an executable file, a library, a document, an image, a template, or a script. Additionally or alternatively, an artifact can include one or more of a patch, an update, a service pack, a version upgrade, a firmware upgrade, a security update, a hotfix, a compatibility update, or a cumulative pack. In one example, a set of customer-specified conditions for deploying an artifact to target computing environment 1108 can depend at least in part on one or more attributes of the artifact. A customer can specify a first set of one or more conditions for deploying a first set of one or more types of artifacts and a second set of one or more conditions for deploying a second set of one or more types of artifacts that are different from the first set of one or more conditions.

[0163] In one example, the artifacts deployed to the target computing environment 1108 include one or more of: a container artifact, an application code artifact, a database artifact, a monitoring and logging artifact, or a security policy artifact. The container artifact can include docker files and images that contain application dependencies, libraries, and / or runtime environments. The container artifact can be packaged into a container for deployment. Additionally or alternatively, the container artifact can include a container registry for storing and distributing container images. The application code artifact can include code, scripts, resources for an application, installation packages, binaries, infrastructure as code, and / or deployment templates. The database artifact can include artifacts for relational databases, NoSQL databases, and / or data migration. The database artifact for relational databases can include SQL scripts, database schemas, and / or data definition language (DDL) scripts for deploying relational databases. The database artifact for NoSQL databases can include configuration files and / or schema definitions. The database artifact for data migration can include data migration scripts, for example, for migrating data between different database versions and / or platforms. The monitoring and logging artifact can include monitoring agents, configuration files for monitoring systems, and / or configuration files for logging frameworks. The security policy artifact can include security configuration files, security framework files, certificate authority (CA) configuration files, digital certificates, public keys, private keys, key pairs, and / or IAM configuration files.

[0164] In one example, the artifacts deployed to the target computing environment 1108 include artifacts associated with one or more of: operating system updates, database upgrades, software upgrades, patch management, library and framework updates, infrastructure maintenance, version control, dependency management, backup and recovery, capacity planning, health checks and monitoring, change management, or incident response. Additionally or alternatively, the artifacts deployed to the target computing environment 1108 can include artifacts associated with one or more of: environment provisioning, auto-scaling, configuration management, continuous integration (CI), continuous deployment (CD), rolling deployment, blue-green deployment, canary deployment, A / B testing, load balancing, data migration, disaster recovery.

[0165] Operating system updates include installing updates and patches for the operating system, for example, to implement new features and / or address security vulnerabilities, bugs, or performance issues. Database upgrades include upgrading the database software to a newer version or applying patches, for example, to improve performance, security, and reliability. Software upgrades include upgrading software components, libraries, or dependencies, for example, to provide new features, improvements, and / or security enhancements. Patch management includes applying patches, security updates, and / or bug fixes for software or systems, for example, to address vulnerabilities and improve stability. Library and framework updates include updating libraries, frameworks, and / or dependencies used in applications, for example, to take advantage of new features and enhancements. Infrastructure maintenance includes performing routine maintenance tasks, such as disk cleanup, system optimization, and / or security hardening, for example, to ensure optimal performance and security. Version control includes managing and tracking changes to code, configurations, and / or other artifacts. Dependency management includes managing dependencies between software components, for example, to ensure compatibility and / or resolve conflicts. Backup and recovery includes creating backups of data and / or configurations, and implementing recovery procedures to restore systems in the event of, for example, data loss or corruption. Capacity planning includes monitoring resource usage and forecasting future demand, for example, to appropriately scale infrastructure and / or avoid performance degradation or service interruptions. Health checks and monitoring include periodically or intermittently performing health checks and / or monitoring system metrics, for example, to detect issues and proactively address them. Change management includes processes and controls for managing changes to systems, applications, and / or infrastructure, for example, to minimize disruptions and risks. Incident response includes responding to incidents, investigating root causes, and / or implementing corrective actions.

[0166] Environment provisioning includes instantiation and configuration of development, testing, and / or production environments. Configuration management includes managing and maintaining the configuration of the overall cloud environment. CI includes automating the processing of integrated code changes across the overall cloud environment. CD includes deploying code changes across the overall cloud environment, e.g., after passing automated testing. Auto-scaling includes automatically adjusting the number of resources in the cloud environment based on demand, e.g., to optimize performance and cost. Rolling deployment includes deploying changes to a subset of the cloud environment, e.g., to minimize downtime and risk. Blue-green deployment includes deploying changes to a parallel environment (blue) before routing traffic from the existing environment (green), e.g., to minimize downtime. Canary deployment includes releasing changes to a subset of the cloud environment and / or a subset of users, e.g., to test for problems before rolling out the changes to the overall cloud environment and / or user population. A / B testing includes testing two or more versions of an application or feature on different parts of the cloud environment and / or groups of users, e.g., to compare performance and / or user experience. Load balancing includes distributing incoming traffic to multiple servers or instances, e.g., to improve reliability and performance. Data migration includes transferring data between different storage systems or databases, e.g., while maintaining data integrity and consistency. Disaster recovery includes processes and procedures for recovering from system failures or disasters and quickly restoring services.

[0167] ii. Example Artifact Deployment Tools

[0168] The virtual cloud network 1102 can include one or more different types of artifact deployment tools 1106 for deploying artifacts to the target computing environment 1108. Different artifact deployment tools 1106 can be used for the same type of artifact and / or different types of artifacts. Additionally or alternatively, different artifact deployment tools 1106 can be used for the same target computing environment 1108 and / or different target computing environments 1108. An artifact deployment tool can include one or more of a configuration deployment tool, a maintenance management tool, an administrator tool, or a command line interface. In one example, the set of one or more conditions specified by a customer for deploying an artifact to a target computing environment 1108 can depend at least in part on one or more attributes of the artifact deployment tool 1106. The customer can specify a first set of one or more conditions for deploying an artifact to a target computing environment 1108 using a first deployment tool 1106 and a second set of one or more conditions different from the first set of one or more conditions for deploying an artifact to a target computing environment 1108 using a second deployment tool 1106.

[0169] A configuration deployment tool can include an application that automates the deployment and management of artifacts related to the configuration of a cloud environment. Artifacts deployed by a configuration deployment tool to a cloud environment can relate to the configuration or setup of various resources in the cloud environment. A configuration deployment tool can utilize declarative or imperative scripts to define a desired state of the cloud environment, and can deploy artifacts to ensure consistency in configuration settings throughout the cloud environment. A configuration deployment tool can simplify the process of provisioning and maintaining a cloud environment, for example, by automating tasks such as installing software, configuring services, and managing system settings. A configuration deployment tool can help ensure that various resources of a cloud environment are configured according to predefined specifications. Deploying artifacts through a configuration management tool can reduce human error and / or improve consistency in the deployment of artifacts throughout a cloud environment.

[0170] A maintenance management tool can include an application that automates the deployment and management of artifacts related to the maintenance and management of a cloud environment. Artifacts deployed by a maintenance management tool to a cloud environment can relate to maintenance or management tasks of a cloud environment, such as one or more of the following: software updates, patch management, configuration changes, or monitoring system health resources. A maintenance management tool can automate various maintenance or management tasks. Deploying artifacts through a maintenance management tool can enable proactive maintenance practices, reduce downtime, enhance security, and / or optimize resource utilization.

[0171] An administrator tool can include an application that simplifies administrative tasks related to operating a cloud environment and / or various services deployed in a cloud environment. Artifacts deployed by an administrator tool to a cloud environment can relate to administrative activities, such as technical support, troubleshooting, and / or proactive measures to ensure the reliability and security of a cloud environment.

[0172] A command-line interface includes a text-based interface configured to interact with a cloud environment through command-line commands. A command-line interface provides an operator with a way to deploy artifacts to a cloud environment directly from a terminal or command prompt. A cloud operator can utilize a command-line interface to deploy artifacts to a cloud environment and perform various operations, including one or more of the following: management, software installation, configuration changes, upgrades, and / or patches.

[0173] iii. Example target computing environment

[0174] Target computing environment 1108 can include one or more portions of a computing environment in which a artifact is deployed, such as virtual cloud network 1102. In one example, target computing environment 1108 includes partition 1104 in which the artifact is deployed. Additionally or alternatively, target computing environment 1108 can include a set of one or more resources 1110 in which the artifact is deployed, and / or a portion of a computing environment in which a set of one or more resources 1110 is located with which the artifact is utilized. Partition 1104 and / or resource 1110 corresponding to target computing environment 1108 can be identified based on a resource identification number and / or a network address.

[0175] Resource 1110 can include a hardware or software component used to construct, maintain, or operate a cloud infrastructure and / or a service deployed in a cloud infrastructure. A hardware resource can include one or more of a server, a processor, a memory device, a storage device, or a networking device. A software resource can include one or more of an operating system, a cloud management platform, a security platform, a development tool, a compute instance, a virtual machine, a container, a serverless computing platform, an auto-scaling application, a storage platform, a networking application, or a service deployed in a cloud environment. In one example, one or more services deployed in a cloud infrastructure are resources relative to one or more other services in the cloud infrastructure.

[0176] In one example, the set of customer-specified conditions for deploying an artifact to target computing environment 1108 can depend at least in part on one or more attributes of target computing environment 1108 in which the artifact is deployed. Additionally or alternatively, the set of customer-specified conditions for deploying an artifact can depend at least in part on one or more attributes of a set of one or more resources 1110 with which the artifact is utilized. A customer can specify a first set of one or more conditions for deploying an artifact to a target computing environment with a first deployment tool 1106, and a second set of one or more conditions for deploying an artifact to a target computing environment with a second deployment tool 1106 that is different from the first set of one or more conditions.

[0177] iv. Example deployment service

[0178] Deployment service 1112 can operate as an intermediary, such as middleware, for deploying artifacts to target computing environments. In one example, deployment service 1112 is a deployment service. Deployment service 1112 can receive a deployment request, obtain a deployment token, and / or obtain confirmation of a deployment token. Additionally or alternatively, deployment service 1112 can direct an artifact to a target computing environment for deployment. In one example, deployment service 1112 can

[0179] The deployment service 1112 can interact with a data corpus that includes information or metadata related to various target computing environments. Additionally or alternatively, the data corpus can include information or metadata related to various resources 1110 in the cloud environment. Additionally or alternatively, the deployment service can interact with configuration files associated with various resources 1110 to obtain information or metadata related to the various resources 1110 and / or the target computing environments in which the resources are located.

[0180] In one example, the deployment service 1112 can determine that distribution of a workpiece to a target computing environment and / or a particular resource 1110 in the target computing environment is conditioned on successful validation of a deployment token based on attributes corresponding to the target computing environment and / or the particular resource 1110 in the target computing environment. When the deployment service 1112 receives a deployment request, the deployment service 1112 can determine that distribution of a workpiece to a target computing environment and / or a particular resource 1110 in the target computing environment is conditioned on successful validation of a deployment token. In response to determining that distribution of the workpiece is conditioned on successful validation of a deployment token, the deployment service 1112 can determine whether a deployment token is included in the deployment request. Additionally or alternatively, the deployment service 1112 can obtain a deployment token for distribution of the workpiece. The deployment service 1112 can validate the deployment token, and upon successful validation of the deployment token, the deployment service 1112 directs the workpiece to the target computing environment for deployment. If a deployment token is not included in the deployment request and / or if the deployment service 1112 is unable to obtain a deployment token, then the deployment service 1112 can refrain from deploying the workpiece. Additionally or alternatively, the deployment service 1112 can direct a notification to the workpiece deployment tool 1106 that submitted the deployment request. The notification can indicate that the deployment service 1112 refrained from deploying the workpiece and / or that distribution of the workpiece was conditioned on successful validation of a deployment token. In response to determining that distribution of the workpiece is not conditioned on successful validation of a deployment token, the deployment service 1112 can direct the workpiece to the target computing environment for deployment without requiring a deployment token.

[0181] In one example, the deployment service 1112 can utilize the data corpus and / or configuration files to determine information or metadata for deploying a workpiece to a resource 1110. In one example, the deployment service 1112 can determine a destination address of a resource 1110 to direct a workpiece to the resource 1110 for deployment. In one example, the deployment service 1112 can allow customer-facing endpoints to be decoupled from an internal service architecture. The deployment service 1112 can map customer-facing endpoints to destination addresses of resources 1110 in the cloud environment.

[0182] The deployment service 1112 can handle the distribution of particular artifacts to particular target computing environments and / or resources 1110. Additionally or alternatively, the deployment service 1112 can push artifacts out to groups of resources 1110, e.g., in connection with environment- wide changes. The deployment service 1112 can coordinate the acquisition and / or validation of deployment tokens for respective target computing environments and / or resources that are part of an environment-wide change. In one example, an environment-wide change can include the deployment of one or more artifacts in one or more partitions 1104 of the virtual cloud network 1102. Additionally or alternatively, an environment-wide change can include the deployment of one or more artifacts to a particular group of resources 1110 located in one or more partitions 1104 of the virtual cloud network 1102. The group of resources 1110 can include multiple instances of a particular resource 1110 and / or different types of resources 1110.

[0183] In one example, the deployment service 1112 can interact with an IAM service to authenticate various entities associated with a deployment request and / or determine whether the various entities are authorized to initiate the deployment request in accordance with applicable access policies. Entities authenticated by the deployment service 1112 can include resource principals associated with the artifact deployment tool 1106 and / or user principals associated with users initiating deployment requests via the artifact deployment tool 1106.

[0184] B. Example Artifact Validation Service

[0185] Reference is made to and incorporated by reference Figure 11B the features of the system 1100 are further described in accordance with one or more embodiments. Reference is made to and incorporated by reference Figure 11B The described features include features for setting conditions for deployment of artifacts to computing environments to validate that a set of one or more customer-specified conditions are satisfied. As Figure 11B shown in

[0186] The validation service 1120 performs operations for providing customer-specified conditions for deployment of artifacts to computing environments. Further, the validation service 1120 performs operations for validating that the customer-specified conditions are satisfied. In one example, as Figure 11B shown in Figure 11B shown in

[0187] In one example, the validation service 1120 can be implemented as a service deployed in a cloud environment. The various artifact deployment tools 1106 Figure 11A and / or the various deployment services 1112 Figure 11A may interact with the validation service 1120, e.g., in connection with deploying artifacts into the target computing environment 1108 Figure 11A . Additionally or alternatively, the validation service 1120 can be implemented as a component of the artifact deployment tools 1106. The artifact deployment tools 1106 can perform operations of the validation service 1120, e.g., in connection with deploying artifacts into the target computing environment 1108. Additionally or alternatively, the validation service 1120 can be implemented as a component of the deployment services 1112 Figure 11A . The deployment services 1112 can perform operations of the validation service 1120, e.g., in connection with deploying artifacts into the target computing environment 1108. In one example, a first set of one or more features of the validation service 1120 can be implemented as a component of the artifact deployment tools 1106, and a second set of one or more features of the validation service 1120 can be implemented as a component of the deployment services 1112. Additionally or alternatively, one or more features of the validation service 1120 can be implemented as a service deployed in a cloud environment that interacts with the various artifact deployment tools 1106 and / or the various deployment services 1112 that respectively include other features of the validation service 1120.

[0188] As shown with reference to Figure 11B , the validation service 1120 includes one or more of a condition specification module 1128, a deployment request evaluation module 1130, a validation module 1132, or a deployment token provisioning module 1134. One or more of the condition specification module 1128, the deployment request evaluation module 1130, the validation module 1132, and / or the deployment token provisioning module 1134 can be implemented in different instances of the validation service 1120, respectively. In one example, different instances of the validation service 1120 can be implemented as a component of the artifact deployment tools 1106, a component of the deployment services 1112, and / or a service deployed in a cloud environment that interacts with one or more artifact deployment tools 1106 and / or one or more deployment services 1112.

[0189] i. Example Condition Specification Module

[0190] The validation service 1120 can include a condition specification module 1128. The condition specification module 1128 can specify conditions specified by a customer in connection with the target computing environment 1108 Figure 11Aassociated. In one example, the condition specifying module 1128 determines the customer specified condition based on input from the operator device interface 1122. The input can identify the target computing environment 1108 and a set of one or more conditions for deploying artifacts to the target computing environment 1108. Additionally or alternatively, the input can identify a set of one or more artifacts for which the set of one or more conditions apply, e.g., based on one or more artifact properties.

[0191] In one example, the customer specified condition includes verifying that approval has been obtained to deploy the artifact to the computing environment. The customer specified condition can also include verifying that approval was obtained according to a customer defined approval workflow. The approval workflow can include one or more operations described in one or more of the following U.S. Patent Applications, each of which is incorporated herein by reference: U.S. Patent Application Serial No.____________ entitled “Using Consent in Conjunction with Access Policies to Control Access in a PLC Realm,” filed on __________; U.S. Patent Application Serial No. 18 / 410,231 entitled “Issuing Surrogate Credentials For Accessing Target Resources,” filed on January 11, 2024; U.S. Patent Application Serial No. 18 / 529,558 entitled “Issuing Delegate Credentials for Accessing Target Resources,” filed on December 5, 2023; U.S. Patent Application Serial No. 18 / 640,885 entitled “Determining Approval Workflows for Obtaining Approvals to Access Resources,” filed on April 19, 2024; or U.S. Patent Application Serial No. 18 / 539,987 entitled “Re-Executing an Authorization Process to Determine an Updated Set of Authorized Actions That may be Initiated by a Computing Entity During a Session,” filed on December 14, 2023.

[0192] Additionally or alternatively, the customer-specified condition can include verifying that a set of one or more deployment states of the customer-specified target computing environment are satisfied. The set of deployment states can include one or more of: a deployment time for deploying the artifact to the target computing environment; a deployment order for deploying the artifact to the target computing environment; or a deployment frequency for deploying the artifact to the target computing environment. The deployment states of the target computing environment can be determined based on a snapshot representing a state of the target computing environment at a particular point in time. The snapshot reflects data, configurations, and / or settings of the target computing environment. In one example, the snapshot can be a backup or disaster recovery snapshot obtained at least in part for backup or disaster recovery purposes. Additionally or alternatively, the snapshot can be a deployment snapshot obtained for a particular purpose of deploying the artifact to the target computing environment. At least a portion of the snapshot can be obtained from logs or scripts generated by a telemetry or monitoring service. Additionally or alternatively, at least a portion of the snapshot can be obtained directly from resources in the cloud environment.

[0193] Verifying a deployment time for deploying the artifact to the target computing environment can include verifying that the deployment time is consistent with one or more time windows. The one or more time windows can include at least one of: one or more times of day, one or more days of the week, one or more days of the month, or one or more days of the year. The deployment time, such as the one or more time windows, can be specified by the customer. Additionally or alternatively, the cloud infrastructure provider can specify a deployment time, such as the one or more time windows, for deploying the artifact to the target computing environment. The customer can specify the cloud infrastructure provider-specified deployment time as a customer-specified condition, e.g., to verify that the artifact is deployed in accordance with a deployment time corresponding to the target resource specified by the cloud infrastructure provider.

[0194] Verification of a deployment order for deploying the artifact to the target computing environment can include verifying that the deployment of the artifact satisfies one or more versioning conditions. The versioning conditions can include verifying that the artifact adheres to a specified roll-out order. The specified roll-out order can be configured to ensure that the artifact is compatible with its previous iteration, the target computing environment, other computing environments, other resources in the target computing environment, and / or other computing environments. The specified roll-out order can include an order that increments from a particular iteration of the artifact to a next iteration of the artifact. Additionally or alternatively, the roll-out order can include an order that increments multiple sets of artifacts that interact with or depend on each other in parallel. In one example, the roll-out order can provide for concurrent distribution of a set of one or more artifacts to a set of target computing environments. Additionally or alternatively, the roll-out order can condition provision of a first artifact to resource A on verifying that a second artifact has been previously provisioned to resource B. The second artifact can correspond to a particular version number relative to the first artifact. Additionally or alternatively, the upgrade order can exclude skipping versions.

[0195] Verification of a deployment frequency of deploying a work item to a target computing environment can include verifying that a plurality of work items are not scheduled to be deployed concurrently with each other and / or that deployment time periods do not overlap. Additionally or alternatively, the deployment frequency can include a condition that limits a number of deployments within a particular time window. The number of deployments can be limited for a particular target computing environment, a particular resource, and / or a particular type of work item.

[0196] Additionally or alternatively, the customer-specified conditions can include verifying that a change ticket associated with deploying a work item to a target computing environment satisfies a set of one or more ticket verification criteria. The ticket verification criteria can be selected based on a source of the change ticket. A first set of criteria corresponds to change tickets originating from a source identifiable by an identity resource associated with the customer. A second set of criteria corresponds to change tickets originating from a source identifiable by an identity resource associated with a cloud infrastructure provider corresponding to the target resource. The change ticket criteria can include one or more of verifying that the change ticket is valid, verifying that the change ticket is approved, or verifying that a current time of execution is within an approved change window of the change ticket.

[0197] ii. Example Deployment Request Evaluation Module

[0198] Verification service 1120 can include a deployment request evaluation module 1130. Deployment request evaluation module 1130 detects a deployment request to deploy a work item to a target computing environment. In one example, when deployment request evaluation module 1130 detects a deployment request, deployment request evaluation module 1130 can determine whether deployment of the work item is conditioned on verifying that a set of customer-specified conditions are satisfied. Additionally or alternatively, deployment request evaluation module 1130 can determine a particular customer-specified condition that applies to the particular deployment request. Additionally or alternatively, deployment request evaluation module 1130 can determine whether deployment of the work item to the target computing environment is conditioned on having a valid deployment token. In one example, when deployment of the work item is conditioned on having a valid deployment token, deployment request evaluation module 1130 can determine whether a deployment token has been provided in association with the deployment request. When a deployment token has been provided in association with the deployment request, deployment request evaluation module 1130 can prompt a verification module 1132 to verify that the deployment token is valid. Additionally or alternatively, when deployment of the work item is conditioned on having a valid deployment token, deployment request evaluation module 1130 can prompt a deployment token provisioning module 1134 to initiate a process to obtain a deployment token.

[0199] In one example, the deployment request evaluation module 1130 can determine whether deployment of a particular artifact is conditioned on verification that a set of customer-specified conditions are satisfied based at least in part on the particular target computing environment in which the artifact is being deployed. Additionally or alternatively, the deployment request evaluation module 1130 can determine whether deployment of an artifact is conditioned on successful validation of a deployment token corresponding to the deployment based at least in part on the particular target computing environment in which the artifact is being deployed. The deployment request evaluation module 1130 can determine based at least in part on a set of one or more attributes of the target computing environment. In one example, deployment of an artifact to a first target computing environment having a first set of one or more attributes is conditioned on verification that a set of customer-specified conditions are satisfied and / or successful validation of a deployment token corresponding to the deployment. Further, in one example, a second target computing environment having a second set of one or more attributes is not subject to the customer-specified conditions for deployment of the artifact and the artifact can be deployed to the second target computing environment without having a valid deployment token corresponding to the deployment.

[0200] The set of one or more attributes of the target computing environment can include one or more of a resource identification number, a network address, a partition identification number, a host name, a subnet, a set of one or more resources deployed in the target computing environment, a customer associated with the target computing environment, an identity resource associated with the target computing environment, or an access policy associated with the target computing environment. The set of one or more attributes of the target computing environment can be stored in the data corpus 1124 and / or metadata associated with the target computing environment. The deployment request evaluation module 1130 can reference one or more of the attributes of the target computing environment to determine whether deployment is conditioned on verification of satisfaction of customer-specified conditions and / or to determine whether deployment is conditioned on validation of a deployment token.

[0201] In one example, the deployment request evaluation module 1130 can determine whether deployment of a particular artifact is conditioned on verification that a set of customer-specified conditions are satisfied based at least in part on the particular artifact being deployed. Additionally or alternatively, the deployment request evaluation module 1130 can determine whether deployment of an artifact is conditioned on successful validation of a deployment token corresponding to the deployment based at least in part on the particular artifact being deployed. The deployment request evaluation module 1130 can determine based at least in part on a set of one or more attributes of the artifact. In one example, deployment of an artifact having a first set of one or more attributes is conditioned on verification that a set of customer-specified conditions are satisfied and / or successful validation of a deployment token corresponding to the deployment. Further, in one example, a second artifact having a second set of one or more attributes is not subject to the customer-specified conditions for deployment of the artifact and the artifact can be deployed without having a valid deployment token corresponding to the deployment.

[0202] The set of one or more attributes of the artifact can include one or more of an artifact type attribute, a configuration attribute, a metadata attribute, a resource attribute, a lifecycle attribute, an operational attribute, a security attribute, a performance attribute, an interoperability attribute, or a compliance attribute. The artifact type attribute includes a kind or class of the artifact. The configuration attribute includes one or more configuration settings or parameters associated with the artifact. The metadata attribute includes information about the artifact stored in metadata. The lifecycle attribute includes a period of a lifecycle of the artifact, such as whether a current period of the artifact is development, testing, pre-release, production, or retired. The operational attribute includes an operational aspect of the artifact, such as a monitoring aspect, a logging aspect, an alerting aspect, a backup aspect, or a disaster recovery aspect. The security attribute indicates one or more security features of the artifact, such as an encryption feature, an authentication feature, or an authorization feature. The performance attribute includes one or more performance characteristics of the artifact, such as a throughput characteristic, a latency characteristic, a response time characteristic, a concurrency characteristic, or a scalability characteristic. The interoperability attribute includes one or more attributes related to compatibility or interoperability of the artifact with other systems, platforms, protocols, and / or standards. The compliance attribute indicates whether the artifact complies with one or more of a regulatory requirement, a data privacy requirement, a security requirement, an industry standard, or an organizational policy, and combinations of these. The set of one or more attributes of the artifact can be stored in the data corpus 1124 and / or in metadata associated with the artifact. The deployment request evaluation module 1130 can reference one or more of the attributes of the artifact to determine whether deployment of the artifact is conditioned on verification of satisfaction of a set of customer-specified conditions and / or to determine whether deployment of the artifact is conditioned on validation of a deployment token.

[0203] iii. Example Validation Module

[0204] The validation service 1120 can include a validation module 1132. In one example, the validation module 1132 can validate that a set of customer-specified conditions for deployment of an artifact to a target computing environment are satisfied. The deployment request evaluation module 1130 can provide an indication to the validation module 1132 that deployment of an artifact is conditioned on satisfaction of a set of customer-specified conditions. The validation module 1132 can validate, in response to the indication from the deployment request evaluation module 1130, that the set of customer-specified conditions are satisfied. In one example, the indication from the deployment request evaluation module 1130 includes an indication of a particular customer-specified condition that is applicable to a particular deployment request. Additionally or alternatively, the validation module 1132 can determine a particular customer-specified condition that is applicable to a particular deployment request.

[0205] In one example, the validation module 1132 can validate a deployment token that represents a validation that a set of customer-specified conditions for deploying an artifact to a target computing environment are satisfied. The deployment request evaluation module 1130 can provide an indication to the validation module 1132 that deployment of an artifact to a target computing environment is conditioned on having a valid deployment token. In one example, the deployment request evaluation module 1130 can provide the validation module 1132 with a deployment token corresponding to a deployment request, and the validation module can validate the deployment token. Additionally or alternatively, the validation module can obtain and / or receive a deployment token corresponding to a deployment request from the deployment token provisioning module 1134.

[0206] In one example, the validation module 1132 includes one or more of an operator approval sub-module 1136, a deployment status sub-module 1138, and a change ticket sub-module 1140. The operator approval sub-module 1136 initiates a workflow for obtaining approval for deploying an artifact to a target computing environment corresponding to a customer-specified condition associated with a deployment request. The workflow can be specified by a customer via the condition specification module 1128. The operator approval sub-module 1136 can validate that approval for deploying an artifact has been obtained. In one example, the operator approval sub-module 1136 can validate that approval for deploying an artifact has been obtained prior to the deployment token provisioning module 1134 obtaining a deployment token corresponding to a deployment request. The deployment status sub-module 1138 validates that a set of one or more deployment status corresponding to one or more customer-specified conditions associated with a deployment request are satisfied. In one example, the deployment status sub-module 1138 can validate that the set of one or more deployment status are satisfied prior to the deployment token provisioning module 1134 obtaining a deployment token corresponding to a deployment request. The change ticket sub-module 1140 validates that a set of one or more ticket validation conditions corresponding to one or more customer-specified conditions associated with a deployment request are satisfied with respect to a change ticket. In one example, the deployment status sub-module 1138 can validate that the set of one or more ticket validation conditions are satisfied prior to the deployment token provisioning module 1134 obtaining a deployment token corresponding to a deployment request.

[0207] In one example, the validation module 1132 includes a deployment token validation sub-module 1142. The deployment token validation sub-module validates a deployment token associated with a deployment request. The deployment token validation sub-module 1142 can validate a deployment token that includes a deployment token obtained by the deployment token provisioning module 1134 and / or a deployment token provided with a deployment token request. In one example, the deployment token includes a digital signature generated by an entity that issued the deployment token. The digital signature can be generated using a symmetric key or an asymmetric key. The deployment token validation sub-module 1142 can validate the deployment token at least by validating the digital signature of the deployment token, e.g., using symmetric key validation or asymmetric key validation as the case can be.

[0208] For symmetric key verification, the digital signature includes a cryptographic hash of the contents of the deployment token generated using a secret key. To verify the digital signature using symmetric key verification, the deployment token validation submodule 1142 generates a cryptographic hash of the contents of the deployment token using the same secret key used to generate the digital signature. The deployment token validation submodule 1142 compares the cryptographic hash generated using the secret key to the cryptographic hash included in the digital signature.

[0209] For asymmetric key verification, a pair of asymmetric keys including a private key and a public key are utilized. The digital signature includes a cryptographic hash of the contents of the deployment token generated using the private key. To verify the digital signature using asymmetric key verification, the deployment token validation submodule 1142 generates a cryptographic hash of the contents of the deployment token using the public key. The deployment token validation submodule 1142 compares the cryptographic hash generated using the public key to the cryptographic hash included in the digital signature.

[0210] When the cryptographic hash generated by the deployment token validation submodule 1142 matches the cryptographic hash included in the digital signature, the deployment token validation submodule 1142 determines that the deployment token is valid. When the cryptographic hash generated by the deployment token validation submodule 1142 does not match the digital signature, the deployment token validation submodule 1142 determines that the deployment token is invalid. Additionally or alternatively, the deployment token validation submodule 1142 can validate the deployment token based on one or more other validation techniques. For example, the deployment token validation submodule 1142 can validate the deployment token based on one or more of: token structure, token decoding, payload claim checking, or custom validation logic.

[0211] Additionally or alternatively, in one example, the deployment token validation submodule 1142 can validate the deployment token based on one or more identity resources in the IAM service. In one example, the deployment token validation submodule 1142 can validate one or more identity resources associated with the holder of the deployment token and / or the source of the deployment request. The deployment token validation submodule 1142 can validate that the one or more identity resources have sufficient permissions to utilize the deployment token according to one or more access policies in the IAM service.

[0212] iv. Example Deployment Token Provisioning Module

[0213] The validation service 1120 can include a deployment token provisioning module 1134. The deployment token provisioning module 1134 can provision a deployment token that validates that a set of one or more customer-specified conditions for deploying a workpiece to a target computing environment are satisfied.

[0214] In one example, the deployment token provisioning module 1134 can issue a deployment token. In one example, the deployment token provisioning module 1134 can issue a deployment token in response to, for example, a token request and / or a deployment request from the artifact deployment tool 1106 Figure 11A . The deployment token provisioning module 1134 can issue a deployment token at least partially in response to verifying that a set of one or more customer-specified conditions for deploying the artifact to the target computing environment are satisfied. In one example, the deployment token provisioning module 1134 can obtain verification from the verification module 1132 that the set of one or more customer-specified conditions for deploying the artifact to the target computing environment are satisfied. In one example, the deployment token provisioning module 1134 can obtain verification from the verification module 1132 in response to a token request and / or a deployment request. The deployment token provisioning module 1134 can issue a deployment token in response to verification from the verification module 1132.

[0215] In one example, the deployment token provisioning module 1134 can obtain a deployment token from the IAM service 1126. The deployment token provisioning module 1134 can direct a token request to the IAM service 1126. The deployment token provisioning module 1134 can direct a token request to the IAM service 1126 in response to, for example, an artifact deployment request from the artifact deployment tool 1106 Figure 11A . The IAM service 1126 can issue a deployment token at least partially in response to verifying that a set of one or more customer-specified conditions for deploying the artifact to the target computing environment are satisfied. In one example, the IAM service 1126 can obtain verification from the verification module 1132 that the set of one or more customer-specified conditions for deploying the artifact to the target computing environment are satisfied. Additionally or alternatively, the token request can include verification that the set of one or more customer-specified conditions are satisfied. The IAM service 1126 can issue a deployment token in response to verifying that the set of one or more customer-specified conditions are satisfied.

[0216] A deployment token provided by the deployment token provisioning module 1134 can be included in a deployment request to deploy the artifact to the target computing environment. The deployment token provisioning module 1134 can provide a deployment token to the artifact deployment tool 1106 Figure 11A and / or the deployment service 1112 Figure 12 , for example, in response to a token request. The artifact deployment tool 1106 and / or the deployment service 1112 can include a deployment token in a deployment request.

[0217] C. Example Operator Device Interface

[0218] In one example, the operator device interface 1122 can be coupled or communicatively coupled with the verification service 1120. The operator device interface 1122 can include hardware and / or software configured to facilitate interaction between an operator and the verification service 1120 and / or other aspects of the system 1100. The operator device interface 1122 can render user interface elements and receive input via the user interface elements. The operator device interface 1122 receives input for the verification service 1120. Additionally or alternatively, the operator device interface 1122 can display output generated by the verification service 1120. Examples of interfaces include a GUI, a command line interface (CLI), a haptic interface, or a voice command interface. Examples of user interface elements include checkboxes, radio buttons, drop-down lists, list boxes, buttons, toggle buttons, text fields, date and time selectors, command lines, sliders, pages, or forms. The operator device interface 1122 can utilize any one or more of these interfaces or interface elements.

[0219] In embodiments, different components of the operator device interface 1122 are specified using different languages. The behavior of user interface elements is specified using a dynamic programming language (e.g., JavaScript). The content of user interface elements is specified using a markup language, such as HyperText Markup Language (HTML) or XML User Interface Language (XUL). The layout of user interface elements is specified using a style sheet language, such as Cascading Style Sheets (CSS). Alternatively, the operator device interface 1122 can be specified using one or more other languages, such as Java, C, or C++.

[0220] In one example, the verification service 1120 can be implemented on one or more digital devices. The term “digital device” generally refers to any hardware device that includes a processor. A digital device can refer to a physical device that executes an application or a virtual machine. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook, a server, a web server, a network policy server, a mediation server, a general purpose machine, a function-specific hardware device, a hardware router, a hardware switch, a hardware firewall, a hardware firewall, a hardware network address translator (NAT), a hardware load balancer, a mainframe, a television, a content receiver, a set-top box, a printer, a mobile handset, a smartphone, a personal digital assistant (PDA), a wireless receiver and / or transmitter, a base station, a communication management device, a router, a switch, a controller, an access point, and / or a browser device.

[0221] D. Example Data Corpus

[0222] Reference is made to Figure 12 to further describe features of the example data corpus 1200. Reference is made to Figure 11A The data corpus 1200 described can be included in a referenceFigure 11B and 11B one or more embodiments described. Reference is made to Figure 12 The data corpus 1124 described can include reference Figure 11B The data corpus 1200 described can include one or more features described with reference to Figure 11A The validation service 1120 (described ) can perform operations based on information obtained from the data corpus 1200. Additionally or alternatively, information described with reference to the data corpus 1200 can be implemented in metadata associated with one or more components of the system described Figure 12 and 11B described.

[0223] As shown in Figure 12 , the data corpus 1200 includes a data structure having one or more customer-specified conditions 1202 for deploying artifacts to target computing environments. In one example, the data corpus 1200 includes customer-specified condition 1202a, customer-specified condition 1202b, customer-specified condition 1202c, customer-specified condition 1202d, customer-specified condition 1202e, and customer-specified condition 1202n. The one or more customer-specified conditions can each include one or more of the following data elements: a target computing environment 1204, a destination address 1206 corresponding to the target computing environment 1204, a token requirement indication 1208 indicating whether a deployment token is required to deploy an artifact to the target computing environment 1204, an artifact type indication 1210 indicating one or more types of artifacts that are subject to the customer-specified condition 1202, a set of one or more verifications 1212 corresponding to the customer-specified condition 1202, and a status 1214 of the set of one or more verifications.

[0224] The target computing environment 1204 can include one or more resources. The destination address 1206 can correspond to a location of one or more resources in the target computing environment 1204. An artifact can be deployed to the target computing environment 1204 at the destination address 1206. In one example, the system can determine whether a deployment token is required to deploy an artifact to the target computing environment 1204 based at least in part on the token requirement indication 1208. As shown in Figure 12 , the token requirement indication 1208 of customer-specified condition 1202e indicates that a deployment token is not required to deploy an artifact to the target computing environment 1204 corresponding to customer-specified condition 1202e.

[0225] Additionally or alternatively, the system can determine which types of artifacts require a deployment token based on the artifact type indication 1210. As shown in Figure 12As shown in the middle, the artifact type indications 1210 indicate that all artifacts deployed to the target computing environments 1204 corresponding to the customer-specified condition 1202a, the customer-specified condition 1202d, and the customer-specified condition 1202n require a deployment token. In addition, the artifact type indications 1210 indicate that, for the target computing environment 1204 corresponding to the customer-specified condition 1202b, deploying an artifact that satisfies one or more criteria corresponding to type B requires a deployment token. In addition, the artifact type indications 1210 indicate that, for the target computing environment 1204 corresponding to the customer-specified condition 1202c, deploying an artifact that satisfies one or more criteria corresponding to type C requires a deployment token.

[0226] The system can determine whether the verifications 1212 corresponding to the customer-specified conditions 1202 are satisfied based at least in part on the statuses 1214 corresponding to the verifications 1212. As Figure 11B As shown in the middle, the statuses 1214 corresponding to the verifications 1212 of the customer-specified condition 1202a, the customer-specified condition 1202b, and the customer-specified condition 1202n indicate that the verifications 1212 are satisfied. The statuses 1214 corresponding to the verifications 1212 of the customer-specified condition 1202c and the customer-specified condition 1202d indicate that at least one of the verifications 1212 is not satisfied.

[0227] In one or more embodiments, the data corpus 1200 is any type of storage unit and / or device (e.g., a file system, a database, a collection of tables, or any other storage mechanism) for storing data. In addition, the data corpus 1200 can include multiple different storage units and / or devices. The multiple different storage units and / or devices can or can not be of the same type, or located at the same physical site. In addition, the data corpus 1200 can be implemented or executed on the same computing system as the verification service 1120. Figure 11A Additionally or alternatively, the data corpus 1200 can be implemented or executed on a different computing system than the verification service 1120. The data corpus 1200 can be communicatively coupled to the verification service 1120 via a direct connection or via a network. The information describing the data corpus 1200 can be implemented in any component of the system 1100 Figure 13A and 11B However, for clarity and explanation purposes, the information is described with reference to the data corpus 1200.

[0228] 4. Example operations for deploying artifacts to a cloud environment

[0229] With reference to Figure 13A and 13B example operations 1300 for deploying artifacts to a cloud environment are further described in accordance with one or more embodiments. With reference to Figure 13A and13B One or more operations 1300 described can be modified, combined, rearranged, or omitted. As such, reference Figure 11A and 13B The particular order of operations 1300 described should not be construed as limiting the scope of one or more embodiments. In one example, the operations 1300 can be performed by one or more components of the system described with reference to Figure 13A and 11B The system described with reference to

[0230] A. Example Artifact Deployment Tool Operations

[0231] With reference to Figure 13A example operations 1300 associated with deploying an artifact to a target computing environment are described in accordance with one or more embodiments. In one example, the operations 1300 described with reference to Figure 13A are performed, at least in part, by an artifact deployment tool. Additionally or alternatively, the operations 1300 described with reference to Figure 13A are performed, at least in part, by a validation service that interacts with and / or is incorporated into the artifact deployment tool. In one example, the target computing environment comprises a PLC environment that is accessible using a first set of identity resources associated with a customer and a second set of identity resources associated with a cloud infrastructure provider. In one example, the artifact deployment tool and / or the validation service are operated by a requestor associated with an identity resource of the second set of identity resources.

[0232] As shown in Figure 13B , the system determines that an artifact is available for deployment to a target computing environment (operation 1302). The system can determine that the artifact is available for deployment based on information generated and / or received by the artifact deployment tool. In one example, the artifact deployment tool can receive an indication that the artifact is available for deployment in response to input from a user device interface. Additionally or alternatively, the system can receive a deployment request to deploy the artifact to the target computing environment. The system can determine that the artifact is available for deployment to the target computing environment based on the deployment request.

[0233] The system determines whether deployment of the artifact is conditional on obtaining a deployment token (operation 1304). The system can determine that deployment of the artifact is conditional on obtaining a deployment token based on data associated with the target computing environment and / or data associated with the artifact. Data that the system uses to determine whether deployment of the artifact is conditional on obtaining a deployment token can be located in a data corpus and / or metadata associated with the target computing environment and / or the artifact.

[0234] In one example, the system determines whether deployment of the artifact is conditioned on obtaining a deployment token based on a destination address in the deployment request. Additionally or alternatively, in one example, a deployment request directed to a particular destination address triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request is directed to the particular destination address based on at least the deployment request being directed to the particular destination address, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0235] In one example, the system determines whether deployment of the artifact is conditioned on obtaining a deployment token based on receiving a deployment request as an artifact deployment request. Additionally or alternatively, a deployment request as an artifact deployment request triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request is an artifact deployment request based on at least the deployment request being an artifact deployment request, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0236] In one example, the system can determine whether deployment of the artifact is conditioned on obtaining a deployment token based on the artifact corresponding to the deployment request. Additionally or alternatively, a deployment request associated with a particular artifact triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request corresponds to the particular artifact based on at least the deployment request being directed to the particular artifact, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0237] When the system determines that deployment of the artifact is conditioned on obtaining a deployment token, the system obtains a deployment token that represents verification that the set of one or more customer-specified conditions are satisfied for deploying the artifact to the target computing environment (operation 1306). In one example, prior to obtaining the deployment token, the system determines that the set of one or more customer-specified conditions are satisfied. Additionally or alternatively, the system can receive a token request that includes an indication that the set of one or more customer-specified conditions are satisfied.

[0238] In one example, obtaining the deployment token can include generating the deployment token. In one example, the artifact deployment tool can include a validation service, and the validation service can include a deployment token provisioning module that issues the deployment token. Additionally or alternatively, obtaining the deployment token can include generating a token request and directing the token request to a validation service that includes the deployment token provisioning module and / or an IAM service that issues the deployment token. In one example, the token request includes metadata related to the artifact, and the validation service and / or the IAM service, upon receiving the token request, validates that the set of one or more customer-specified conditions are satisfied based at least in part on the metadata related to the artifact. Upon the validation service successfully validating that the set of one or more customer-specified conditions are satisfied, the validation service generates the deployment token and provides the deployment token to the artifact deployment tool. Upon the IAM service successfully validating that the set of one or more customer-specified conditions are satisfied, the IAM service generates the deployment token and provides the deployment token to the validation service. The validation service can provide the deployment token to the artifact deployment tool. Obtaining the deployment token can include the artifact deployment tool receiving the deployment token in response to the token request.

[0239] Upon obtaining the deployment token, the system generates a deployment request for deploying the artifact to the target computing environment that includes the deployment token (operation 1308). The deployment request can additionally include the artifact to be deployed to the target computing environment. Additionally or alternatively, the deployment request can include a location of the artifact, and a resource corresponding to the target computing environment can retrieve the artifact for deployment in the target computing environment.

[0240] In one example, upon determining that the artifact is available for deployment to the target computing environment, the system can initiate a process of deploying the artifact to the target computing environment. The process can include initiating a validation that the set of one or more customer-specified conditions are satisfied and obtaining a deployment token upon the set of customer-specified conditions being validated as satisfied (operation 1306). The system can pause the process while waiting for the deployment token that represents the validation that the set of one or more customer-specified conditions are satisfied. Upon obtaining the deployment token, the system continues the process. Upon continuing the process, the system generates the deployment request (operation 1308).

[0241] The system can initiate one or more attempts to verify that the set of one or more customer-specified conditions are satisfied, e.g., when obtaining the deployment token (operation 1306). When the set of one or more customer-specified conditions are not satisfied, the system can generate a non-confirmation response indicating that the set of one or more customer-specified conditions are not satisfied. In one example, the verification service generates and transmits the non-confirmation response to the artifact deployment tool. After generating the non-confirmation response, the system can initiate a subsequent attempt to verify that the set of one or more customer-specified conditions are satisfied. In one example, the system can determine that the set of one or more customer-specified conditions are satisfied in response to the subsequent attempt. In one example, the artifact deployment tool can initiate a subsequent token request after receiving the non-confirmation response. The system can obtain the deployment token (operation 1306) based at least in part on the subsequent attempt to verify that the set of one or more customer-specified conditions are satisfied.

[0242] After generating the deployment request, the system directs the deployment request to a destination address for deployment of the artifact to the target computing environment (operation 1310). In one example, the system directs the deployment request to a deployment service for deployment of the artifact to the target computing environment. The deployment service receives the deployment request and the deployment token. In one example, the system directs the deployment request to the destination address, e.g., in the target computing environment, and the deployment service intercepts the deployment request. The deployment service obtains confirmation of the deployment token (operation 1326, Figure 13B ). In one example, the deployment service includes the verification service, and the verification service includes a deployment token confirmation submodule that confirms the deployment token. Additionally or alternatively, the system can include a verification service that interacts with the deployment service, and the deployment service can direct the deployment token to the verification service for confirmation. The verification service can confirm the deployment token and provide an indication to the deployment service that the deployment token has been successfully confirmed.

[0243] In one example, the system can include metadata related to the artifact in the token request. The metadata related to the artifact can be used to verify that the set of one or more customer-specified conditions are satisfied. Additionally or alternatively, the metadata can be used to obtain the deployment token. In one example, obtaining the deployment token can include obtaining the metadata related to the artifact, e.g., from a data corpus and / or metadata file associated with the artifact, and including the metadata related to the artifact in the token request. Upon receiving the token request, the system can verify that the set of one or more customer-specified conditions are satisfied, and in response to verifying that the set of one or more customer-specified conditions are satisfied, the system obtains the deployment token.

[0244] Upon successfully obtaining confirmation of the deployment token, the deployment service directs the deployment request and / or the artifact to the destination address in the target computing environment for deployment (operation 1328, Figure 13B). In one example, a resource in the target computing environment receives the deployment request and validates the deployment token included in the deployment request. In response to successfully validating the deployment token, the resource deploys the artifact in the target computing environment. The resource can receive the artifact for deployment with the deployment request, and / or can retrieve the artifact from a location indicated by the deployment request.

[0245] Referring again to operation 1304 and operation 1310, when the system determines that deployment of the artifact is not conditioned on obtaining a deployment token, the system directs the deployment request to a deployment service for deploying the artifact to the target computing environment. The deployment service receives the request and directs the deployment request and / or the artifact to the target computing environment for deployment.

[0246] B. Example Deployment Service Operations

[0247] Referring to Figure 13B , example operations 1300 are described in accordance with one or more embodiments associated with utilizing a deployment service and / or a validation service to deploy an artifact to a target computing environment. In one example, referring to Figure 13B , the operations 1300 described are performed at least in part by a deployment service. The deployment service can be configured to route requests to a destination address in a target computing environment. Additionally or alternatively, referring to Figure 13B , the operations 1300 described are performed at least in part by a validation service that interacts with and / or is incorporated into the deployment service. In one example, the target computing environment includes a PLC environment that is accessible using a first set of identity resources associated with a customer and a second set of identity resources associated with a cloud infrastructure provider. In one example, the deployment service and / or the validation service are operated by a requestor associated with an identity resource in the second set of identity resources.

[0248] As shown in Figures 15A-15C , the system detects a request to deploy an artifact to a target computing environment (operation 1320). In one example, the system detects the request at least in part by receiving a deployment request to deploy an artifact to a target computing environment. Additionally or alternatively, the system can detect the deployment request at least in part by receiving a token request to obtain a deployment token for deploying an artifact to a target computing environment. The deployment request can include an artifact to be deployed to the target computing environment. Additionally or alternatively, the deployment request can include a location of the artifact, and the system can retrieve the artifact for deployment in the target computing environment.

[0249] In response to detecting the deployment request, the system determines whether deployment of the artifact is conditioned on obtaining a deployment token (operation 1322). The system can determine that deployment of the artifact is conditioned on obtaining a deployment token based on data included in the deployment request. Additionally or alternatively, the system can determine that deployment of the artifact is conditioned on obtaining a deployment token based on data associated with the target computing environment and / or based on data associated with the artifact. In one example, the system determines that deployment of the artifact to the target computing environment is conditioned on having a valid deployment token based on a set of one or more attributes of the target computing environment. Data that the system uses to determine whether deployment of the artifact is conditioned on obtaining a deployment token can be located in a data corpus and / or metadata associated with the target computing environment and / or the artifact. Additionally or alternatively, the system can receive a token request, and the system can determine that deployment of the artifact is conditioned on obtaining a deployment token based on the token request.

[0250] In one example, the system determines whether deployment of the artifact is conditioned on obtaining a deployment token based on a destination address in the deployment request. Additionally or alternatively, in one example, a deployment request that is directed to a particular destination address triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request is directed to the particular destination address based on at least the deployment request being directed to the particular destination address, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0251] In one example, the system determines whether deployment of the artifact is conditioned on obtaining a deployment token based on receiving the deployment request as an artifact deployment request. Additionally or alternatively, a deployment request that is an artifact deployment request triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request is an artifact deployment request based on at least the deployment request being an artifact deployment request, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0252] In one example, the system can determine whether deployment of the artifact corresponding to the deployment request is conditioned on obtaining a deployment token based on the artifact. Additionally or alternatively, a deployment request associated with a particular artifact triggers the system to initiate processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied. When the system determines that the deployment request corresponds to the particular artifact based on at least the deployment request being directed to the particular artifact, the system initiates processes for obtaining a deployment token and / or for verifying that the set of one or more customer-specified conditions are satisfied.

[0253] When the system determines that deployment of the artifact is conditioned on obtaining a deployment token, the system obtains a deployment token that represents verification that the set of one or more customer-specified conditions for deployment of the artifact to the target computing environment are satisfied (operation 1324). In one example, the system determines that the set of one or more customer-specified conditions are satisfied prior to obtaining the deployment token. Additionally or alternatively, the system can receive a token request that includes an indication that the set of one or more customer-specified conditions are satisfied. In one example, obtaining the deployment token can include receiving the deployment token with the deployment request. Additionally or alternatively, obtaining the deployment token can include issuing the deployment token. In one example, the deployment service can include a verification service, and the verification service can include a deployment token provisioning module that issues the deployment token. Additionally or alternatively, obtaining the deployment token can include generating the token request and directing the token request to a verification service that includes the deployment token provisioning module and / or an IAM service that issues the deployment token. Obtaining the deployment token can include receiving the deployment token in response to the token request.

[0254] In one example, the system can include metadata related to the artifact in the token request. The metadata related to the artifact can be used to verify that the set of one or more customer-specified conditions are satisfied. Additionally or alternatively, the metadata can be used to generate the deployment token. In one example, obtaining the deployment token can include obtaining the metadata related to the artifact from the deployment request and including the metadata related to the artifact in the token request. Upon receiving the token request, the system can verify that the set of one or more customer-specified conditions are satisfied, and in response to verifying that the set of one or more customer-specified conditions are satisfied, the system obtains the deployment token.

[0255] Upon obtaining the deployment token, the system determines whether the deployment token is valid (operation 1326). In one example, the deployment service includes a verification service, and the verification service includes a deployment token validation submodule that validates the deployment token. Additionally or alternatively, the system can include a verification service that interacts with the deployment service, and the deployment service can direct the deployment token to the verification service for validation. The verification service can validate the deployment token and provide an indication to the deployment service that the deployment token has been successfully validated.

[0256] Upon successfully obtaining validation of the deployment token, the system directs the deployment request and / or the artifact to a destination address in the target computing environment (operation 1328). In one example, a resource in the target computing environment receives the deployment request and validates the deployment token included in the deployment request. In response to successfully validating the deployment token, the resource deploys the artifact in the target computing environment. The resource can receive the artifact for deployment with the deployment request, and / or can retrieve the artifact from a location indicated by the deployment request.

[0257] Referring again to operation 1322 and operation 1328, when the system determines that deployment of the artifact is conditioned on obtaining a deployment token, the system directs the deployment request and / or the artifact to the destination address in the target computing environment for deployment.

[0258] Referring again to operation 1326, when the system determines that the deployment token is invalid, the system can obtain a new deployment token (operation 1324). In one example, the system can generate a notification indicating that the deployment token is invalid. The system can obtain a new deployment token (operation 1324) in response to the notification.

[0259] In one example, the system can determine that the set of one or more customer-specified conditions are not satisfied when obtaining the deployment token (operation 1326). In response to determining that the set of one or more customer-specified conditions are not satisfied, the system refrains from directing the artifact to the target computing environment. In one example, in response to determining that the set of one or more customer-specified conditions are not satisfied, the system generates a non-confirmation response indicating that the set of one or more customer-specified conditions are not satisfied. The system can direct the non-confirmation response to the artifact deployment tool. After directing the non-confirmation response to the artifact deployment tool, the system can receive another deployment request for deployment of the artifact to the target computing environment (operation 1320). The system can obtain the deployment token (operation 1324) in response to a subsequent attempt to obtain a validation token and / or validate that the set of one or more customer-specified conditions are satisfied. The system can obtain confirmation of the deployment token (operation 1326), and in response to successfully obtaining confirmation of the second deployment token, the system can direct the artifact to the destination address in the target computing environment (operation 1328). The artifact is received at the destination address and deployed into the target computing environment.

[0260] In one example, after determining that deployment of the artifact is conditioned on obtaining a deployment token (operation 1322), the system initiates a process for validating that the set of one or more customer-specified conditions are satisfied. The process can include queuing the deployment request while waiting for the deployment token (operation 1324). When the system receives the deployment token, the system continues the process. After receiving the deployment token, the process includes obtaining confirmation of the deployment token (operation 1326) and directing the deployment request and / or the artifact to the destination address in the target computing environment (operation 1328).

[0261] 5. Example Embodiments

[0262] Referring to FIGS. 14-14C, Figures 16A-16C , Figures 17A-17C and Figure 14A , example features and operations of a system for deploying artifacts to a cloud environment are further described in accordance with one or more embodiments. Referring to Figure 15A , Figure 16A ,Figure 17A and Figure 14A The described embodiments include features for verifying conditions for deploying an artifact to a target computing environment, and features for obtaining a verification token indicating that the conditions for deploying the artifact to the target computing environment have been met. (Reference) Figure 15A , Figure 16A , Figure 17A and Figure 11A The described embodiments may include references Figure 14B and 11B One or more characteristics described.

[0263] refer to Figure 15B and 14C , Figure 16B and 15C , Figure 17B and 16C as well as Figure 14B and 17C The described embodiments include operations related to verifying the conditions for deploying the artifact to the target computing environment, and operations related to a confirmation token indicating that the conditions for deploying the artifact to the target computing environment have been met. (See reference) Figure 15B and 14C , Figure 16B and 15C , Figure 17B and 16C as well as Figure 13A and 17C Implementation examples may include references Figure 14A and 13B One or more operations described.

[0264] A. Deploying verification tools includes verification services.

[0265] i. Example system components

[0266] refer to Figure 14A A system 1400 for deploying artifacts to a target computing environment is further described according to one or more embodiments. Figure 14A As shown, system 1400 includes a verification service incorporated into a deployment verification tool for deploying artifacts to a target computing environment. In one or more embodiments, system 1400 may include a reference... Figure 14A The number of components described may be more or less. (Reference) Figure 14A The components described can be located locally or remotely. References Figure 14A The described components can be implemented using software and / or hardware. The components of System 1400 can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. An operation described for one component can be performed by another component.

[0267] likeFigure 14B As shown in FIG. 69, the system 1400 includes a virtual cloud network 1402 in which a set of partitions 1404 are deployed. The partition 1404a can be assigned to a cloud infrastructure provider. The partition 1404n can be assigned to a PLC operator or customer. The partition 1404a includes a artifact deployment tool 1406 and a data corpus 1408. The artifact deployment tool 1406 includes a validation service 1410. The partition 1404n includes a deployment service 1412 and at least one target computing environment 1414. The data corpus 1408 can include one or more artifacts 1416, such as artifact 1416a and artifact 1416n. Additionally or alternatively, the data corpus 1408 can include validation data 1418. The validation data 1418 can indicate whether a customer-specified condition for deploying the artifact 1416 to the target computing environment 1414 is satisfied. Additionally or alternatively, the data corpus 1408 can include one or more deployment tokens 1420 representing a validation that the customer-specified condition is satisfied.

[0268] ii. Example Operations

[0269] Reference Figure 14B and 14C Example operations 1450 for deploying an artifact to a cloud environment are further described with reference to one or more embodiments. Reference is made to Figure 14B and 14C One or more of the operations 1450 described with reference to Figure 14A and 14C The particular order of operations 1450 described with reference to Figure 14B should not be construed as limiting the scope of one or more embodiments. In one example, the operations 1450 can be performed by one or more components of the system described with reference to

[0270] As Figure 14CAs shown, the artifact deployment tool 1406 determines that an artifact is available for deployment to the target computing environment 1414 (operation 1452). The verification service 1410, incorporated into the artifact deployment tool 1406, determines that the deployment of the artifact is conditional upon obtaining a deployment token (operation 1454). In response to determining that the deployment of the artifact is conditional upon obtaining a deployment token, the verification service 1410 determines that the customer-specified condition is met (operation 1456). In response to determining that the customer-specified condition is met, the verification service 1410 obtains a deployment token (operation 1458). The verification service 1410 may obtain the deployment token from the IAM service, and / or the verification service 1410 may issue the deployment token. After obtaining the deployment token, the artifact deployment tool 1406 generates a deployment request to deploy the artifact to the target computing environment 1414 (operation 1460). The deployment request may include a deployment token and an artifact. The artifact deployment tool 1406 directs the deployment request, for example, including a deployment token and an artifact, to the deployment service 1412 (operation 1462).

[0271] refer to Figure 15A Deployment service 1412 confirms the deployment token corresponding to the deployment request and / or the artifact used for deployment to the target computing environment 1414 (operation 1464). In response to successful confirmation of the deployment token, deployment service 1412 directs a deployment request, including, for example, the deployment token and the artifact, to the target computing environment 1414 (operation 1466). Target computing environment 1414 confirms the deployment token corresponding to the deployment request and / or the artifact (operation 1468). In response to successful confirmation of the deployment token, target computing environment 1414 deploys the artifact (operation 1470).

[0272] B. Deployment of verification tools and interaction with verification services

[0273] i. Example system components

[0274] refer to Figure 15A A system 1500 for deploying artifacts to a target computing environment is further described according to one or more embodiments. Figure 15A As shown, system 1500 includes deployment verification tools that interact with a verification service to deploy artifacts to a target computing environment. In one or more embodiments, system 1500 may include a reference... Figure 15A The number of components described may be more or less. (Reference) Figure 15A The components described can be located locally or remotely. References Figure 15A The described components can be implemented using software and / or hardware. The components of System 1500 can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. An operation described for one component can be performed by another component.

[0275] likeFigure 15B As shown in FIG. 15, system 1500 includes a virtual cloud network 1502 in which a set of partitions 1504 are deployed. Partition 1504a can be assigned to a cloud infrastructure provider. Partition 1504n can be assigned to a PLC operator or customer. Partition 1504a includes artifact deployment tool 1506, data corpus 1508, and validation service 1510. Artifact deployment tool 1506 and validation service 1510 can be separate services deployed in partition 1504a. Partition 1504n includes deployment service 1512 and at least one target computing environment 1514. Data corpus 1508 can include one or more artifacts 1516, such as artifact 1516a and artifact 1516n. Additionally or alternatively, data corpus 1508 can include validation data 1518. Validation data 1518 can indicate whether a customer-specified condition for deployment of artifact 1516 to target computing environment 1514 is satisfied. Additionally or alternatively, data corpus 1508 can include one or more deployment tokens 1520 representing validation that a customer-specified condition is satisfied.

[0276] ii. Example Operations

[0277] Reference Figure 15B and 15C Example operations 1550 for deploying an artifact to a cloud environment are further described with reference to one or more embodiments. Reference is made to Figure 15B and 15C One or more of operations 1550 described with reference to Figure 15A and 15C The particular order of operations 1550 described with reference to Figure 15B may be modified, combined, rearranged or omitted. As such, those having ordinary skill in the art will appreciate that the particular order of operations 1550 described with reference to

[0278] As shown in Figure 15C , artifact deployment tool 1506 determines that an artifact is available for deployment to target computing environment 1514 (operation 1552). Artifact deployment tool 1506 determines that deployment of the artifact is conditioned on obtaining a deployment token (operation 1554). In response to determining that deployment of the artifact is conditioned on obtaining a deployment token, artifact deployment tool 1506 generates a token request (operation 1556). The token request includes metadata associated with the artifact to be deployed to target computing environment 1514. Artifact deployment tool 1506 directs the token request to validation service 1510 (operation 1558).

[0279] The validation service 1510 determines that the customer-specified condition is satisfied (operation 1560). The validation service 1510 can determine that the customer-specified condition is satisfied based at least in part on the metadata included in the token request and / or based at least in part on the validation data stored in the data corpus. In one example, the validation service 1510 identifies the customer-specified condition in the data corpus based on the metadata included in the deployment token. Upon identifying the customer-specified condition, the validation service 1510 determines that the customer-specified condition is satisfied. In response to determining that the customer-specified condition is satisfied, the validation service 1510 obtains the deployment token (operation 1562). The validation service 1510 can obtain the deployment token from the IAM service and / or the validation service 1510 can emit the deployment token. Upon obtaining the deployment token, the validation service 1510 directs the deployment token to the artifact deployment tool 1506 (operation 1564).

[0280] Referring to Figure 16A , the artifact deployment tool 1506 generates a deployment request for deploying the artifact to the target computing environment 1514 (operation 1566). The deployment request can include the deployment token and the artifact. The artifact deployment tool 1506 directs the deployment request, e.g., including the deployment token and the artifact, to the deployment service 1512 (operation 1568). The deployment service 1512 validates the deployment token corresponding to the deployment request and / or the artifact for deployment to the target computing environment 1514 (operation 1570). In response to successfully validating the deployment token, the deployment service 1512 directs the deployment request, e.g., including the deployment token and the artifact, to the target computing environment 1514 (operation 1572). The target computing environment 1514 validates the deployment token corresponding to the deployment request and / or the artifact (operation 1574). In response to successfully validating the deployment token, the target computing environment 1514 deploys the artifact (operation 1576).

[0281] C. Deployment service includes validation service

[0282] i. Example system components

[0283] Referring to Figure 16A , a system 1600 for deploying an artifact to a target computing environment is further described in accordance with one or more embodiments. As shown in Figure 16A , the system 1600 includes a validation service incorporated into a deployment service for deploying an artifact to a target computing environment. In one or more embodiments, the system 1600 can include more or fewer components than those shown in Figure 16A Referring to Figure 16A , the components described with reference to Figure 16AThe described components can be implemented in software and / or hardware. The components of system 1600 can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. Operations described with respect to one component can be performed by another component.

[0284] As Figure 16B shown in FIG. 16, system 1600 includes a virtual cloud network 1602 in which a set of partitions 1604 are deployed. Partition 1604a can be assigned to a cloud infrastructure provider. Partition 1604n can be assigned to a PLC operator or customer. Partition 1604a includes artifact deployment tool 1606 and data corpus 1608a. Partition 1604n includes deployment service 1610, data corpus 1608n, and at least one target computing environment 1612. Deployment service 1610 includes validation service 1614. Data corpus 1608a of partition 1604a can include one or more artifacts 1616, such as artifact 1616a and artifact 1616n. Data corpus 1608n of partition 1604n can include validation data 1618. Validation data 1618 can indicate whether a customer-specified condition for deploying artifact 1616 to target computing environment 1612 is satisfied. Additionally or alternatively, data corpus 1608n of partition 1604n can include one or more deployment tokens 1620 representing validation that a customer-specified condition is satisfied.

[0285] ii. Example Operations

[0286] With reference to Figure 16B and 16C , example operations 1650 for deploying an artifact to a cloud environment are further described in accordance with one or more embodiments. With reference to Figure 16B and 16C one or more operations 1650 can be modified, combined, rearranged, or omitted. As such, a particular order of operations 1650 as described with reference to Figure 16A and 16C should not be construed as limiting the scope of one or more embodiments. In one example, operations 1650 can be performed by one or more components of a system described with reference to Figure 16B .

[0287] As Figure 16CAs shown, artifact deployment tool 1606 determines that an artifact is available for deployment to target computing environment 1612 (operation 1652). Artifact deployment tool 1606 generates a deployment request for deploying the artifact to target computing environment 1612 (operation 1654). The deployment request may include the artifact. Artifact deployment tool 1606 directs the deployment request, including, for example, the artifact, to deployment service 1610 (operation 1656). Verification service 1614, incorporated into deployment service 1610, determines that the deployment of the artifact is conditional upon obtaining a deployment token (operation 1658). In response to determining that the deployment of the artifact is conditional upon obtaining a deployment token, verification service 1614 determines that the customer-specified condition is met (operation 1660). In response to determining that the customer-specified condition is met, verification service 1614 obtains a deployment token (operation 1662). Verification service 1614 may obtain a deployment token from IAM service, and / or verification service 1614 may issue a deployment token.

[0288] refer to Figure 17A Upon obtaining the deployment token, deployment service 1610 directs the deployment request (e.g., including the artifact) and the deployment token to target computing environment 1612 (operation 1664). Target computing environment 1612 confirms the deployment token corresponding to the deployment request and / or artifact (operation 1666). In response to successful confirmation of the deployment token, target computing environment 1612 deploys the artifact (operation 1668).

[0289] D. Interaction between deployment service and verification service

[0290] i. Example system components

[0291] refer to Figure 17A A system 1700 for deploying artifacts to a target computing environment is further described according to one or more embodiments. Figure 17A As shown, system 1700 includes deployment verification tools that interact with a deployment service for deploying artifacts to a target computing environment. In one or more embodiments, system 1700 may include a reference... Figure 17A The number of components described may be more or less. (Reference) Figure 17A The components described can be located locally or remotely. References Figure 17A The described components can be implemented using software and / or hardware. System 1700 components can be distributed across multiple applications and / or machines. Multiple components can be combined into a single application and / or machine. Operations described for one component can be performed by another component.

[0292] like Figure 17BAs shown in FIG. 17, system 1700 includes a virtual cloud network 1702 in which a set of partitions 1704 are deployed. Partition 1704a can be assigned to a cloud infrastructure provider. Partition 1704n can be assigned to a PLC operator or customer. Partition 1704a includes artifact deployment tool 1706 and data corpus 1708a. Partition 1704n includes data corpus 1708n, deployment service 1710, at least one target computing environment 1712, and validation service 1714. Deployment service 1710 and validation service 1714 can be separate services deployed in partition 1704n. Data corpus 1708a of partition 1704a can include one or more artifacts 1716, such as artifact 1716a and artifact 1716n. Data corpus 1708n of partition 1704n can include validation data 1718. Validation data 1718 can indicate whether a customer-specified condition for deploying artifact 1716 to target computing environment 1712 is satisfied. Additionally or alternatively, data corpus 1708n of partition 1704n can include one or more deployment tokens 1720 representing validation that a customer-specified condition is satisfied.

[0293] ii. Example Operations

[0294] Reference Figure 17B and 17C Example operations 1750 for deploying an artifact to a cloud environment are further described in accordance with one or more embodiments. Reference is made to Figure 17B and 17C One or more of operations 1750 described with reference to Figure 17A and 17C The particular order of operations 1750 described with reference to Figure 17B should not be construed as limiting the scope of one or more embodiments. In one example, operations 1750 can be performed by one or more components of the system described with reference to

[0295] As shown in Figure 17C Artifact deployment tool 1706 determines that an artifact is available for deployment to target computing environment 1712 (operation 1752). Artifact deployment tool 1706 generates a deployment request for deploying the artifact to target computing environment 1612 (operation 1754). The deployment request can include the artifact. Artifact deployment tool 1606 directs the deployment request including the artifact to deployment service 1710 (operation 1756).

[0296] The deployment service 1710 determines that deployment of the artifact is conditioned on obtaining a deployment token (operation 1758). In response to determining that deployment of the artifact is conditioned on obtaining a deployment token, the deployment service 1710 generates a token request (operation 1760). The token request includes metadata associated with the artifact to be deployed to the target computing environment 1712. The deployment service 1710 directs the token request to the validation service 1714 (operation 1762).

[0297] Reference ​ The validation service 1714 determines that the customer-specified condition is satisfied (operation 1764). The validation service 1714 can determine that the customer-specified condition is satisfied based at least in part on the metadata included in the token request and / or based at least in part on validation data stored in a data corpus. In one example, the validation service 1714 identifies the customer-specified condition in the data corpus based on the metadata included in the deployment token. Upon identifying the customer-specified condition, the validation service 1714 determines that the customer-specified condition is satisfied. In response to determining that the customer-specified condition is satisfied, the validation service 1714 obtains the deployment token (operation 1766). The validation service 1714 can obtain the deployment token from an IAM service and / or the validation service 1714 can issue the deployment token. Upon obtaining the deployment token, the validation service 1714 directs the deployment token to the deployment service 1710 (operation 1768). Upon obtaining the deployment token, the deployment service 1710 directs the deployment request (e.g., including the artifact) and the deployment token to the target computing environment 1712 (operation 1770). The target computing environment 1712 validates the deployment token corresponding to the deployment request and / or the artifact (operation 1772). In response to successfully validating the deployment token, the target computing environment 1712 deploys the artifact (operation 1774).

[0298] 6. Other matters; extensions

[0299] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meaning to one of ordinary skill in the art, and are not to be limited to a special or customized meaning, unless otherwise expressly so defined herein.

[0300] This application can include references to certain trademarks. While it is possible to use trademarks in patent applications, the use of a trademark can not be necessary in a patent application and it is not intended that the disclosure be limited to the products of any one company, nor is it intended that the disclosure be limited in any way by the terminology used. It is intended that only those products that actually or equivalently perform the functions recited in the claims should be included within the scope of the disclosure.

[0301] Embodiments are directed to a system with one or more devices that include hardware processors and are configured to perform any of the operations described herein and / or recited in any of the claims below.

[0302] In an embodiment, one or more non-transitory computer-readable storage media include instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or recited in any of the claims.

[0303] In an embodiment, a method includes the operations described herein and / or recited in any of the claims, the method performed by at least one device comprising a hardware processor.

[0304] Any combination of the features and functionality described herein can be used according to one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that can vary from implementation to implementation. Thus, the specification and drawings should be regarded as illustrative rather than restrictive. The sole and exclusive metric for determining the scope of the disclosure, and the extent of the disclosure's disclosure content, is the literal and equivalent range of the claims issued from the application, in whatever form they can be issued, including any subsequent amendments, revisions, equivalents, rulings, interpretations, rulings by administrative or judicial authorities and / or equivalents.

Claims

1. A method comprising: The artifact deployment tool determines which artifact is available for deployment to the target computing environment; The artifact deployment tool obtains a first deployment token, which represents the verification that a first set of one or more customer-specified conditions for deploying the first artifact to the target computing environment are met. The artifact deployment tool generates a first deployment request for deploying a first artifact to a target computing environment, wherein the first deployment request includes a first deployment token; The artifact deployment tool directs the first deployment request to a deployment service for deploying the artifact to the target computing environment, wherein the deployment service receives confirmation of the first deployment token and, in response to receiving confirmation of the first deployment token, deploys the first artifact to the target computing environment. The method is performed by at least one device including a hardware processor.

2. The method as described in claim 1, The target computing environment includes a privately tagged cloud environment accessible using a first set of identity resources associated with the customer and a second set of identity resources associated with the cloud infrastructure provider. The artifact deployment tool is operated by the requester associated with the identity resources in the second set of identity resources.

3. The method of claim 1, wherein the conditions specified by the first group of one or more customers include: Verification confirms that approval has been obtained for deploying the first artifact to the target computing environment, which is associated with a customer-defined approval workflow.

4. The method of claim 1, wherein the artifact deployment tool is configured to: (a) determine that approval has been obtained for deploying a first artifact to a target computing environment in association with a customer-defined approval workflow, and (b) obtain a first deployment token based at least on said approval.

5. The method of claim 4, wherein (i) the artifact deployment tool generates a first deployment token, or (ii) the identity service generates a first deployment token and the artifact deployment tool obtains the first deployment token from the identity service.

6. The method of claim 1, wherein the conditions specified by the first group of one or more customers include: Verify that one or more deployment states of the target computing environment specified by the customer are satisfied.

7. The method of claim 6, wherein the set of one or more deployment states of the target computing environment includes: The deployment time for deploying the first artifact to the target computing environment is within a time window specified by at least one of the following: the customer, or the provider of the cloud infrastructure for the target computing environment.

8. The method of claim 6, wherein verifying that the set of one or more deployment states of the target computing environment are satisfied includes: Verify that the deployment of the first artifact to the target computing environment corresponds to the deployment order specified by the customer for deployment to the target computing environment.

9. The method of claim 1, wherein the conditions specified by the first group of one or more customers include: Verify that the change ticket associated with deploying the first artifact to the target computing environment meets one or more set of ticket verification criteria.

10. The method of claim 9, The artifact deployment tool selects one or more of the set of ticket verification criteria based on the source of the changed ticket. The source may include one: a first source identifiable by a first identity resource associated with the customer, or a second source identifiable by a second identity resource associated with a provider of cloud infrastructure corresponding to the target computing environment.

11. The method of claim 9, wherein the set of one or more ticket verification criteria includes at least one of the following: The ticket change is valid; The change to the ticket was approved; or The current execution time is within the approval change window for the changed ticket.

12. The method of claim 1, wherein obtaining the first deployment token comprises: The token request used to obtain the first deployment token is directed to the verification service, wherein the token request includes metadata related to the first artifact; The verification service (a) receives a token request, (b) verifies, at least in part, based on metadata associated with the first artifact, that one or more customer-specified conditions of the first group are met, (c) obtains a first deployment token, and (d) provides the first deployment token to the artifact deployment tool.

13. The method of claim 12, wherein the verification service verifies at least one of the following: Approval has been obtained for deploying the first artifact to the target computing environment, which is associated with a customer-defined approval workflow; One or more deployment states of the target computing environment specified by the customer are satisfied; or The change ticket associated with deploying the first artifact to the target computing environment meets one or more sets of ticket validation criteria.

14. The method of claim 12, wherein (a) the verification service generates a first deployment token, or (b) the identity service generates a first deployment token and the verification service obtains the first deployment token from the identity service.

15. The method of claim 1, wherein the artifact deployment tool comprises at least one of the following: a configuration deployment tool, a maintenance management tool, an administrator tool, or a command-line interface.

16. The method of claim 1, further comprising: After determining that the first artifact is available for deployment to the target computing environment: Initiate a process to deploy the first artifact to the target computing environment, wherein the process includes: Initiate verification that the conditions specified by one or more customers in the first group are met; The process is paused while awaiting a first deployment token indicating that the conditions specified by one or more customers in the first group have been met. After obtaining the first deployment token, the process continues, wherein the process further includes: After continuing the aforementioned processing: a first deployment request is generated and directed to the deployment service.

17. The method of claim 1, wherein obtaining the first deployment token comprises: Initiate the first attempt to verify that the conditions specified by one or more customers in the first group are met; Receive a non-acknowledgment response indicating that the conditions specified by one or more customers in the first group have not been met; Upon receiving a non-acknowledgment response, initiate a second attempt to verify that the conditions specified by one or more customers in the first group have been met; In response to the second attempt, the first deployment token is received.

18. The method of claim 1, further comprising: The artifact deployment tool determines whether the second artifact can be deployed to the target computing environment; A second deployment token is obtained from the artifact deployment tool. The second deployment token represents the verification that a second set of one or more customer-specified conditions for deploying the second artifact to the target computing environment are met. The artifact deployment tool generates a second deployment request for deploying the second artifact to the target computing environment, wherein the second deployment request includes a second deployment token; The artifact deployment tool directs the second deployment request to the deployment service, where the deployment service confirms the second deployment token and, in response to the confirmation of the second deployment token, deploys the second artifact to the target computing environment. The conditions specified by one or more customers in the second group are different from those specified by one or more customers in the first group.

19. One or more non-transitory computer-readable media storing instructions that, when executed by one or more hardware processors, cause to perform the operation as described in any one of claims 1-18.

20. A system comprising: At least one device including a hardware processor; The system is configured to perform the operations described in any one of claims 1-18.

21. A system comprising components for performing the operations as described in any one of claims 1-18.

Images