Triggering event in response to operability of threat cloud infrastructure

Abstract

Techniques are disclosed for responding to a trigger event that threatens operability of at least a portion of a cloud infrastructure of a cloud environment. In response to detecting the occurrence of the trigger event, the system performs a mitigation process to mitigate the impact of the trigger event. The mitigation process includes determining a set of candidate services as candidates for stopping performing operations in the cloud environment. In addition, the mitigation process generates a ranking for the set of candidate services based on weighting metrics associated with respective service characteristics of the set of candidate services. Further, based on the ranking, the mitigation process selects a service from the set of candidate services and stops performing the operation of the service to at least partially mitigate the impact of the trigger event.

Description

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

[0002] This application claims priority to the following U.S. provisional patent applications, which are hereby incorporated by reference: U.S. Provisional Patent Application Serial No. 63 / 462,875, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 503,143, filed May 18, 2023, entitled “TECHNIQUES FOR VALIDATING AND TRACKING REGION BUILD SKILLS”; and U.S. Non-Provisional Patent Application No. 18 / 647,971, filed April 26, 2024, entitled “RESPONDING TO TRIGGER EVENTS THAT THREATEN ANOPERABILITY OF A CLOUD INSFRACTRUCTURE”.

[0003] The following U.S. patent applications are hereby incorporated herein by reference: U.S. Patent Application Serial Nos. 18 / 647,735 and 18 / 647,741, filed April 26, 2024, entitled “HEALTH METRICS ASSOCIATED WITH CLOUD SERVICES”; U.S. Patent Application Serial No. 18 / 647,893, filed April 26, 2024, entitled “MANAGING RESOURCE CONSTRAINTS INA CLOUD ENVIRONMENT”; U.S. Patent Application Serial No. 18 / 498,964, filed October 31, 2023, entitled “SKILLS SERVICE CONFIGURED TO MANAGE ASPECTS OF A BUILDING A DATA CENTER”; and U.S. Patent Application Serial No. 18 / 498,964, filed November 27, 2023, entitled “TRACKING DATACENTER BUILD DEPENDENCIES WITH CAPABILITIES AND U.S. Patent Application Serial No. 18 / 520,103, entitled “SKILLS”; and U.S. Patent Application Serial No. 18 / 537,902, entitled “TRACKING DATA CENTER BUILDHEALTH”, filed on December 13, 2023.

[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 environments. More specifically, this disclosure relates to systems and methods for triggering events that threaten the operability of cloud infrastructure. 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 leverage various technologies to monitor the operation and performance of their cloud environments. Cloud operators can monitor the operation and performance of their cloud environments to gain insights into system health, detect operational problems, optimize resource allocation or utilization, and respond to potential issues.

[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. Attached Figure Description

[0009] In the accompanying drawings, embodiments are illustrated by way of example rather than limitation. It should be noted that references to "a" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment, and they mean at least one. In the drawings:

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

[0011] Figure 2 The illustration further illustrates how a cloud infrastructure environment can be used to provide cloud-based applications or services according to embodiments.

[0012] Figure 3 The illustration shows an example cloud infrastructure architecture according to an embodiment.

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

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

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

[0016] Figure 7 The illustration shows how a system according to an embodiment can provide a dedicated or private tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0017] Figure 8 The illustration further illustrates the use of a private tag cloud domain for tenants or customers in a cloud infrastructure environment, according to an embodiment.

[0018] Figure 9 The illustration further illustrates the use of a private tag cloud domain for tenants or customers in a cloud infrastructure environment, according to an embodiment.

[0019] Figure 10 The illustration depicts a system according to an embodiment for providing access to software products or services in a cloud computing or other computing environment.

[0020] Figure 11A-11C The illustration depicts features of a system including a cloud infrastructure protection utility according to one or more embodiments.

[0021] Figure 12A The illustration shows an example mapping of services to service features according to one or more embodiments.

[0022] Figure 12B and 12C An example dependency graph illustrating dependencies between service features according to one or more embodiments is shown.

[0023] Figure 13A and 13B The illustration shows an example weighted metric for a service of a system according to one or more embodiments.

[0024] Figure 14A and 14B The illustration depicts example operations for protecting cloud infrastructure from triggering events that threaten the operability of the cloud infrastructure, according to one or more embodiments.

[0025] Figure 15 The illustration shows an example event mitigation interface for triggering events of a cloud infrastructure for responding to threat systems, according to one or more embodiments. Detailed Implementation

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

[0027] 1. General Overview

[0028] 2. Example Cloud Environment

[0029] 3. System architecture for cloud infrastructure protection

[0030] 4. Example Weighted Metric

[0031] 5. Example Operations for Cloud Infrastructure Protection

[0032] 6. Example event mitigation interface

[0033] 7. Other matters; extension

[0034] 1. General Overview

[0035] One or more embodiments mitigate triggering events by performing mitigation processes to mitigate the impact of the triggering event that threatens the operability of cloud infrastructure. In one example, the system performs mitigation processes that include stopping the execution of one or more services selected from a ranking of candidate services in the cloud environment to at least partially mitigate the impact of the triggering event. The candidate services are ranked based on a weighted metric reflecting the value of individual service characteristics of the candidate services. In one example, the triggering event includes a large-scale event with a wide-ranging impact on the cloud infrastructure, such as a widespread service outage associated with overheating of cloud infrastructure components due to a heatwave. When a cloud infrastructure component overheats, the component's temperature is related to the utilization load of the services executing in the cloud environment on the cloud infrastructure. By stopping the execution of services in the cloud environment, the triggering event is at least partially mitigated by reducing the utilization load on the cloud infrastructure.

[0036] In one example, the system determines the weight metric of a candidate service based on the weights assigned to each service feature. The weight assigned to a service feature can represent the value of that service feature within a given context. Therefore, the weighted metric for a particular service represents the combination of the values ​​of the individual service features of that particular service. Additionally or alternatively, the system can determine the weight of a particular service feature based on its influence on one or more downstream service features. A service feature can have a relatively high weight when it influences a large number of downstream service features and / or when it influences a downstream service feature that itself has a relatively high weight.

[0037] In one example, a user (such as a private or private tag cloud (PLC) operator or customer) assigns weights to service characteristics of various services deployed in partitions of a cloud environment assigned to the entity represented by that user. The user-assigned weights can represent the relative value of the service characteristics relative to the entity, for example, within the context of operations performed in the partitions of the cloud environment and / or the context of business activities that depend on operations performed in the partitions of the cloud environment. As with different partitions of the cloud environment, different instances of a particular service deployed in their respective partitions may have different values. Therefore, the system can determine which services to stop for a particular partition, at least in part, based on the value of the service relative to that partition. In one example, the system mitigates the triggering event at least in part by stopping services with relatively low values, as indicated by the weighted metrics of the various services.

[0038] In one example, a weighted metric for a service can represent the health of that service. The system can determine the health of a service based on a mapping between the service and one or more service characteristics associated with that service and the detected alert. Additionally or alternatively, the system can determine the health of a service based on the impact of its service characteristics on downstream service characteristics. Therefore, the system can determine which services to stop for a particular partition based at least in part on the health of the services relative to that partition. In one example, the system at least partially mitigates the triggering event by stopping services with relatively low health, as indicated by the weighted metrics of the individual services.

[0039] In one example, a weighted metric for a service can represent a combination of the service's relative value and its health. The system can determine the relative value of each service characteristic and the health metric for each service characteristic. In one example, the system mitigates the triggering event at least in part by suspending service based on a combination of service value and health as indicated by the weighted metrics of the individual services. In one example, the system can suspend service based on a ranking reflecting one or more of the following: relatively low value and relatively low health, relatively low health and relatively high value, or relatively low value and relatively high health. Additionally or alternatively, the system can avoid suspending services that are healthy and have a relatively high value.

[0040] One or more embodiments include a cloud infrastructure protection utility that collects, processes, and analyzes data generated by various components in a cloud environment. This cloud infrastructure protection utility generates weighted metrics and other information related to triggering events and value, health, performance, or behavioral services within the cloud environment. The cloud infrastructure protection utility provides insights into the occurrence of triggering events and the operational status of the cloud environment. These insights enable cloud operators to respond more effectively to triggering events that threaten the operability of cloud infrastructure while maintaining relatively high-value services operational during adverse conditions caused by triggering events. This cloud infrastructure protection utility allows cloud operators to protect cloud infrastructure while minimizing service disruptions to customers.

[0041] In one example, a cloud infrastructure provider deploys cloud infrastructure protection utilities and / or event mitigation interfaces to a partition of the cloud environment, such as a domain. The partition could be a PLC domain supplied to a PLC operator, such as a customer operating as a reseller. The cloud infrastructure provider can then hand over operation of the partition to the PLC operator or customer after deploying the cloud infrastructure protection utilities. One or more operators can access and utilize the cloud infrastructure protection utilities to monitor for and respond to triggering events.

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

[0043] 2. Example Cloud Environment

[0044] One or more embodiments provide features associated with a cloud environment, including a PLC environment. 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 offers.

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

[0046] cloud infrastructure environment

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

[0048] 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).

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

[0050] like Figure 1As 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.

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

[0052] 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), which enable customers to create and access cloud networks 184 and 186 and run cloud instances A 192 and B 194. In this embodiment, availability domain A 180 and availability domain B 182 may represent data centers, or a group of data centers located within a region. These availability domains may be isolated from each other, meaning they may not share the same physical infrastructure, such as power or cooling systems. This design provides a high degree of fault independence and robustness. In this embodiment, a fault domain can provide additional protection and resilience within a single availability domain by grouping hardware and infrastructure into availability domains isolated from other fault domains. This isolation may involve power, cooling, and other potential sources of failure.

[0053] According to an embodiment, a lease (a container of resources used by the tenant) can be created for each cloud tenant / customer (e.g., tenants A 142 and B 144). This lease provides a secure and isolated partition within the cloud infrastructure environment, where customers can create, organize, and manage their cloud resources. Cloud tenants / customers can access availability domains and cloud networks to access each of their cloud instances. Leases are isolated from other leases, ensuring that each customer's data and resources are secure and inaccessible to other customers. Within a lease, customers can create, manage, and organize various cloud resources, including compute instances, storage volumes, and networks. Identity and Access Management (IAM) services enable the management of users, groups, and policies within a lease. Through IAM, customers can control who has access to their resources and what actions they can perform. Leases also represent a level of disposal billing and subscription management. Usage and costs associated with resources within a lease are tracked and billed uniformly under that lease. Each lease 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 among tenants.

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

[0055] According to an embodiment, the cloud infrastructure environment provides access to the shared cloud resource 140 via, for example, a compute resource layer 150, a network resource layer 160, and / or a storage resource layer 170. Customers can launch cloud instances as needed to meet computing and application requirements. After a customer has provisioned and launched a cloud instance, the provisioned cloud instance can be accessed from a client device (such as client device 120).

[0056] According to an embodiment, computing resources 150 may include resources such as bare-metal cloud instances 152, virtual machines 154, graphics processing unit (GPU) computing 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 the server's processor, memory, storage devices, 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 VMs, thereby allocating physical resources (such as CPU, memory, and storage devices) to each VM. In an embodiment, GPU computing cloud instances provide GPUs as well as traditional CPU resources. These instances are designed for tasks requiring high levels of parallel processing power, making them well-suited for applications such as machine learning, scientific computing, 3D rendering, and video processing. In an embodiment, container 158 uses a virtualization approach that allows multiple isolated applications to run on a single controlling host, thereby virtualizing the operating system. Each container shares the host system's kernel but runs in an isolated user space, making the containers lightweight and efficient.

[0057] The components of computing resource 150 can be used to provision and manage bare-metal computing cloud instances, or to provision cloud instances as needed to deploy and run applications, just like in an on-premises data center. For example, according to an embodiment, the cloud infrastructure environment can provide control over physical host (bare-metal) machines within the computing resource tier that run directly on bare-metal servers as computing cloud instances without the need for a hypervisor.

[0058] According to an embodiment, the cloud infrastructure environment can also provide control over virtual machines within the computing resource layer, which can be booted from, for example, an image, wherein the type and quantity of resources available to the virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine is booted.

[0059] According to an embodiment, the network resource layer may include several network-related resources, such as a Virtual Cloud Network (VCN) 162, a load balancer 164, an edge service 166, and / or a connectivity service 168. In this embodiment, the Virtual Cloud Network (VCN) is a customizable and private network in a cloud environment. The VCN provides a virtual version of a traditional network, including subnets, routing tables, and gateways. It allows users to set up a cloud-based network architecture according to their requirements. In this embodiment, the edge service 166 includes services and technologies designed to bring computing, data storage, and networking capabilities closer to the desired location. The edge service 166 can be used to optimize traffic, reduce latency, or provide other advantages.

[0060] According to embodiments, the storage resource layer may include several resources, such as data / block volume 172, file storage device 174, object storage device 176, and / or local storage device 178. Data / block volume 172 provides unformatted block-level storage, which can be used to create a file system for a managed database or for other purposes requiring unformatted storage. File storage device 174 provides a file system in embodiments and can provide a shared file system that can be accessed simultaneously by multiple instances using standard file storage protocols. Object storage device 176 manages data as objects within buckets. Objects have certain attributes, which may include data, metadata, and unique identifiers. Local storage device 178 refers to a storage device physically attached to a host computer.

[0061] like Figure 2 As shown, according to an embodiment, the cloud infrastructure environment may include a series of complementary cloud-based components, such as cloud infrastructure applications and services 200, which enable organizations or enterprise customers to operate their applications and services in a highly available managed environment.

[0062] According to an embodiment, a self-contained cloud region can be provided as a dedicated area of ​​Oracle Cloud Infrastructure (OCI) within an organization's data center, which provides data center operators with the flexibility, scalability, and cost-effectiveness of, for example, the OCI public cloud, while retaining full control over its data and applications to meet security, regulatory, or data residency requirements.

[0063] For example, according to an embodiment, such an environment may include racks physically and logically managed by a cloud infrastructure provider (e.g., Oracle), customer racks, access rights for cloud operators to perform setup and hardware support, customer data center power and cooling, customer footprint, customer data center personnel area, and physical access cages.

[0064] According to an embodiment, a dedicated zone provides tenants / customers with 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, finance, HCM, and SCM, available in the public cloud regions of a cloud infrastructure provider (e.g., Oracle). Customers can seamlessly extract and replace legacy workloads using services from the cloud infrastructure provider (e.g., bare metal computing, VMs, and GPUs), database services (e.g., Oracle Autonomous Database), or container-based services (e.g., Oracle Kubernetes Container Engine).

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

[0066] In the IaaS model, cloud infrastructure providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, cloud infrastructure providers can also supply various services to complement these infrastructure components; example services include billing software, monitoring software, logging software, load balancing software, or clustering software. Therefore, because these services can be policy-driven, IaaS users can implement policies to drive load balancing, thereby maintaining application availability and performance.

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

[0068] According to the embodiments, cloud infrastructure providers may, but are not necessarily, third-party services that exclusively provide (e.g., provision, lease, or sell) IaaS. Entities may also choose to deploy private clouds, thereby becoming their own infrastructure service providers.

[0069] 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 may also include the processing of a preparation server (e.g., an installation library or daemon). This is typically managed by the cloud infrastructure provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for disposal (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

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

[0071] According to embodiments, the challenges of IaaS provisioning include: the initial challenge of provisioning an initial set of infrastructure before anything is operational; and the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, or removing services) once everything is provisioned. In some cases, these two challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more profiles. Therefore, the overall topology of the infrastructure (e.g., which resources depend on other resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows for creating and / or managing the different components described in the profiles can be generated.

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

[0073] According to embodiments, continuous deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that is intended to be deployed to one or more, but typically many, different production environments (e.g., across various geographical locations). However, in some examples, the infrastructure for deploying the code needs to be provisioned. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed using deployment tools.

[0074] Figure 3 The illustration shows an example cloud infrastructure architecture according to an embodiment.

[0075] like Figure 3 As shown, according to an embodiment, service operator 202 can communicatively couple to secure host lease 204, which may include virtual cloud network (VCN) 206 and secure host subnet 208.

[0076] In some examples, service operators may use one or more client computing devices, which may be portable handheld devices (e.g., telephones, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., head-mounted displays), running software such as Microsoft Windows and / or various mobile operating systems (e.g., iOS, Android, etc.), and supporting the Internet, email, short message service (SMS), or other communication protocols. Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices may be workstation computers running various commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as Chrome OS). Additionally or alternatively, client computing devices may be any other electronic device, such as thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles), and / or personal messaging devices capable of communicating over networks with access to VCNs and / or the Internet.

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

[0078] According to an embodiment, the control plane VCN may include a control plane demilitarized zone (DMZ) layer 220 that acts as a peripheral network (e.g., part of an enterprise network between an internal and external network). DMZ-based servers may have limited responsibility to help contain potential vulnerabilities. Furthermore, the DMZ layer may include one or more load balancer (LB) subnets 222, a control plane application layer 224 that may include an application subnet 226, and a control plane data layer 228 that may include database (DB) subnets 230 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets included in the control plane DMZ layer may communicatively couple to one or more application subnets included in the control plane application layer and an Internet gateway 234 that may be included in the control plane VCN. One or more application subnets may communicatively couple to one or more DB subnets, a service gateway 236, and a Network Address Translation (NAT) gateway 238 included in the control plane data layer. The control plane VCN may include a service gateway and a NAT gateway.

[0079] According to an embodiment, the control plane VCN may include a data plane mirror application layer 240, which may include one or more application subnets. The one or more application subnets included in the data plane mirror application layer may include a virtual network interface controller (VNIC) capable of executing compute instances. The compute instances may communicatively couple the one or more application subnets of the data plane mirror application layer to the one or more application subnets that may be included in the data plane application layer.

[0080] According to an embodiment, the data plane VCN may include a data plane application layer, a data plane DMZ layer, and a data plane data layer. The data plane DMZ layer may include one or more LB subnets communicatively coupled to one or more application subnets of the data plane application layer and the internet gateway of the data plane VCN. The one or more application subnets may be communicatively coupled to the service gateway and NAT gateway of the data plane VCN. The data plane data layer may also include one or more DB subnets communicatively coupled to one or more application subnets of the data plane application layer.

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

[0082] According to an embodiment, the service gateway of the control plane VCN or data plane VCN can make application programming interface (API) calls to cloud services without traversing the public internet. API calls from the service gateway to the cloud service can be unidirectional; the service gateway can make API calls to the cloud service, and the cloud service can send requested data to the service gateway. Generally, the cloud service cannot initiate API calls to the service gateway.

[0083] According to one embodiment, a secure host lease can be directly connected to a service lease that might otherwise be isolated. A secure host subnet can communicate with an SSH subnet via an LPG, which enables bidirectional communication between otherwise isolated systems. Connecting a secure host subnet to an SSH subnet allows the secure host subnet to access other entities within the service lease.

[0084] According to embodiments, a control plane VCN can allow users of a service lease to set 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 the data plane mirror application layer of the control plane VCN can communicate with the data plane application layer of the data plane VCN via a VNIC, which can be included in both the data plane mirror application layer and the data plane application layer.

[0085] According to an embodiment, users or clients of the system can make requests, such as create, read, update, or delete (CRUD) operations, via the public internet that can transmit requests to the metadata management service. The metadata management service can transmit the request to the control plane VCN via an internet gateway. The request can be received by one or more LB subnets contained in the control plane DMZ layer. The one or more LB subnets can determine that the request is valid, and in response to this determination, the one or more LB subnets can transmit the request to one or more application subnets contained in the control plane application layer. If the request is acknowledged and a call to the public internet is required, the call to the internet can be transmitted to a NAT gateway that can make the call to the internet. The metadata to be stored by the request can be stored in one or more DB subnets.

[0086] According to an embodiment, the data plane mirroring application layer can facilitate direct communication between the control plane VCN and the data plane VCN. For example, it may be desirable to apply configuration changes, updates, or other suitable modifications to resources contained in the data plane VCN. With the help of the VNIC, the control plane VCN can communicate directly with the resources contained in the data plane VCN, and thus can perform configuration changes, updates, or other suitable modifications.

[0087] According to one embodiment, the control plane VCN and data plane VCN can be included in a service lease. In this case, the system's users or customers may not own or operate the control plane VCN or data plane VCN. Alternatively, the cloud infrastructure provider may own or operate both the control plane VCN and data plane VCN, both of which can be included in a service lease. This embodiment enables network isolation, which can prevent users or customers from interacting with the resources of other users or customers. Furthermore, this embodiment allows the system's users or customers to privately store databases without relying on the public internet for storage, which may not provide the desired level of threat protection.

[0088] According to one embodiment, one or more LB subnets included in the control plane VCN can be configured to receive signals from the serving gateway. In this embodiment, the control plane VCN and the data plane VCN can be configured to be invoked by customers of the cloud infrastructure provider without invoking the public internet. Customers of the cloud infrastructure provider may expect this embodiment because the database(s) used by the customer can be controlled by the cloud infrastructure provider and can be stored on a service lease that is isolated from the public internet.

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

[0090] like Figure 4 As shown, according to an embodiment, the data plane VCN may be included in customer lease 221. In this case, the cloud infrastructure provider may provide a control plane VCN for each customer, and the cloud infrastructure provider may establish a unique compute instance for each customer included in the service lease. Each compute instance may allow communication between the control plane VCN included in the service lease and the data plane VCN included in the customer lease. The compute instance may allow resources provisioned in the control plane VCN included in the service lease to be deployed or otherwise used in the data plane VCN included in the customer lease.

[0091] According to an embodiment, a cloud infrastructure provider's customer may have a database managed and operated within a customer lease. In this example, the control plane VCN may include a data plane mirror application layer, which may include one or more application subnets. The data plane mirror application layer may reside in the data plane VCN, but it may not be provided within the data plane VCN. That is, the data plane mirror application layer may access the customer lease, but it may not exist in the data plane VCN, or be owned or operated by the customer. The data plane mirror application layer may be configured to invoke the data plane VCN, but it cannot be configured to invoke any entity contained within the control plane VCN. A customer may expect to deploy or otherwise use resources provisioned in the control plane VCN within the data plane VCN, and the data plane mirror application layer may facilitate the customer's desired deployment or other use of resources.

[0092] According to one embodiment, a cloud infrastructure provider's customers can apply filters to a data plane VCN. In this embodiment, the customer can determine what the data plane VCN can access and can restrict access to the public internet from the data plane VCN. The cloud infrastructure provider may not be able to apply filters or otherwise control the data plane VCN's access to any external networks or databases. Applying filters and controls to the data plane VCN included in the customer's lease helps isolate the data plane VCN from other customers and the public internet.

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

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

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

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

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

[0098] According to an embodiment, the public internet can communicatively couple to a NAT gateway contained in a control plane VCN and a data plane VCN. Service gateways contained in the control plane VCN and the data plane VCN can communicatively couple to cloud services.

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

[0100] According to an embodiment, a cloud infrastructure provider's customer can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application layer. The code running this functionality can execute within a VM, and this code may not be configured to run anywhere else on the data plane VCN. Each VM can be connected to a customer lease. The corresponding containers (1)-(N) contained within the VM can be configured to run the code. In this case, dual isolation can exist (e.g., containers running code, where the containers may be contained within at least one VM contained in an untrusted application subnet), which helps prevent incorrect or otherwise unintended code from corrupting the cloud infrastructure provider's network or the networks of different customers. Containers can be communicatively coupled to the customer lease and can be configured to transmit or receive data from the customer lease. Containers can be configured not to transmit or receive data from any other entity in the data plane VCN. After the code execution is complete, the cloud infrastructure provider can dispose of these containers.

[0101] According to an embodiment, one or more trusted application subnets may run code that can be owned or operated by a cloud infrastructure provider. In this embodiment, one or more trusted application subnets may be communicatively coupled to one or more database subnets and configured to perform CRUD operations within the one or more database subnets. One or more untrusted application subnets may be communicatively coupled to one or more database subnets and configured to perform read operations within the one or more database subnets. Containers that may be contained within each customer's VM and may run code from the customer may not be communicatively coupled to the one or more database subnets.

[0102] According to embodiments, the control plane VCN and data plane VCN may be coupled without direct communication, or there may be no direct communication between them. However, communication can occur indirectly, where the cloud infrastructure provider can establish an LPG that facilitates communication between the control plane VCN and the data plane VCN. In another example, either the control plane VCN or the data plane VCN can invoke cloud services via a service gateway. For example, an invocation of a cloud service from the control plane VCN may include a request for a service that can communicate with the data plane VCN.

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

[0104] like Figure 6As shown, according to an embodiment, one or more trusted application subnets may be communicatively coupled to a service gateway contained in the data plane VCN, a NAT gateway contained in the data plane VCN, and one or more database subnets contained in the data plane data layer. One or more untrusted application subnets may be communicatively coupled to a service gateway contained in the data plane VCN and one or more database subnets contained in the data plane data layer. The data plane data layer may include one or more database subnets that can be communicatively coupled to a service gateway contained in the data plane VCN.

[0105] According to an embodiment, one or more untrusted application subnets may include a primary VNIC that is communicatively coupled to tenant virtual machines (VMs) residing within one or more untrusted application subnets. Each tenant VM may run code in a corresponding container and may be communicatively coupled to an application subnet that may be included in a data plane application layer, which may be included in a container egress VCN 280. Corresponding auxiliary VNICs 282(1)-(N) may facilitate communication between the one or more untrusted application subnets included in the data plane VCN and the application subnets included in the container egress VCN. The container egress VCN may include a NAT gateway that is communicatively coupled to the public internet.

[0106] According to an embodiment, an Internet gateway contained in a control plane VCN and a data plane VCN can be communicatively coupled to a metadata management service, which can be communicatively coupled to the public Internet. The public Internet can be communicatively coupled to a NAT gateway contained in both the control plane VCN and the data plane VCN. A service gateway contained in both the control plane VCN and the data plane VCN can be communicatively coupled to a cloud service.

[0107] According to an embodiment, Figure 6 The pattern shown can be regarded as Figure 5 This is an exception to the pattern shown, and it may be the pattern desired by customers if the cloud infrastructure provider cannot communicate directly with them (e.g., in a disconnected region). Customers have live access to the corresponding containers contained within each customer's VM. Containers can be configured to invoke appropriate secondary VNICs contained in one or more application subnets within the data plane application layer, which may be contained in the container's egress VCN. The secondary VNICs can then route the calls to a NAT gateway, which can then route the calls to the public internet. In this example, the containers that customers can access live can be isolated from the control plane VCN and from other entities contained within the data plane VCN. Containers can also be isolated from resources from other customers.

[0108] In other examples, customers can use containers to invoke cloud services. In this example, a customer can run code within a container that requests a service from the cloud service. The container can then forward the request to a secondary VNIC, which in turn forwards it to a NAT gateway, which in turn forwards it to the public internet. The public internet can then be used to forward the request via an internet gateway to one or more load balancer (LB) subnets contained within the control plane VCN. In response to determining that the request is valid, the LB subnets can forward the request to one or more application subnets, which in turn forward the request to the cloud service via a service gateway.

[0109] It should be recognized that the IaaS architecture depicted in the figures above may have components other than those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be combined with embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations or arrangements.

[0110] In some embodiments, the IaaS system described herein may include a suite of application, middleware, and database service providers delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner.

[0111] Private Tag Cloud Environment

[0112] According to an embodiment, a cloud infrastructure environment can be used to provide a dedicated cloud environment, such as one or more privately tagged cloud environments, for tenants of the cloud infrastructure environment to use when accessing subscription-based software products, services, or other provisioning items associated with the cloud infrastructure environment.

[0113] Figure 7 The illustration shows how a system according to an embodiment can provide a dedicated or private tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0114] like Figure 7 As shown, according to an embodiment, a cloud infrastructure provider (e.g., OCI) may supply one or more 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 tag cloud for use by its customer 330 when accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0115] For illustrative purposes, examples of such subscription-based products, services, or other offerings may 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.

[0116] Figure 8 The illustration further illustrates the use of a privately labeled cloud domain by a tenant or customer of a cloud infrastructure environment, according to an embodiment.

[0117] like Figure 8 As shown, according to an embodiment, the system may include a cloud subscription service or component, such as an Oracle Cloud Subscription (OCS) service or component, which exposes one or more subscription management APIs for creating orders for joining new customers or initiating workflows for creating subscriptions and orchestrating billing and pricing services or other components for the PLC domain 400.

[0118] According to an embodiment, when a PLC operator or its customer requests a PLC environment, the system creates a PLC domain for lease use by one or more providers. 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 domain boundaries to regions outside that domain. Each domain is accessed independently. The PLC operator accesses cloud resources and services through cloud leases. A cloud lease is a secure and isolated partition of the cloud infrastructure environment, and it exists only within a single domain. Within this lease, if policies permit, the operator can access services in all regions within that domain and deploy workloads.

[0119] According to an embodiment, the first step of this process is to create an operator lease for the PLC operator, and then transfer the domain and associated areas to the PLC operator for subsequent management. The PLC operator then becomes the administrator of the lease, able to view and manage everything that happens within the domain, including its customer accounts and those customers' use of cloud resources.

[0120] Generally, once the domain is handed over or provided to the PLC operator, the cloud infrastructure provider cannot subsequently access the data within the operator's lease unless the operator authorizes the cloud infrastructure provider to do so, for example, to provide troubleshooting for potential problems.

[0121] According to an embodiment, the PLC operator can then create additional internal leases intended for its own internal use, such as for evaluating the end-customer experience, providing sales demonstration leases, or operating a database for its own internal use. The operator can also create one or more customer leases, with the end customer acting as its administrator. Cloud infrastructure usage metrics (e.g., compute usage, storage usage, and usage of other infrastructure resources) can be aggregated by the operator to reflect usage by both the operator and customers. Cloud infrastructure usage can be reported to the cloud infrastructure provider.

[0122] According to embodiments, a user interface or console may be provided that allows PLC operators to manage their customer accounts and customer-supplied services. Cloud infrastructure providers may also use cloud infrastructure leasing (e.g., converged application leasing) to install any required infrastructure services for use by operators and their customers.

[0123] Figure 9 The illustration further illustrates the use of a privately labeled cloud domain by a tenant or customer of a cloud infrastructure environment, according to an embodiment.

[0124] like Figure 9 As shown, according to an embodiment, a cloud subscription service or component exposes one or more subscription management APIs for creating orders for new customers or initiating workflows for creating subscriptions and orchestrating billing and pricing services or other components.

[0125] According to an embodiment, the system may also include a billing service or component that operates on a logical container for billing accounts or subscriptions and preferences used to generate invoices for customers.

[0126] According to an embodiment, the system may also include a subscription pricing service (SPS) or component that operates on a product catalog defining the products that customers can purchase. The subscription pricing service may also be used to provide a price list (e.g., a rate card) that is also available through the pricing service.

[0127] According to an embodiment, to support sales processing for creating subscriptions in the PLC domain, products can be selected from the product hub. Once an order is created, a subscription is created in a cloud subscription service, which then manages the subscription's lifecycle and provisiones the content required for provisioning in downstream services. The SPS component then manages pricing and usage aspects for the ability to collect final fees from PLC operators or for operators to charge their customers. Usage events are forwarded to a billing service or component, where, depending on the subscription's billing preferences, an invoice is created and pushed to the accounts receivable component.

[0128] According to an embodiment, although the services provided in the field report their usage to a metering service or component, such usage does not have any associated price. Billing processing, for example, determines the cost of each specific event by applying a rate card, determines the unit and cost of the subscription, associates the cost with the record, and then forwards it to the billing service or component.

[0129] like Figure 9 As further illustrated, according to an embodiment, a PLC operator can control multiple domains A and B. For example, an operator operating in multiple countries might wish 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 an embodiment, usage associated with these multiple domains can be aggregated for billing the operator.

[0130] The examples of the various systems provided above are intended 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.

[0131] Private tag cloud subscription

[0132] Figure 10 The illustration depicts a system according to an embodiment for providing access to software products or services in a cloud computing or other computing environment.

[0133] like Figure 10 As shown, according to an embodiment, the system can be provided as a cloud computing or other computing environment, referred to herein as a platform in some embodiments, which supports the use of subscription-based products, services or other offerings.

[0134] Examples of such subscription-based products, services, or other offerings may 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 use these products or services.

[0135] According to embodiments, subscriptions may include artifacts such as products, commitments, billing models, and states. The cloud subscription service may expose one or more subscription management APIs for creating orders to join new customers or initiating workflows to create subscriptions and orchestrate appropriate footprints in the billing and pricing services or components, as further described below.

[0136] According to an embodiment, a billing service or component operates on a logical container of billing accounts or subscriptions and preferences used to generate invoices. Each billing account generates one or more invoices per billing period. The billing service includes a first pipeline that receives usage and costs from a metering service or component. Usage can be received via a REST API or other interface. The billing service writes the usage to a database from which the billing service or other services can calculate and aggregate balances. The billing service may include a second pipeline responsible for obtaining aggregated usage and commitments and calculating costs for one or more billing intervals.

[0137] According to an embodiment, a subscription pricing service (SPS) or component operates on a product catalog that defines the products a customer can purchase. The product catalog forms the backbone of a price list (i.e., rate cards) also owned by the pricing service. Rate cards are modeled as pricing rules on top of publicly listed prices. The pricing service maintains a single price list for each product; new product prices can be added, and existing prices can be changed. The price lists have a complete history, with the latest version being the current rate card. Because some contracts may require snapshots of the rate cards, the pricing service handles this by recording when a customer's rate card was created and then querying the price list at that time.

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

[0139] According to an embodiment, the cloud subscription service operates as an upstream service to receive new order requests, for example, from the Oracle Fusion Order Management environment. The cloud subscription service can provide subscription information to the SPS service. Subscription details such as the timing 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, for example, received from Oracle Fusion Order Management, which the SPS stores as a pricing rule entity.

[0140] In one embodiment, the SPS service runs as a background process to manage a rate card service or component responsible for generating rate cards for new subscriptions and updating them when prices change. The SPS service can expose APIs to access rate cards and pricing rules. The metering inline billing engine can leverage these APIs to obtain subscription-specific rate cards and pricing rules, using this data for cost calculations.

[0141] According to an embodiment, additional SPS components may include, for example, the Pricing / Product Hub Oracle Integration Cloud (OIC) integration component, which allows PLC operator entities to manage, for example, their product and price lists provided by the Oracle Fusion Product Hub and the Oracle Fusion Pricing Hub, respectively, within the environment to offer subscription-based products, services, or other offerings.

[0142] For example, according to this embodiment, the SPS OIC product integration process can listen for creation / update events in the product hub and invoke the SPS product API. Similarly, the SPS OIC pricing integration process can retrieve new price list creation from the pricing hub and invoke the corresponding SPS pricing API.

[0143] According to one embodiment, the system may also include an SPS core module that provides APIs for managing and accessing pricing entities. Pricing can be accessed through internal services such as an inline billing engine.

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

[0145] According to an embodiment, the system may also include a rule decoder engine. The SPS service is responsible for managing the pricing rules for subscriptions, including discounts offered to end customers. Pricing rule applicability can be based on product attributes such as discount groups, product categories, or specific SKUs. Internally, the SPS needs to identify a list of products to which these rules will apply. To achieve this, the rule decoder engine can compile the pricing rules into a format that the inline billing engine can use for cost calculations. This compilation process can be triggered when a product or pricing rule is created / updated.

[0146] If passed Figure 10As illustrated in the example, according to the embodiment: At 441, product and pricing information, such as that managed 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, the pricing configuration and pricing rules for the new order are sent to the SPS. At 444, the Cloud Subscription Service is used to establish a billing account in the Billing Service or component. At 445, the Cloud Subscription Service publishes events to the Cloud Infrastructure Streaming component. At 446, billing data is sent to the Accounts Receivable component to generate an invoice. At 447, the Cloud Subscription Service uses Recycling and Subscription Lifecycle (RASL) events from the Cloud Infrastructure Streaming component. At 448, the Activation Service reads the Cloud Subscription Service event stream. At 449, the customer retrieves activation data from the portal. At 450, the Lease Lifecycle Service provisiones the lease as part of the subscription activation. At 451, the Lease Lifecycle Service creates an account footprint during account provisioning. At 452, the Lease Lifecycle Service sets a limit template during account provisioning. At 453, the account component acts as a downstream RASL client to handle legacy repossession. At 454, aggregated costs and usage are sent to the billing service or component. At 455, organizations can create subleases using the lease lifecycle service. At 456, the metering service or component retrieves subscription mapping data. At 457, the subscription service retrieves organizational data used for subscription mapping. At 458, RASL reads the cloud subscription service event stream. At 459, the subscription service reads the cloud subscription service event stream; and at 460, the metering service or component retrieves rate card data for each subscription, which can then be used to collect final charges from PLC operators or enable PLC operators to charge their customers.

[0147] The examples provided above are intended to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for use by tenants of cloud infrastructure 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.

[0148] 3. System Architecture for Cloud Infrastructure Protection

[0149] Figure 11A-11C The illustration depicts a system 1100 according to one or more embodiments, the system 1100 including features for cloud infrastructure protection, including features for triggering events in response to threats to the operability of the cloud infrastructure. In one or more embodiments, system 1100 refers to hardware and / or software configured to perform the operations described herein. Reference is made below. Figure 14A and 14B Examples describing the operation. (In addition to the reference...) Figure 11A-11CIn addition to the features described, system 1100 may also include one or more features described in Part 2 above, entitled “Dedicated or Private Tag Cloud Environment”.

[0150] In one or more embodiments, system 1100 may include a reference. Figure 11A-11C The number of components described may be more or less. (Reference) Figure 11A-11C The components described can be located locally or remotely. References Figure 11A-11C The described components can be implemented using 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. An operation described for one component can be performed by another component.

[0151] A. Example of triggering event monitoring

[0152] refer to Figure 11A System 1100 includes cloud infrastructure 1102. Cloud infrastructure 1102 includes infrastructure elements 1104, a virtual cloud network 1106, and infrastructure support systems 1108. Infrastructure elements 1104 (such as infrastructure elements 1104a and 1104n) include physical components for providing a cloud infrastructure environment. As an example, physical components may include one or more of the following: servers, racks, switches, processors, memory devices, storage devices, networking devices, power supply devices, and other physical components for providing a cloud infrastructure environment. Virtual cloud network 1106 is deployed on at least a portion of infrastructure element 1104.

[0153] Infrastructure support system 1108 includes an environmental monitoring system 1110 that monitors environmental conditions associated with system 1100 and an environmental control system 1112 that controls the environmental conditions associated with system 1100. Environmental monitoring system 1110 includes multiple sensors 1114, such as sensors 1114a and 1114n. Sensors 1114 can monitor environmental conditions, for example, to detect environmental conditions that may indicate a triggering event. Environmental conditions monitored by sensors 1114 may include one or more of the following: temperature, humidity, air pressure, moisture, water, wind speed, smoke, or air quality. In one example, sensor 1114 includes one or more of the following: a temperature sensor, a humidity sensor, an air pressure sensor, a moisture sensor, a flood sensor, an anemometer, a smoke detector, or an air quality sensor. Additionally or alternatively, sensors 1114 may monitor the operating conditions of cloud infrastructure 1102, for example, to detect operating conditions that may indicate a triggering event. The operating conditions monitored by sensor 1114 may include one or more of the following: power consumption, voltage, network traffic, latency, virtualization performance, storage performance, database performance, server workload, load balancer health, or application performance.

[0154] The environmental control system 1112 includes multiple controlled components 1116, such as controlled components 1116a and 1116n. The environmental control system 1112 controls the controlled components 1116 to adjust environmental parameters that may affect the cloud infrastructure. The controlled components 1116 may include one or more of the following: heating systems, cooling systems, ventilation systems, air conditioning systems, fans, blowers, dampers, vents, humidification systems, dehumidification systems, fire suppression systems, air quality control equipment, or lighting systems. The environmental control system 1112 may control the controlled components 1116 in response to control commands from the environmental monitoring system 1110. The control commands may cause the controlled components 1116 to operate in a manner that provides desired environmental conditions to the infrastructure element 1104 of the cloud infrastructure 1102 and / or the virtual cloud network 1106 deployed on the infrastructure element 1104. In one example, the controlled components 1116 maintain temperature and humidity levels, for example, to prevent the infrastructure element 1104 from overheating and / or to maintain the reliable operation of the infrastructure element 1104. Sensor 1114 can monitor the operation of the controlled component 1116, for example, to provide feedback to the environmental control system 1112 corresponding to control commands. Additionally or alternatively, sensor 1114 can monitor the operation of infrastructure element 1104, for example, to verify that infrastructure element 1104 is performing normally and / or to detect the occurrence of interruptions, interference, anomalies or performance defects.

[0155] Further reference Figure 11AMultiple partitions 1118, such as partition 1118a and partition 1118n, are deployed on the virtual cloud network 1106. Partition 1118 represents a logically or physically isolated portion of the virtual cloud network 1106. In one example, partition 1118 includes tenant partitions or leases that isolate portions of the virtual cloud network 1106 between different entities or tenants (such as PLC operators or customers). Additionally or alternatively, partition 1118 may include service partitions that isolate different services or workloads. Additionally or alternatively, partition 1118 may include geographic partitions that isolate a portion of the virtual cloud network 1106 corresponding to a specific geographic region. Additionally or alternatively, partition 1118 may include network partitions that isolate the virtual cloud network 1106 into separate segments or subnets.

[0156] One or more partitions 1118 include a cloud infrastructure protection utility 1120. Additionally or alternatively, one or more partitions 1118 include multiple services 1122, such as service 1122a and service 1122n. The cloud infrastructure protection utility 1120 can perform operations related to protecting cloud infrastructure 1102, including detecting triggering events that threaten the operability of cloud infrastructure 1102 and / or performing mitigation procedures to mitigate the impact of the triggering events. In one example, mitigation procedures may include stopping the operation of one or more services 1122.

[0157] The cloud infrastructure protection utility 1120 can, in response to a triggered event, stop services 1122 running in one or more partitions 1118 of the virtual cloud network 1106. Services 1122 stopped to mitigate the impact of the triggered event may reside in the same partition as the cloud infrastructure protection utility 1120 and / or in a different partition 1118. In one example, such as... Figure 11A As shown, partition 1118a includes cloud infrastructure protection utility 1120, and partition 1118n includes multiple services 1122, which can be stopped by cloud infrastructure protection utility 1120 to mitigate the impact of the triggering event.

[0158] In one example, cloud infrastructure protection utility 1120 is deployed to partition 1118 assigned to a cloud operator (such as a PLC operator or customer), and the cloud operator uses cloud infrastructure protection utility 1120 to detect triggering events and stop service 1122 running in partition 1118 to at least partially mitigate the impact of the triggering events. Additionally or alternatively, multiple different cloud operators (such as multiple different PLC operators or customers) may each utilize an instance of cloud infrastructure protection utility 1120 to detect triggering events in their respective partitions 1118. By stopping service 1122 running in their respective partitions 1118, the triggering events can be at least partially mitigated. Multiple partitions 1118 that stop service 1122 can collectively contribute to mitigating the impact of the triggering events. Additionally or alternatively, cloud infrastructure protection utility 1120 may be deployed to partitions 1118 of a cloud infrastructure provider that monitors various partitions 1118 of the virtual cloud network 1106. Cloud infrastructure providers can utilize cloud infrastructure protection utility 1120 to detect triggering events and stop services 1122 executing in various partitions 1118 to at least partially mitigate the impact of the triggering events. In one example, the cloud infrastructure provider can utilize cloud infrastructure protection utility 1120 to select services 1122 to be stopped from various partitions 1118 (such as partitions 1118 assigned to various PLC operators or customers). In one example, various PLC operators or customers can utilize cloud infrastructure protection utility 1120 to provide inputs that can, for example, be used by the cloud infrastructure provider to select services 1122 to be stopped to mitigate the impact of the triggering events. The inputs can allow stopping services 1122 in various partitions 1118 based on criteria specific to a particular partition 1118 and / or specific services 1122 executing in partition 1118.

[0159] In one example, the input can be used to compute weighted metrics for various services 1122, which are used to determine which services 1122 should be stopped to mitigate the impact of the triggering event. In one example, the cloud infrastructure protection utility 1120 determines which services 1122 should be stopped based at least on weighted metrics corresponding to the weights assigned to the various service characteristics of service 1122. The weights assigned to the service characteristics can represent the value of the service characteristics in a given context. Additionally or alternatively, the cloud infrastructure protection utility 1120 can monitor the health of service 1122 and / or service characteristics. In one example, the cloud infrastructure protection utility 1120 selects which services 1122 should be stopped based at least on the health of service 1122 and / or the weighted metrics corresponding to the various service characteristics of service 1122. See below for reference. Figure 11B Further description of example service 1122 and its service characteristics. See below for reference. Figure 13A and 13B Further description of the example weighted metric.

[0160] As used herein, the term "triggering event" refers to an event or condition that threatens, disrupts, or inhibits the operability of at least a portion of a cloud infrastructure. A triggering event threatens the operability of the corresponding portion of the cloud infrastructure when there is a significant likelihood that the triggering event or condition will exceed the operational parameters corresponding to that portion of the cloud infrastructure. Operational parameters may include control limits or specifications for operating the corresponding portion of the cloud infrastructure. Triggering events may include large-scale events or conditions that have a broad impact on the cloud infrastructure, such as widespread service outages. Additionally or alternatively, triggering events may include isolated events or conditions that affect isolated portions of the cloud infrastructure.

[0161] Triggering events may be associated with one or more of the following: weather, environmental conditions, equipment failure or malfunction, operating conditions of cloud infrastructure, misconduct, or human error. Additionally or alternatively, triggering events may be associated with one or more of the following: severe weather, heat waves, storms, natural disasters, cold waves, hurricanes, blizzards, tornadoes, dust storms, floods, fires, explosions, wind, rain, snow, ice, haze, or smoke. Additionally or alternatively, triggering events may be associated with one or more of the following: hardware failure, power outages, utility interruptions, switching to backup power, power supply limitations, voltage drops, power outages, cloud infrastructure interruptions, cooling system failures, ventilation system failures, heating system failures, network outages, software errors, cybersecurity incidents, security vulnerabilities, or system upgrade or maintenance events.

[0162] In one example, a triggering event may be based on one or more of the following: a threshold, physical limitations, performance limitations, capacity planning, operational strategies, cost limitations, or efficiency parameters. A triggering event can be determined by comparing sensor data from environmental monitoring system 1110 with a threshold. A threshold may correspond to a limitation or constraint associated with the operability of at least a portion of cloud infrastructure 1102. A triggering event and / or threshold can be selected to prevent or mitigate potential damage to the cloud infrastructure. The associated triggering event can be determined with respect to current, planned, or predicted scenarios. Scenarios may relate to the environmental and / or operational conditions of cloud infrastructure 1102. Triggering events can be determined with respect to finite deterministic scenarios and / or probabilistic scenarios. In one example, a triggering event may correspond to a scenario that explicitly threatens, interferes with, or inhibits the operability of at least a portion of the cloud infrastructure. Additionally or alternatively, a triggering event may correspond to a scenario that satisfies a probabilistic threshold that threatens, interferes with, or inhibits the operability of at least a portion of the cloud infrastructure.

[0163] B. Example services and service features

[0164] refer to Figure 11B As shown with respect to partition 1118n, partition 1118 includes service 1122, and service 1122 includes one or more service features 1124.

[0165] In one example, such as Figure 11B As shown, partition 1118n includes services 1122a and 1122c. Service 1122a includes service features 1124a and 1124b. Service 1122c includes service features 1124c and 1124d. Furthermore, partition 1118n includes services 1122e and 1122n. Service 1122e includes service features 1124e and 1124f. Service 1122n includes service features 1124n and 1124x.

[0166] The cloud infrastructure protection utility 1120 determines the occurrence of a triggering event. To mitigate the impact of the triggering event on the cloud infrastructure, the cloud infrastructure protection utility 1120 determines the services 1122 to be stopped in partition 1118n based on weighted metrics associated with the various service characteristics 1124 of service 1122. In one example, the cloud infrastructure protection utility 1120 may determine the services 1122 to be stopped based on weighted metrics corresponding to the weights of service characteristics 1124a and service characteristics 1124b assigned to service 1122a. Additionally or alternatively, the cloud infrastructure protection utility 1120 may determine the services 1122 to be stopped based on weighted metrics corresponding to the weights of service characteristics 1124c and service characteristics 1124d assigned to service 1122c. Additionally or alternatively, the cloud infrastructure protection utility 1120 may determine the service 1122 to be stopped based on a weighted metric corresponding to the weights of service characteristics 1124e and service characteristics 1124f assigned to service 1122e. Additionally or alternatively, the cloud infrastructure protection utility 1120 may determine the service 1122 to be stopped based on a weighted metric corresponding to the weights of service characteristics 1124n and service characteristics 1124x assigned to service 1122n.

[0167] In one example, the cloud infrastructure protection utility 1120 determines a weighted metric for service 1122 based on weights assigned to one or more service features 1124, representing the value of each service feature within a given context. Alternatively or additionally, the cloud infrastructure protection utility 1120 may determine a weighted metric for service 1122 based on weights assigned to one or more service features 1124, representing the impact of each service feature 1124 on one or more other service features 1124 deployed downstream.

[0168] like Figure 11B As shown, service feature 1124e of service 1122e is arranged downstream of service feature 1124a of service 1122a. Service feature 1124e depends on service feature 1124a. In one example, the functionality of service feature 1124e depends on the functionality of service feature 1124a. Furthermore, service feature 1124n of service 1122n is arranged downstream of service feature 1124a of service 1122a. Service feature 1124n depends on service feature 1124a. In one example, the functionality of service feature 1124n depends on the functionality of service feature 1124a. The functionality of service feature 1124a may include generating one or more outputs that are used as input by service feature 1124e and / or service feature 1124n. Additionally or alternatively, the functionality of service feature 1124a may include performing one or more operations that directly or indirectly affect service feature 1124e and / or service feature 1124n. Additionally or alternatively, service feature 1124e and / or service feature 1124n may be arranged after service feature 1124a relative to the sequence of data flows or operations. The cloud infrastructure protection utility 1120 may determine the weighted metric of service 1122a based at least in part on: (a) the impact of service feature 1124a on service feature 1124e due to the dependency between service feature 1124a and service feature 1124e; and / or (b) the impact of service feature 1124a on service feature 1124n due to the dependency between service feature 1124a and service feature 1124n.

[0169] like Figure 11BAs further shown, service feature 1124f of service 1122e is arranged downstream of service feature 1124c of service 1122c, and service feature 1124x of service 1122n is arranged downstream of service feature 1124f of service 1122e. Service feature 1124f depends on service feature 1124c. In one example, the functionality of service feature 1124f depends on the functionality of service feature 1124c. The functionality of service feature 1124c may include generating one or more outputs that are used as input by service feature 1124f, and / or performing one or more operations that directly or indirectly affect service feature 1124f. Additionally or alternatively, service feature 1124f may be arranged after service feature 1124c relative to a data flow or sequence of operations. Furthermore, service feature 1124x depends on service feature 1124f. In one example, the functionality of service feature 1124x depends on the functionality of service feature 1124f. The functionality of service feature 1124f may include generating one or more outputs that use service feature 1124x as input, and / or performing one or more operations that directly or indirectly affect service feature 1124x. Additionally or alternatively, service feature 1124x may be arranged after service feature 1124f relative to a sequence of data flows or operations. Furthermore, service feature 1124x indirectly depends on service feature 1124c. Service feature 1124c indirectly affects service feature 1124x. The cloud infrastructure protection utility 1120 may determine the weighted metric of service 1122c based at least in part on the impact of service feature 1124c on service feature 1124f and / or service feature 1124x. Additionally or alternatively, the cloud infrastructure protection utility 1120 may determine the weighted metric of service 1122c and / or the weighted metric of service 1122e based at least in part on the impact of service feature 1124f on service feature 1124x.

[0170] In one example, cloud infrastructure protection utility 1120 can determine a weighted metric for service 1122 based on weights assigned to one or more service features 1124 of service 1122, where these weights represent the influence of one or more service features 1124 located upstream on one or more service features 1124 of service 1122. Figure 11BAs shown, service feature 1124a of service 1122a is positioned upstream of service feature 1124e of service 1122e and service feature 1124n of service 1122n. Due to the dependency between service feature 1124a and service feature 1124e, service feature 1124a influences service feature 1124e. Additionally or alternatively, due to the dependency between service feature 1124a and service feature 1124n, service feature 1124a influences service feature 1124n. The cloud infrastructure protection utility 1120 may determine the weighted metric of service 1122e based at least in part on the influence of service feature 1124a on service feature 1124e. Additionally or alternatively, the cloud infrastructure protection utility 1120 may determine the weighted metric of service 1122n based at least in part on the influence of service feature 1124a on service feature 1124n.

[0171] like Figure 11B As further shown, service feature 1124f of service 1122e is positioned upstream of service feature 1124x of service 1122n, and service feature 1124c of service 1122c is positioned upstream of service feature 1124f. Due to the dependency between service feature 1124f and service feature 1124x, service feature 1124f influences service feature 1124x. Due to the dependency between service feature 1124c and service feature 1124f, service feature 1124c influences service feature 1124f. The cloud infrastructure protection utility 1120 can determine the weighted metric of service 1122e at least in part based on the influence of service feature 1124c on service feature 1124f. Additionally or alternatively, the cloud infrastructure protection utility 1120 can determine the weighted metric of service 1122n at least in part based on the influence of service feature 1124f and / or service 1122c on service feature 1124x.

[0172] As used herein with reference to the arrangement of a first service feature downstream of a second service feature, the term "downstream" means at least one of the following: (a) the first service feature is arranged after the second service feature relative to a sequence of data flow or operations; (b) the first service feature depends on the functionality of the second feature, such as the output of the second service feature for which the first service feature is used as input; or (c) an operation performed by the second service feature that directly or indirectly affects the first service feature.

[0173] As used herein with reference to the arrangement of a first service feature upstream of a second service feature, the term "upstream" means at least one of the following: (a) the first service feature is arranged prior to the second service feature relative to a sequence of data flow or operations; (b) the first service feature has a function upon which the second feature depends, such as the output of the first service feature for which the second service feature is used as input; or (c) an operation performed by the first service feature that directly or indirectly affects the second service feature.

[0174] As used herein with reference to a first service feature that depends on or has a dependency relationship with a second service feature, the term "dependency" or "dependency relationship" means at least one of the following: (a) the first service feature is arranged after the second service feature relative to a sequence of data flows or operations; (b) the first service feature depends on the functionality of the second feature, such as the output of the second service feature for which the first service feature is used as input; or (c) an operation performed by the second service feature that directly or indirectly affects the first service feature. In one example, a downstream service feature depends on an upstream service feature.

[0175] As used herein, the term "service" refers to a modular, self-contained functional unit deployed in cloud infrastructure. A service can encapsulate a specific set of functions, utilities, or tasks. Services can range from simple, standalone applications or utilities to functional units of complex distributed systems comprising multiple interconnected components. Services can include well-defined interfaces for interacting with other services, service features, or carrier equipment interfaces.

[0176] In one example, services include compute instances, virtual machines, containers, or storage systems. Additionally or alternatively, services include applications, programs, utilities, resources, platforms, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Database as a Service (DBaaS), container orchestration services, serverless computing services, storage services, Content Delivery Network (CDN) services, Identity and Access Management (IAM) services, networking services, machine learning or AI services, big data or analytics services, Internet of Things (IoT) services, blockchain services, monitoring or logging services, customized services, or customer-specific services.

[0177] IaaS can include one or more of the following: virtual machines, compute instances, or cloud servers. PaaS can include one or more of the following: application hosting, application services, or cloud-native application platforms. SaaS can include one or more of the following: email and productivity suites, office applications, or collaboration tools. DBaaS can include one or more of the following: managed databases, database services, or database platforms. Container orchestration services can include one or more of the following: container orchestration platforms or cluster management services. Serverless computing services can include one or more of the following: Function as a Service (FaaS) or serverless computing architectures. Storage services can include one or more of the following: object storage, block storage, or file storage. CDN services can include one or more of the following: content delivery services, content caching services, streaming and media delivery services, or content automation services. IAM services can include one or more of the following: authentication or authorization services, identity management services, or federated identity services. Networking services can include one or more of the following: VPC services or Software-Defined Networking (SDN) services. Machine learning services may include one or more of the following: machine learning platforms, model training services, automated model selection or configuration services, AI integration services, model monitoring or management services, or deep learning services. Big data or analytics services may include one or more of the following: data warehouse services, analytics platforms, or data lake services. IoT services may include one or more of the following: IoT platforms, device management services, or edge computing services. Blockchain services may include one or more of the following: blockchain platforms, distributed ledger services, smart contract services, security or cryptographic services, or tokenization services. Monitoring or logging services may include one or more of the following: monitoring services, logging services, or application performance monitoring services.

[0178] As used herein, the term "service characteristic" refers to the features, functionality, capabilities, properties, parameters, or aspects of a service. Service characteristics can contribute to the operation, output, state, or quality of a service. Service characteristics can be related to the service at build time and / or runtime. In one example, a service can be a service characteristic relative to one or more other services.

[0179] In one example, service characteristics (such as service characteristics related to the service's build time) include one or more of the following: dependency management characteristics, build automation characteristics, code compilation characteristics, code quality characteristics, unit testing characteristics, artifact generation characteristics, configuration management characteristics, continuous integration characteristics, code packaging characteristics, dependency scanning characteristics, documentation generation characteristics, code obfuscation characteristics, version control characteristics, tagging characteristics, or build-time optimization characteristics.

[0180] Additionally or alternatively, service characteristics (such as service characteristics related to the service runtime) include one or more of the following: deployment characteristics, authentication characteristics, authorization security characteristics, encryption characteristics, compliance characteristics, content delivery characteristics, content caching characteristics, logging characteristics, auditing characteristics, disaster recovery characteristics, scalability characteristics, virtualization characteristics, automation characteristics, machine learning integration characteristics, reliability characteristics, availability characteristics, fault tolerance characteristics, data redundancy characteristics, response time characteristics, throughput characteristics, data encryption characteristics, performance monitoring characteristics, performance optimization characteristics, resource utilization characteristics, load balancing characteristics, or patch management characteristics.

[0181] Additionally or alternatively, service characteristics (such as those related to the service's runtime and build time) include one or more of the following: resource management characteristics, error handling and logging characteristics, dynamic configuration characteristics, thread management characteristics, session management characteristics, caching characteristics, connection pooling characteristics, or adaptive security characteristics.

[0182] C. Example Cloud Infrastructure Protection Utility

[0183] refer to Figure 11C The system 1100, which includes a cloud infrastructure protection utility 1120, is further described according to one or more embodiments. Figure 11C The illustration depicts the features of cloud infrastructure 1102, which includes a virtual cloud network 1106, in which partition 1118 is deployed. (See diagram for details.) Figure 11C As shown, partition 1118 includes a cloud infrastructure protection utility 1120, a data corpus 1126, and a carrier equipment interface 1128. Furthermore, partition 1118 includes one or more services 1122 and corresponding service features 1124. As an example, Figure 11C Services 1122a and 1122c are shown. Furthermore, Figure 11C Service features 1124a and 1124b of service 1122a are shown, as are service features 1124c and 1124d of service 1122c. Additionally, refer to... Figure 11C The cloud infrastructure 1102 described may include references Figure 11A and / or Figure 11B One or more additional components, features, or functions are described.

[0184] The cloud infrastructure protection utility 1120 may include one or more of the following: a mapping module 1130, a weighting module 1132, a metric calculation module 1134, an event detection module 1136, or a service selection module 1138. Additionally, the cloud infrastructure protection utility 1120 includes an event mitigation interface 1140. See below for reference. Figure 15Further description of example event mitigation interface 1140.

[0185] The cloud infrastructure protection utility 1120 detects triggering events that threaten the operability of cloud infrastructure 1102. Furthermore, the cloud infrastructure protection utility 1120 performs mitigation processing to mitigate the impact of the triggering events. The mitigation processing includes selecting one or more services 1122 from a set of candidate services 1122 for stopping execution, to at least partially mitigate the impact of the triggering events. The cloud infrastructure protection utility 1120 may determine multiple sets of candidate and / or services 1122 for stopping based at least in part on one or more datasets stored in a data corpus 1126. The datasets stored in the data corpus 1126 may be generated based on input from the operator equipment interface 1128. Additionally or alternatively, the datasets stored in the data corpus 1126 may be based on input from an environmental monitoring system 1110 (…). Figure 11A This is generated from sensor data or other information. (See reference) Figures 12A-12C Further description of the example data corpus 1126.

[0186] In one example, system 1100, including one or more components of cloud infrastructure protection utility 1120, is deployed to virtual cloud network 1106, simultaneously or subsequently, partition 1118 is deployed to virtual cloud network 1106. In one example, a first entity deploys partition 1118 and system 1100 including one or more components of cloud infrastructure protection utility 1120, and then delegates operation of partition 1118 to a second entity. In one example, the first entity is a cloud infrastructure provider, and the second entity is a PLC operator or customer. The second entity utilizes cloud infrastructure protection utility 1120 to operate partition 1118. In one example, the second entity accesses the event mitigation interface 1140 of cloud infrastructure protection utility 1120, for example, to input and / or retrieve information related to the operation of cloud infrastructure protection utility 1120. In one example, the first and second entities may be distinguished based on identity resources of the cloud environment. A set of identity resources of the cloud environment may include a first identity domain corresponding to the first entity and a second identity domain corresponding to the second entity. Partition 1118, including the cloud infrastructure protection utility 1120 deployed to partition 1118, can be accessed based on the second identity domain corresponding to the second entity.

[0187] i. Example Mapping Module

[0188] In one example, mapping module 1130 generates mappings associated with service 1122 and service feature 1124. In one example, the mappings may identify service 1122 and its individual service features 1124. The mappings may define relationships, dependencies, and / or communication channels between service features 1124 and / or service 1122. In one example, the mappings are generated based on input from the operator via operator equipment interface 1128. Additionally or alternatively, mapping module 1130 may include one or more mapping utilities for generating mappings between service features 1124 and service 1122. These one or more mapping utilities may include service discovery utilities, configuration management utilities, orchestration platforms, or event-driven architecture utilities. In one example, mapping module 1130 utilizes these one or more mapping utilities to dynamically update the mappings. The mappings may be dynamically updated as different services 1122 and / or service features 1124 in partition 1118 are provisioned and / or deprovisioned. (See reference...) Figure 12A Further description of the example mapping.

[0189] In one example, mapping module 1130 generates a dependency graph indicating the dependencies between service 1122 and / or service feature 1124. In one example, the dependency graph may include dependencies between different service features 1124. Additionally or alternatively, the dependency graph may include dependencies between different services 1122. In one example, the dependency graph is generated based on input from the operator via operator equipment interface 1128. Additionally or alternatively, mapping module 1130 may include one or more dependency graph utilities for generating the dependency graph between service features 1124 and / or service 1122. The one or more dependency graph utilities may include service discovery utilities, configuration management utilities, orchestration platforms, or event-driven architecture utilities. In one example, mapping module 1130 utilizes one or more dependency graph utilities to dynamically update the dependency graph. The dependency graph may be dynamically updated as different services 1122 and / or service features 1124 in partition 1118 are provisioned and / or deprovisioned. (See reference...) Figure 12B and Figure 12C Further describe the example dependency graph.

[0190] ii. Example weighted module

[0191] Weighting module 1132 assigns weights to various weighting items. Weighting items may include services 1122, service features 1124, and / or alert parameters. Additionally or alternatively, weighting items may include mappings, dependencies, and / or nodes. The weight assigned to a weighting item may represent the importance, significance, value, or influence of that weighting item within a given context. A relatively high weight may indicate that the weighting item is relatively more important, more meaningful, more valuable, or more influential. A relatively low weight may indicate that the weighting item is relatively less important, less meaningful, less valuable, or less influential. The weights assigned to weighting items may be stored in a data corpus 1126. In one example, the weights are stored in association with mappings and / or dependency graphs stored in the data corpus 1126.

[0192] In one example, the weight assigned to a weighted item (e.g., service 1122 or service feature 1124) may represent the importance or value of that weighted item to one or more components or operations in the cloud environment. The weight assigned to service feature 1124 of service 1122 may represent the importance or value of that service feature 1124 to service 1122. The weight assigned to service 1122 may represent the importance or value of service 1122 to one or more operational aspects of the cloud environment. Additionally or alternatively, the weight assigned to service 1122 may represent the importance or value of service 1122 to one or more business activities that depend on service 1122.

[0193] In one example, the weight assigned to a weighted item (e.g., service 1122, service feature 1124, or alert parameter) can represent the impact or significance of that weighted item on one or more components or operations in the cloud environment. The weight assigned to service feature 1124 of service 1122 can represent the impact or significance of that service feature 1124 on one or more corresponding services 1122. Additionally or alternatively, the weight assigned to service feature 1124 of service 1122 can represent the impact or significance of that service feature 1124 on one or more downstream service features 1124.

[0194] The weighting module 1132 can assign weights to various nodes, mappings, and / or dependencies. The weight assigned to a particular node may depend on one or more neighboring nodes. In one example, service 1122 is mapped to a first service feature 1124 assigned a first weight and a second service feature 1124 assigned a second weight. Furthermore, the first weight is greater than the second weight. A first weight greater than the second weight indicates that the first service feature 1124 is more important, meaningful, valuable, or influential than the second service feature 1124 relative to service 1122. In one example, upstream service feature 1124 may have a first weight relative to a first downstream service feature 1124 and a second weight relative to a second downstream service feature 1124. The weight difference between the first and second downstream service features 1124 can indicate that the upstream service feature 1124 is more important, more meaningful, more valuable, or has a greater influence on the first downstream service feature 1124 than on the second downstream service feature 1124. Additionally or alternatively, downstream service feature 1124 may have a first weight relative to the first upstream service feature 1124 and a second weight relative to the second upstream service feature 1124. The weight difference between the first upstream service feature 1124 and the second upstream service feature 1124 may indicate that the importance, significance, value, or influence of the first upstream service feature 1124 relative to the downstream service feature 1124 is greater than the importance, significance, value, or influence of the second upstream service feature on the downstream service feature 1124.

[0195] In one example, the weights assigned to weighted items (e.g., service 1122, service feature 1124, or alarm parameters) are generated based on input from the operator via operator equipment interface 1128. Weighted items may include user-defined weights, such as user-defined valuations, user-defined importance, user-defined significance, and / or user-defined impact. User-defined weights may differ between different partitions. In one example, different tenants (such as PLC operators or customers) may assign different user-defined weights to different services and / or different instances of services. Tenants may determine user-defined weights based on the context of the service, service feature, cloud operation, or tenant's business activities. In one example, weighted items may include user-defined business value. The user-defined business value of a weighted item can represent the importance, significance, value, or impact of that weighted item on the tenant's business or operations. The relative importance, significance, value, or impact of various weighted items may differ between tenants, for example, based on differences in business or operations between different tenants and / or differences in priority between different tenants.

[0196] In one example, weighting module 1132 may include one or more weighting utilities that generate weights for different weighting items. One or more weighting utilities can dynamically update the weights of the weighting items. The weighting items can be dynamically updated based on parameters of the cloud environment. In one example, weighting module 1132 dynamically updates the weights of one or more weighting items based on one or more parameters of the following types: events, states, log entries, metrics, thresholds, algorithms, or patterns. In one example, weighting module 1132 dynamically updates the weights of one or more weighting items based on the operational state and / or changes in the operational state of one or more services 1122 and / or service features 1124 corresponding to the weighting item. For example, weighting module 1132 can dynamically update the weight of service feature 1124 in response to service 1122 initiating the use of service feature 1124 and / or in response to service pausing or terminating the use of service feature 1124. Weighting module 1132 can detect the transition of a service feature from a stopped or paused operational state to an initialized or running operational state, and vice versa. When service feature 1124 is in a stopped or paused operation state, weighting module 1132 can assign a relatively low weight to service feature 1124, for example, based on the fact that service feature 1124 is not being used by service 1122. A relatively low weight can indicate that service feature 1124 has relatively low importance, significance, value, or impact when the service feature is in a stopped or paused operation state. Weighting module 1132 can assign a relatively high weight to service feature 1124 when service feature 1124 is in an initialization or running operation state, for example, based on the fact that service feature 1124 is being used by service 1122. A relatively high weight can indicate that service feature 1124 has relatively high importance, significance, value, or impact when the service feature is in an initialization or running operation state. As another example, weighting module 1132 can assign another weight to service feature in response to determining that service feature transitions from an initialization or running operation state to an error or update operation state. Weighting module 1132 can detect when service feature transitions from an initialization or running operation state to an error or update operation state, and vice versa. Differences in weights can represent the difference in importance, significance, value, or impact of a service between an initialization or running operation state and an error or update operation state.

[0197] In one example, weighting module 1132 can utilize a machine learning model to determine the weights and / or weighting metrics of various weighting terms. An example machine learning model will be described further below. References will be provided below. Figure 13A and 13B Further description of the example weighted metric.

[0198] iii. Example metric calculation module

[0199] The metric calculation module 1134 calculates metrics for various services 1122 and / or service features 1124. In one example, the metric calculation module 1134 calculates weighted metrics associated with services 1122 and / or service features 1124, for example, based at least in part on the weights assigned to weighted items by the weighting module 1132. Example weighted metrics will be referenced below. Figure 13A and 13B Further description. Additionally or alternatively, the metric calculation module 1134 may calculate health metrics based on alarm data related to alarm parameters obtained from telemetry services and / or messaging services. Additionally or alternatively, the metric calculation module 1134 may calculate weighted metrics based at least in part on health metrics associated with service 1122 and / or service feature 1124.

[0200] In one example, the metric calculation module 1134 calculates a weighted metric for service 1122 based on the weights of one or more service features 1124 assigned to service 1122. Additionally or alternatively, the metric calculation module 1134 may calculate a weighted metric for service 1122 based on the weights of one or more upstream service features 1124 and / or one or more downstream service features 1124 that share dependencies with a specific service feature 1124 of service 1122. In one example, the metric calculation module 1134 calculates a weighted metric for service 1122 based on health metrics determined for service 1122 and / or one or more service features 1124 of service 1122. Additionally or alternatively, the metric calculation module 1134 may calculate a weighted metric for service 1122 based on health metrics determined for one or more upstream service features 1124 and / or one or more downstream service features 1124 that share dependencies with the service feature 1124 of service 1122.

[0201] The metric calculation module 1134 can store weighted metrics of various services 1122 in the data corpus 1126. Additionally or alternatively, the metric calculation module 1134 can transmit the weighted metrics to the service selection module 1138, for example, to select services 1122 to be stopped based on the weighted metrics, in order to mitigate the impact of the triggering event on the cloud infrastructure 1102.

[0202] iv. Example event detection module

[0203] Event detection module 1136 detects triggering events for the operability of threat cloud infrastructure 1102. In one example, event detection module 1136 bases its detection on events from environmental monitoring system 1110 (…). Figure 11AThe event detection module 1136 detects trigger events based on sensor data or other information from the cloud infrastructure 1102. Alternatively or additionally, the event detection module 1136 may detect trigger events based on the current, planned, or predicted utilization of the cloud infrastructure 1102. Alternatively or additionally, the event detection module 1136 may utilize a machine learning model to predict trigger events. The machine learning model may be based on data from the environmental monitoring system 1110 (…). Figure 11A Sensor data or other information, and / or based on the current, planned or predicted utilization of cloud infrastructure 1102 to predict triggering events.

[0204] Event detection module 1136 can determine the occurrence of a triggering event by comparing sensor data from environmental monitoring system 1110 with a threshold. The threshold may correspond to a limitation or constraint associated with the operability of at least a portion of cloud infrastructure 1102. In one example, event detection module 1136 compares a temperature value corresponding to a sensor monitoring the temperature associated with cloud infrastructure 1102 with a temperature threshold representing a temperature limit for preventing temperature-related damage to cloud infrastructure 1102. When the temperature value reaches the temperature threshold, event detection module 1136 determines that a triggering event has occurred. In one example, the event detection module receives data from environmental monitoring system 1110 (… Figure 11A An alarm is issued by the environmental monitoring system 1110. This alarm indicates the occurrence of an event or situation that threatens, interferes with, or inhibits the operability of at least a portion of the cloud infrastructure 1102. The event detection module 1136 responds to receiving an alarm from the environmental monitoring system 1110. Figure 11A Alarms are used to determine when a triggering event occurs.

[0205] In one example, the event detection module 1136 is based, for instance, on information from the environmental monitoring system 1110 ( Figure 11A The information determines one or more characteristics of the triggering event. The characteristics of the triggering event may include one or more of the following: whether the triggering event represents a large-scale or isolated impact on cloud infrastructure 1102, the portion of cloud infrastructure 1102 affected by the triggering event, and the nature or cause of the triggering event. The nature or cause of the triggering event may indicate whether the triggering event is associated with weather, environmental conditions, equipment failure or malfunction, operating conditions of cloud infrastructure 1102, improper behavior, or human error.

[0206] In one example, when the detection module 1136 detects the occurrence of a triggering event, the event detection module 1136 transmits a message to the service selection module 1138, which includes information related to the triggering event. The information related to the triggering event may include indications that the event detection module 1136 has detected the triggering event and / or one or more characteristics of the triggering event.

[0207] v. Example Service Selection Module

[0208] The service selection module 1138 identifies multiple groups of candidate services 1122 as candidates for stopping operations in the cloud environment to mitigate the impact of triggering events on the cloud infrastructure 1102. Furthermore, the selection module 1138 selects the service 1122 to be stopped from these multiple groups of candidate services 1122.

[0209] A set of candidate services 1122 may include all or part of the services 1122 executed in partition 1118. In one example, service selection module 1138 may determine candidate services 1122 based on a set of candidate criteria. Service selection module 1138 may compare various services 1122 with the set of candidate criteria to determine whether each service 1122 meets the criteria to be included in the set of candidate services 1122. Candidate criteria may include one or more criteria for determining whether a particular service 1122 is suitable or unsuitable for being stopped and restarted.

[0210] In one example, candidate criteria may exclude service 1122 from a set of candidate services 1122 based on one or more of the following: downstream services performing in the cloud environment depend on service 1122; downstream service features depend on service 1122 or service feature 1124 of service 1122; service 1122 handles necessary operations that affect the overall functionality of the cloud environment; stopping service 1122 may result in data corruption or data loss; service 1122 has a long startup time; service 1122 includes stateful operations, session data, or real-time processing; service 1122 is consuming a significant portion of the resources in the cloud environment, making stopping the service likely to cause resource contention issues or affect the performance of other services 1122; or service 1122 is utilizing a negligible portion of the resources in the cloud environment, making stopping the service a negligible contribution to mitigating the impact of the triggering event on the cloud infrastructure.

[0211] In one example, a candidate criterion may be used to include service 1122 in a set of candidate services 1122 based on one or more of the following: service 1122 operates in a stateless manner; service 1122 does not depend on session data or state information between maintenance requests; service 1122 does not depend on downstream services; service characteristic 1124 of service 1122 does not depend on downstream service characteristics; service 1122 can gracefully stop operation; service 1122 has a fast start-up time; service 1122 has a fault-tolerant design; service 1122 is isolated from necessary operations in the cloud environment; or service 1122 is consuming a meaningful portion of resources in the cloud environment such that stopping the service would make a meaningful contribution to mitigating the impact of the triggering event on the cloud infrastructure.

[0212] Service selection module 1138 can include or exclude services 1122 from a set of candidate services 1122 based on various combinations of candidate criteria. In one example, service selection module 1138 can expand the candidate criteria to provide a suitable set of candidate services 1122. In one example, service selection module 1138 can utilize a relatively strict set of candidate criteria when a relatively small set of candidate services 1122 is appropriate. For example, a relatively small set of candidate services 1122 might be appropriate when the impact of the triggering event on cloud infrastructure 1102 can be mitigated by stopping a relatively small number of services 1122. Additionally or alternatively, service selection module 1138 can utilize a relatively inclusive set of candidate criteria when a relatively large set of candidate services 1122 is appropriate. For example, a relatively large set of candidate services 1122 might be appropriate when it is necessary to stop a relatively large number of services 1122 to significantly mitigate the impact of the triggering event on cloud infrastructure 1102.

[0213] Service selection module 1138 can determine candidate criteria based on weighted metrics assigned to candidate criteria. Weighted metrics can be used to include and / or exclude various candidate criteria to obtain a suitable set of candidate services 1122. Weighted metrics can be assigned to candidate criteria by weighting module 1132. The weights assigned to candidate criteria can include user-defined weights, such as user-defined valuation, user-defined importance, user-defined significance, and / or user-defined impact. User-defined weights may vary across different partitions. In one example, different tenants (such as PLC operators or customers) can provide different user-defined weights for different candidate criteria. Tenants can determine user-defined weights based on the service context, service characteristics, cloud operations, or tenant business activities. Additionally or alternatively, weighting module 1132 can utilize one or more weighting utilities to generate weights for various candidate criteria.

[0214] In one example, service selection module 1138 may determine a mitigation target, which represents the target mitigation level of the impact of the triggering event on cloud infrastructure 1102. Additionally or alternatively, service selection module 1138 may determine the extent to which stopping a corresponding candidate service 1122 can mitigate the impact of the triggering event on cloud infrastructure 1102. Service selection module 1138 may calculate mitigation factors for the candidate services 1122, each representing the extent to which stopping a particular candidate service 1122 can mitigate the impact of the triggering event on cloud infrastructure 1102. Service selection module 1138 may determine a set of candidate services 1122 based on the mitigation target and / or the mitigation factors of various services 1122. In one example, service selection module 1138 includes a number of services 1122 in a set of candidate services 1122 such that the combined mitigation factor of that number of services 1122 meets or exceeds the mitigation target. Alternatively or additionally, the service selection module 1138 may include a number of services 1122 from a set of candidate services 1122, such that the combined mitigation factor of that number of services 1122 is higher than the mitigation target by a threshold size. The threshold may provide an appropriate number of services 1122 from a set of candidate services 1122.

[0215] Service selection module 1138 can select a service 1122 to be stopped from a set of candidate services 1122, at least in part, based on weighted metrics corresponding to services 1122 respectively. Service selection module 1138 may obtain the weighted metrics from metric calculation module 1134 and / or data corpus 1126. In one example, service selection module 1138 may select a service 1122 with a lower weighted metric relative to one or more other candidate services 1122 to stop. A lower weighted metric for service 1122 may indicate that stopping service 1122 may have a smaller impact on, for example, operations performed in partition 1118 of a cloud environment and / or business activities dependent on operations performed in partition 1118 of a cloud environment. Additionally or alternatively, service selection module 1138 may select a service 1122 to be stopped based on mitigation factors corresponding to services 1122 respectively. In one example, service selection module 1138 may select a service 1122 with a higher mitigation factor relative to one or more other candidate services 1122 to stop. Additionally or alternatively, the service selection module 1138 may select a service 1122 to be stopped based on a combination of weighted metrics and mitigation factors. The service selection module 1138 may select one or more services 1122 to be stopped that are sufficient to mitigate the impact of the triggering event on the cloud infrastructure 1102, while having a relatively small impact on operations performed in partition 1118 of the cloud environment and / or business activities that depend on operations performed in partition 1118 of the cloud environment.

[0216] In one example, after selecting one or more services 1122 to be stopped, the service selection module 1138 can initiate a stop process to stop the operation of one or more services 1122. The stop process may include stopping operations that depend on the specific service being stopped. The stop operation for stopping service 1122 may include one or more of the following: backing up and / or exporting data associated with service 1122, notifying stakeholders that service 1122 is about to be stopped, obtaining approval from stakeholders to stop service 1122, scheduling the time to stop service 1122, or stopping the execution of service 1122.

[0217] vi. Event mitigation interface

[0218] The event mitigation interface 1140 generates and displays a visual representation of various information related to detected triggering events and services that can be stopped to mitigate the impact of the triggering events on cloud infrastructure 1102. The information generated and displayed by the event mitigation interface 1140 may include an indication that a triggering event has been detected. Furthermore, the information generated and displayed by the event mitigation interface 1140 may identify one or more services 1122 as candidates for ceasing operations in the cloud environment. Additionally, the information generated and displayed by the event mitigation interface 1140 may include weighted metrics, mitigation factors, rankings, and operational status for one or more services 1122, respectively. References will follow below. Figure 15 Further description of example event mitigation interface 1140.

[0219] C. Example carrier equipment interface

[0220] In one example, the carrier equipment interface 1128 may be coupled or communicatively coupled to the cloud infrastructure protection utility 1120. The carrier equipment interface 1128 may include hardware and / or software configured to facilitate interaction between the carrier and other aspects of the cloud infrastructure protection utility 1120 and / or system 1100. The carrier equipment interface 1128 may render user interface elements and receive input via these user interface elements. For example, the carrier equipment interface 1128 may display output generated by the cloud infrastructure protection utility 1120. Additionally or alternatively, the carrier equipment interface 1128 may be configured to receive input to the cloud infrastructure protection utility 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 switches, text fields, date and time pickers, command lines, sliders, pages, or forms. The carrier equipment interface 1128 may utilize any one or more of these interfaces or interface elements.

[0221] In one embodiment, different components of the operator equipment interface 1128 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 stylesheet language (such as Cascading Style Sheets (CSS)). Alternatively, the operator equipment interface 1128 may be specified using one or more other languages ​​(such as Java, C, or C++).

[0222] In one example, the cloud infrastructure protection utility 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 virtual machine. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, function-specific hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translation (NAT), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handheld terminals, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication management equipment, routers, switches, controllers, access points, and / or browser devices.

[0223] D. Example machine learning model

[0224] Further reference Figure 11C In one example, cloud infrastructure protection utility 1120 may include and / or utilize at least one machine learning model 1142. Figure 11CAs shown, machine learning model 1142 is depicted as residing within partition 1118. Alternatively, the machine learning model 1142 utilized by the cloud infrastructure protection utility may reside elsewhere in the virtual cloud network 1106. The cloud infrastructure protection utility 1120 may utilize machine learning model 1142 to generate, for example, a mapping between service feature 1124 and service 1122. Alternatively, the cloud infrastructure protection utility 1120 may utilize machine learning model 1142 to generate a dependency graph of service feature 1124 and / or service 1122. Alternatively, the cloud infrastructure protection utility 1120 may utilize machine learning model 1142 to determine the weights of weighting terms (e.g., service 1122, service feature 1124, and / or candidate criteria). Alternatively, the cloud infrastructure protection utility 1120 may utilize machine learning model 1142 to determine mitigation factors for service 1122, representing the degree to which stopping a specific service 1122 can mitigate the impact of a triggering event on cloud infrastructure 1102.

[0225] Machine learning algorithm 1144 may include one or more machine learning algorithms, such as supervised and / or unsupervised algorithms. Various types of algorithms may be used, such as linear regression, logistic regression, linear discriminant analysis, classification and regression trees, Naive Bayes, k-nearest neighbors, learned vector quantization, support vector machines, bagging and random forests, boosting, backpropagation, and / or clustering. As an addition to or alternative to machine learning model 1142, cloud infrastructure protection utility 1120 may utilize one or more classical models. Classical models may include one or more classical statistical algorithms that rely on a set of assumptions about one or more of the underlying data, data generation processes, or relationships between variables. Example classical statistical algorithms may include linear regression, logistic regression, ANOVA (analysis of variance), or hypothesis testing.

[0226] In one example, machine learning algorithm 1144 can iteratively learn a target model f that optimally maps a set of input variables to output variables. Specifically, machine learning algorithm 1144 can be configured to generate and / or train machine learning model 1142. Machine learning algorithm 1144 can iteratively learn the target model f, which uses a set of training data to optimally map a set of input variables to output variables. The training data used by machine learning algorithm 1144 can be stored in a data corpus 1126. The training data can include datasets and associated labels. The datasets can be associated with the input variables of the target model f. The associated labels can be associated with the output variables of the target model f. The training data can be updated based on, for example, feedback on the accuracy of the current target model f. The updated training data can be fed back into machine learning algorithm 1144, which in turn updates the target model f.

[0227] Machine learning algorithm 1144 can generate a target model f such that the target model f best fits the training data dataset to the labels of the training data. Additionally or alternatively, machine learning algorithm 1144 can generate a target model f such that when the target model f is applied to the training data dataset, the maximum number of results determined by the target model f matches the labels of the training data. Different target models can be generated based on different machine learning algorithms 1144 and / or different sets of training data.

[0228] In one example, such as Figure 11C As shown, the cloud infrastructure protection utility 1120 may include a model trainer 1146 that utilizes one or more machine learning algorithms 1144 to generate and / or train a machine learning model 1142. In one example, the model trainer 1146 may obtain and / or generate feedback from one or more of the machine learning models 1142. The model trainer 1146 may train, update, and / or retrain one or more of the machine learning models 1142 based at least in part on this feedback. The feedback may correspond to one or more outputs of at least one machine learning model 1142. In one example, the model trainer 1146 may obtain one or more training datasets. The model trainer 1146 may train the machine learning model 1142 used by the cloud infrastructure protection utility 1120 based at least in part on the one or more training datasets.

[0229] The training dataset can be stored in the data corpus 1126. In one example, the training data may include the outputs from one or more machine learning models 1142. For example, machine learning models 1142 may be iteratively trained and / or retrained, at least in part, based on the outputs generated by one or more machine learning models 1142. As machine learning models 1142 analyze additional datasets to produce additional outputs, and as machine learning models 1142 iteratively train or retrain based on these additional outputs, machine learning models 1142 can iteratively improve over time.

[0230] In one example, training data may include one or more initial supervised learning datasets. Model trainer 1146 may train machine learning model 1142 at least in part based on one or more initial supervised learning datasets. In one example, training data may include one or more subsequent supervised learning datasets. Model trainer 1146 may update or retrain machine learning model 1142 based on one or more subsequent supervised learning datasets. One or more subsequent supervised learning datasets may be generated at least in part based on feedback corresponding to one or more outputs of machine learning model 1142.

[0231] E. Sample Data Corpus

[0232] Figures 12A-12C The illustration shows the features of the example corpus 1200. (Reference) Figures 12A-12C The described corpus 1200 can be included in the reference. Figure 11A-11C One or more embodiments are described. Additionally or alternatively, refer to... Figure 11A-11C One or more features of the described corpus 1126 may be included in the reference Figures 12A-12C The data described is in a corpus of 1200.

[0233] i. Example mapping from service characteristics to services

[0234] like Figure 12A As shown, the data corpus 1200 includes a mapping 1202. Mapping 1202 includes mapping relationships between services 1206 and service features 1208. The mapping relationships between services 1206 and service features 1208 identify specific service features 1208 of a specific service 1206.

[0235] In one example, corpus 1200 includes a mapping 1202 from a specific service feature 1208 to a specific service 1206. As an example, mapping 1202a maps service feature 1208a to service 1206a. As another example, mapping 1202b maps service feature 1208b to service 1206b. Additionally or alternatively, corpus 1200 may include a mapping 1202 that maps a specific service 1206 to a service feature 1208 of that specific service 1206. As an example, mapping 1202c maps service 1206c to service feature 1208c and service feature 1208d.

[0236] Mapping 1202 stored in data corpus 1200 represents all or a subset of services 1206 deployed in the partition. Additionally or alternatively, mapping 1202 stored in data corpus 1200 represents all or a subset of service features 1208 of a particular service 1206.

[0237] In one example, the data corpus 1200 includes a specific set of mappings 1202 that are identified as particularly relevant for selecting service 1206 as a candidate for halting operations in a cloud environment to mitigate the impact of triggering events on cloud infrastructure. The data corpus 1200 may include mappings 1202 defined by users (such as cloud operators). User-defined mappings 1202 may correspond to specific services 1206 and / or service features 1208 that the user is interested in. Additionally or alternatively, the data corpus 1200 may include mappings 1202 automatically generated by mapping utilities. Mappings 1202 automatically generated by mapping utilities may correspond to specific services 1206 and / or service features 1208 that the mapping utility determines may be of interest to users (such as cloud operators).

[0238] ii. Example dependency graph

[0239] refer to Figure 12B and 12C The data corpus 1200 may include a dependency graph that maps functional dependencies between service features. The dependency graph represents dependencies associated with one or more service features 1208. In one example, the dependency graph may include a downstream dependency graph 1210, which represents downstream dependencies 1212 of one or more service features 1208. A downstream dependency 1212 of a specific service feature 1208 indicates a downstream service feature 1208 that depends on or is affected by one or more functions or operations of that specific service feature 1208. Additionally or alternatively, in one example, the dependency graph may include an upstream dependency graph 1214, which represents upstream dependencies 1216 of one or more service features 1208.

[0240] Figure 12B The diagram 1210 illustrates an example downstream dependency relationship of service feature 1208h for service 1206h. Figure 12B The downstream dependency graph 1210 shown represents the downstream dependency 1212 of service feature 1208h. Downstream dependency 1212 identifies service feature 1208h that depends on or is affected by service feature 1206h. As an example, downstream dependency graph 1210 includes downstream dependency 1212a between service feature 1208h and service feature 1208i of service 1206i. Downstream dependency 1212a indicates that service feature 1208i depends on or is affected by service feature 1208h. As another example, downstream dependencies 1212b and 1212c indicate that service features 1208k and service feature 1208m of service 1206k both depend on or are affected by service feature 1208h.

[0241] Downstream dependencies 1212 may include one or more downstream service features 1208 that depend on or are affected by a specific service feature 1208, which in turn depends on or is affected by another service feature 1208. As an example, downstream dependency graph 1210 includes a downstream dependency 1212d between service feature 1208i of service 1206i and service feature 1208n of service 1206j, and a downstream dependency 1212e between service feature 1208i and service feature 1208p. Downstream dependencies 1212a and 1212d together indicate that service feature 1208n depends on or is affected by service feature 1208h. Furthermore, downstream dependencies 1212a and 1212e indicate that service feature 1208p depends on or is affected by service feature 1208h. Service features 1208n and / or 1208p may indirectly depend on service feature 1208h, respectively, due to the dependencies on service feature 1208i indicated by downstream dependencies 1212d and 1212e. As another example, downstream dependency 1212f between service feature 1208k of service 1206k and service feature 1208q of service 1206m indicates that service feature 1208p depends on or is affected by service feature 1208h. Service feature 1208q may indirectly depend on service feature 1208h due to the dependency on service feature 1208k indicated by downstream dependency 1212f.

[0242] Figure 12C The diagram 1214 illustrates an example upstream dependency relationship for service feature 1208t of service 1206t. Figure 12CThe upstream dependency graph 1214 shown represents the upstream dependency 1216 of service feature 1208t. Upstream dependency 1216 identifies the upstream service feature 1208 from service feature 1208t of service 1206t. Service feature 1208t depends on or is influenced by upstream service feature 1208. As an example, upstream dependency graph 1214 includes upstream dependency 1216a between service feature 1208t and service feature 1208u of service 1206u. Upstream dependency 1216a indicates that service feature 1208t depends on or is influenced by service feature 1208u. As another example, upstream dependencies 1216b and 1216c indicate that service feature 1208t depends on or is influenced by service features 1208v and service feature 1208w of service 1206v, respectively.

[0243] Upstream dependency 1216 may include one or more upstream service features 1208, which depend on or are influenced by another upstream service feature 1208. As an example, upstream dependency graph 1214 includes upstream dependency 1216d between service feature 1208u of service 1206u and service feature 1208x of service 1206x, and upstream dependency 1216e between service feature 1208u and service feature 1208y. Upstream dependencies 1216a and 1216d together indicate that service feature 1208t depends on or is influenced by service feature 1208x. Furthermore, upstream dependencies 1216a and 1216e indicate that service feature 1208t depends on or is influenced by service feature 1208y. Service feature 1208t may indirectly depend on or be indirectly affected by service features 1208x and / or service feature 1208y due to upstream dependencies indicated by upstream dependencies 1216d and 1216e, respectively. As another example, upstream dependency 1216f between service feature 1208v of service 1206v and service feature 1208z of service 1206z indicates that service feature 1208t depends on or is affected by service feature 1208z. Service feature 1208t may indirectly depend on service feature 1208z due to upstream dependency 1216f.

[0244] The data corpus 1200 may include dependency graphs of all or a subset of service features 1208 of a specific service 1206 deployed in a partition. Additionally or alternatively, the dependency graphs stored in the data corpus 1200 represent all or a subset of downstream dependencies 1212 and / or upstream dependencies 1216 among various service features 1208. In one example, the data corpus 1200 includes a specific set of dependency graphs for service features 1208 that are identified as particularly noteworthy for selecting service 1206 as a candidate for halting operations in a cloud environment to mitigate the impact of triggering events on cloud infrastructure. For example, service 1206 may be selected based on a weighted metric representing the impact of service features 1208 of service 1206 on downstream service features 1208. Additionally or alternatively, service 1206 may be selected based on a weighted metric representing the impact of upstream service features 1208 on service features 1208 of service 1206. The data corpus 1200 may include dependency graphs defined by users (such as cloud operators). These user-defined dependency graphs may correspond to specific service features 1208 and / or services 1206 that the user is interested in. Additionally or alternatively, the data corpus 1200 may include dependency graphs automatically generated by mapping utilities. These automatically generated dependency graphs may correspond to specific service features 1208 and / or services 1206 that the mapping utility determines the user (such as a cloud operator) may be interested in.

[0245] In one or more embodiments, the data corpus 1200 is any type of storage unit and / or device used to store data (e.g., a file system, database, collection of tables, or any other storage mechanism). Additionally, the data corpus 1200 may include multiple different storage units and / or devices. These multiple different storage units and / or devices may or may not be of the same type, or may be located at the same physical site. Furthermore, the data corpus 1200 can be integrated with cloud infrastructure protection utility 1120 (… Figure 11A-11C ) can be implemented or executed on the same computing system. Additionally or alternatively, the data corpus 1200 can be implemented with the cloud infrastructure protection utility 1120 ( Figure 11A-11C Implemented or executed on separate computing systems. The data corpus 1200 can be accessed via a direct connection or via a network and cloud infrastructure protection utility 1120. Figure 11A-11C Communication coupling. Information describing the data corpus 1200 can be found in system 1100 ( Figure 11A-11C This can be implemented in any component of the dataset. However, for clarity and explanation, this information is described with reference to the corpus 1200.

[0246] 4. Example Weighted Metric

[0247] refer to Figure 13A and 13B The following further describes an example weighted metric. In one example, a weighted metric represents the influence of a particular service feature on one or more downstream service features, and / or the influence of one or more upstream service features on a particular service feature. A weighted metric can represent the sum, product, or composition of one or more input parameters used to compute the weighted metric. Additionally or alternatively, one or more input parameters may include functions, operators, variables, or constants. One or more input parameters may be associated with services and / or service features. One or more input parameters may include weights applied to services and / or service features. See below for reference. Figure 13A and 13B The examples described are provided for clarity and should not be construed as limiting the scope of any claim.

[0248] A. Measurement based on the impact on downstream service characteristics

[0249] refer to Figure 13A The description further details a metric 1300 representing the impact of service features on downstream service features. Metric 1300 includes a weighted metric calculated for a service based on the weights assigned to service features and / or services. The weighted metric for a service can represent the importance, significance, value, or degree of influence of one or more service features of that service on one or more downstream services.

[0250] like Figure 13A As shown, the system calculates a weighted metric 1302a for service 1304a based on the impact of one or more service features 1306 of service 1304a on one or more downstream service features 1306 of one or more downstream services 1304a. Service 1304a includes service feature 1306a and service feature 1306b. In one example, a service feature may affect one or more downstream service features of one or more downstream services. Service feature 1306a affects downstream service feature 1306c of service 1304c. Furthermore, service feature 1306a affects downstream service feature 1306d of service 1304d. In one example, a service feature may affect multiple downstream service features of a particular downstream service. Service feature 1306b affects downstream service features 1306e and downstream service feature 1306f of service 1304e.

[0251] In one example, the system calculates a weighted metric 1302a for service 1304a based on the count of downstream service features 1306 affected by service feature 1306 of service 1304a. Additionally or alternatively, the system may calculate the weighted metric 1302a based on the dependency weights of service feature 1306. The system may determine the dependency weights of a service feature based on one or more downstream service features that depend on the service feature. In one example, the weighted metric 1302a is based on the dependency weight 1308a corresponding to service feature 1306a and / or the dependency weight 1308b corresponding to service feature 1306b.

[0252] In one example, the system determines dependency weights based on the counts of downstream service features. The system determines the counts of downstream service features and calculates dependency weights based on these counts. In one example, the dependency weight is the count of the downstream service feature. In another example, the dependency weight represents the product of the count of the downstream service feature and one or more functions, operators, variables, or constants. Alternatively or additionally, the system determines dependency weights based on the feature weights of one or more downstream service features that depend on the service feature. Alternatively or additionally, the dependency weight of the service feature can be calculated based on the feature weight of the service feature. The feature weight of service feature 1306 can represent the importance, significance, value, or impact of service feature 1306.

[0253] like Figure 13A As shown, the system calculates the dependency weight 1308a of service feature 1306a based on feature weights 1310c and 1310d. Feature weight 1310c corresponds to downstream service feature 1306c of service 1304c. Feature weight 1310d corresponds to downstream service feature 1306d of service 1304d. In one example, the dependency weight 1308a of service feature 1306a is additionally based on feature weight 1310a of service feature 1306a. In one example, dependency weight 1308a represents the sum, product, or composition of feature weights 1310a, 1310c, and 1310d. Additionally or alternatively, dependency weight 1308a may represent the product of one or more functions, operators, variables, or constants associated with service feature 1306a, downstream service feature 1306c, and / or downstream service feature 1306d. Figure 13A As shown, the value of dependency weight 1308a is (8), which represents the product of feature weight 1310c, feature weight 1310d and feature weight 1310a (e.g., 2x4x1=8).

[0254] Additional or alternative land, such as Figure 13AAs shown, the system calculates the dependency weight 1308b of service feature 1306b based on feature weights 1310e and 1310f. Feature weight 1310e corresponds to downstream service feature 1306c of service 1304e. Feature weight 1310f corresponds to downstream service feature 1306d of service 1304e. In one example, the dependency weight 1308b of service feature 1306b is additionally based on feature weight 1310b of service feature 1306b. In one example, dependency weight 1308b represents the sum, product, or composition of feature weights 1310b, 1310e, and 1310f. Additionally or alternatively, dependency weight 1308b may represent the product of one or more functions, operators, variables, or constants associated with service feature 1306b, downstream service feature 1306e, and / or downstream service feature 1306f. Figure 13A As shown, the value of dependency weight 1308b is (3), which represents the product of feature weight 1310e, feature weight 1310f and feature weight 1310b (e.g., 1x3x1=3).

[0255] In one example, such as Figure 13A As shown, the system calculates a weighted metric 1302a based on the dependency weights 1308a and 1308b of service feature 1306a. In one example, the system can calculate the weighted metric 1302a based on the service weights 1312a of service 1304a. Service weights 1312a, for example, can represent the importance, significance, value, or impact of service feature 1306a of service 1304a, or as an addition. In one example, the weighted metric 1302a represents the sum, product, or composition of dependency weights 1308a, dependency weights 1308b, and service weight 1312a. Figure 13A As shown, the value of weighted metric 1302a is (55), which represents the product of service weight 1312a and dependency weight 1308a plus the product of service weight 1312a and dependency weight 1308b (e.g., 8x5+3x5=55).

[0256] B. Measurement based on the impact from upstream service characteristics

[0257] refer to Figure 13B Furthermore, a metric 1300 is described based on the impact of upstream service features on service features. Metric 1300 includes a weighted metric calculated for the service based on the weights assigned to the service features and / or the service features themselves. The weighted metric for a service can represent the importance, significance, value, or degree of influence of one or more upstream services on the service features of that service.

[0258] like Figure 13B As shown, the system calculates a weighted metric 1302t for service 1304t based on the influence of one or more upstream service features 1306 on one or more service features 1306 of service 1304t. Service 1304t includes service feature 1306t and service feature 1306v. In one example, a service feature may be influenced by one or more upstream service features of one or more upstream services. Service feature 1306t is influenced by upstream service feature 1306w of service 1304w. Furthermore, service feature 1306t is influenced by upstream service feature 1306x of service 1304x. In one example, a service feature may be influenced by multiple upstream service features of a particular upstream service. Service feature 1306v is influenced by upstream service features 1306y and 1306z of service 1304z.

[0259] In one example, the system calculates a weighted metric 1302t for service 1304t based on the count of downstream service features 1306 affected by service feature 1306 of service 1304t. Additionally or alternatively, the system may calculate the weighted metric 1302t based on the dependency weights of service feature 1306. The system may calculate the dependency weights of a service feature based on one or more upstream service features that the service feature depends on. In one example, the weighted metric 1302t is based on the dependency weight 1308t corresponding to service feature 1306t and / or the dependency weight 1308v corresponding to service feature 1306v.

[0260] In one example, the system determines dependency weights based on the counts of upstream service features. The system determines the counts of upstream service features and calculates dependency weights based on these counts. In one example, the dependency weight is the count of the upstream service feature. In another example, the dependency weight represents the product of the upstream service feature count and one or more functions, operators, variables, or constants. Additionally or alternatively, the system determines dependency weights based on the feature weights of one or more upstream service features that the service feature depends on. Furthermore, the dependency weight of a service feature can be calculated based on the feature weight of that service feature. The feature weight of service feature 1306 can represent the importance, significance, value, or impact of service feature 1306.

[0261] In one example, such as Figure 13BAs shown, the system calculates the dependency weight 1308t of service feature 1306t based on feature weight 1310w and feature weight 1310x. Feature weight 1310w corresponds to the upstream service feature 1306w of service 1304w. Feature weight 1310x corresponds to the upstream service feature 1306x of service 1304x. In one example, the dependency weight 1308t of service feature 1306t is additionally based on the feature weight 1310t of service feature 1306t. In one example, dependency weight 1308t represents the sum, product, or composition of feature weight 1310t, feature weight 1310w, and feature weight 1310x. Additionally or alternatively, dependency weight 1308t may represent the product of one or more functions, operators, variables, or constants associated with service feature 1306t, upstream service feature 1306w, and / or upstream service feature 1306x. Figure 13A As shown, the value of dependency weight 1308t is (9), which represents the product of feature weight 1310w, feature weight 1310x and feature weight 1310t (e.g., 3x3x1=9).

[0262] Additional or alternative land, such as Figure 13B As shown, the system calculates the dependency weight 1308v of service feature 1306v based on feature weight 1310y and feature weight 1310z. Feature weight 1310y corresponds to the upstream service feature 1306y of service 1304z. Feature weight 1310z corresponds to the upstream service feature 1306z of service 1304z. In one example, the dependency weight 1308v of service feature 1306v is additionally based on the feature weight 1310v of service feature 1306v. In one example, dependency weight 1308v represents the sum, product, or composition of feature weight 1310v, feature weight 1310y, and feature weight 1310z. Additionally or alternatively, dependency weight 1308v may represent the product of one or more functions, operators, variables, or constants associated with service feature 1306v, upstream service feature 1306y, and / or upstream service feature 1306z. Figure 13A As shown, the value of dependency weight 1308v is (2), which represents the product of feature weight 1310y, feature weight 1310z and feature weight 1310v (e.g., 2x1x1=2).

[0263] In one example, such as Figure 13BAs shown, the system calculates a weighted metric 1302t based on the dependency weights 1308t of service feature 1306t and the dependency weights 1308v of service feature 1306v. In one example, the system can calculate the weighted metric 1302t based on the service weights 1312t of service 1304t. The service weights 1312t, for example, can represent the importance, significance, value, or impact of service feature 1306 of service 1304t, either in addition to representing or as an appendage. In one example, the weighted metric 1302t represents the sum, product, or composition of dependency weights 1308t, dependency weights 1308v, and service weight 1312t. Figure 13A As shown, the value of the weighted metric 1302t is (33), which represents the product of the service weight 1312t and the dependency weight 1308t plus the product of the service weight 1312t and the dependency weight 1308v (e.g., 3x9+3x2=33).

[0264] 5. Example Operations for Cloud Infrastructure Protection

[0265] refer to Figure 14A and 14B Example operation 1400 is further described according to one or more embodiments. In one example, the system may perform operation 1400 related to cloud infrastructure protection, including operation 1400 related to triggering events that respond to threats to the operability of the cloud infrastructure. Reference Figure 14A and 14B One or more operations 1400 described may be modified, combined, rearranged, or omitted. Therefore, refer to... Figure 14A and 14B The specific order of operations 1400 described should not be construed as limiting the scope of one or more embodiments. In one example, operations 1400 may be derived from references... Figure 11A-11C One or more components of the system described are executed.

[0266] refer to Figure 14AThe system detects the occurrence of a triggering event that threatens the operability of at least a portion of the cloud infrastructure (Operation 1402). The system may detect the triggering event based on sensor data from an environmental monitoring system or other information. In one example, the triggering event includes one or more of the following: severe weather, heat wave, storm, natural disaster, cold wave, hurricane, blizzard, tornado, dust storm, flood, fire, explosion, wind, rain, snow, ice, haze, or smoke. Additionally or alternatively, the triggering event may include one or more of the following: hardware failure, power outage, utility interruption, switch to backup power, power supply limitation, voltage drop, power outage, cloud infrastructure interruption, cooling system failure, ventilation system failure, heating system failure, network interruption, software error, cybersecurity incident, security vulnerability, system upgrade or maintenance event.

[0267] In response to the detection of a triggering event, the system executes mitigation procedures (Operation 1404) to mitigate the impact of the triggering event. Mitigation procedures include stopping one or more services in the cloud environment. See below for reference. Figure 14B Example operation 1400 further describes the mitigation process. In one example, during and / or after the mitigation process, the system determines whether the impact of the triggering event has been adequately mitigated (operation 1406). When the system determines that the impact of the triggering event has not been adequately mitigated, the system continues with the mitigation process at operation 1404. When the system determines that the impact of the triggering event has been adequately mitigated, the system resumes the operation of one or more services (operation 1408).

[0268] refer to Figure 14B The example operation 1400 for mitigation processing is further described. For example... Figure 14B As shown, the system identifies a set of candidate services as candidates for a stop operation (Operation 1410). This set of candidate services can be determined based on candidate criteria used to determine whether a particular service is suitable for being stopped and restarted. The system ranks the set of candidate services based at least on weighted metrics associated with each service characteristic (Operation 1412). Based at least on this ranking, the system selects the service from the set of candidate services for the stop operation (Operation 1414). The system can identify the service characteristics of the set of candidate services based on a mapping from candidate services to the service characteristics of each candidate service. This mapping can be stored in a data repository and / or in metadata associated with each service. The system can generate the ranking based on the weights assigned to each service characteristic.

[0269] After selecting a service to stop the operation, the system stops the operation of the selected service to at least partially mitigate the triggering event (operation 1416). The system can stop the operation of the selected service by executing a stop procedure corresponding to the selected service. The stop procedure may include one or more of the following stop operations: backing up and / or exporting data associated with service 1122, notifying stakeholders that service 1122 is about to be stopped, obtaining approval from stakeholders to stop service 1122, scheduling the time to stop service 1122, or stopping the execution of service 1122.

[0270] During or after the operation of stopping the selected service, the system determines whether the impact of the triggering event has been sufficiently mitigated (operation 1418). When the system determines that the impact of the triggering event has not been sufficiently mitigated, the system selects another service from the group of candidate services to stop the operation (operation 1414). When the system determines that the impact of the triggering event has been sufficiently mitigated, the system resumes the operation of the one or more services that were stopped (operation 1408). The system can resume the operation of the one or more stopped services by starting the services incrementally, such as starting them in the reverse order of service stopping. Additionally or alternatively, the stopped services can be started together as a group. Starting a service may include one or more of the following: transmitting instructions to the service to resume the operation of the service, notifying stakeholders that the service has been started, or increasing the utilization of the service.

[0271] In one example, the triggering event includes high temperature associated with at least a portion of the cloud infrastructure, and stopping one or more services at least partially alleviates the high temperature. In another example, the triggering event includes an interruption associated with at least a portion of the cloud infrastructure, and stopping services at least partially alleviates resource constraints associated with resource parameters of the cloud environment.

[0272] In one example, the ranking for selecting the service to stop is also based on feature weights associated with one or more downstream service features that depend on one or more service features of each candidate service. The system can determine feature weights based on a dependency graph that plots the dependencies between services and service features. In one example, the ranking is also based on feature measures representing the operational impact associated with each service feature of the group of candidate services. In one example, the corpus includes foreign keys representing service features, which correspond to primary keys in the dependency graph representing those service features. The system can determine foreign keys based on the mapping between service features and services. The system can determine one or more downstream service features by traversing the dependency graph and retrieving values ​​corresponding to downstream service features.

[0273] In one example, the system determines a ranking adjustment for one or more services from a set of candidate services based on one or more prior occurrences of a specific service being stopped due to one or more previously triggered events. The system may adjust the ranking to prevent a specific service from being stopped repeatedly. As a result of the ranking adjustment, one or more services may be ranked higher than they would have been if the ranking had not been adjusted, and / or one or more services may be ranked lower than they would have been if the ranking had not been adjusted.

[0274] 6. Example event mitigation interface

[0275] Figure 15 An example event mitigation interface according to one or more embodiments is illustrated. This example event mitigation interface can be used for cloud infrastructure protection, including responding to triggering events that threaten the operability of the cloud infrastructure. The event mitigation interface can be used to monitor system operation and / or initiate and / or approve system actions, such as stopping services performing in the cloud environment, to at least partially mitigate the impact of the triggering event on the cloud infrastructure. References Figure 15 The examples provided are for clarity only. References Figure 15 The described components and / or operations should be understood as examples and may not be applicable to some embodiments. Therefore, references Figure 15 The described components and / or operations should not be construed as limiting the scope of any claim.

[0276] like Figure 15 As shown, in one example, the event mitigation interface 1500 instructs the mitigation console 1502 to display information related to the triggered event. Figure 15 As shown, the mitigation console 1502 indicates the occurrence of triggering event 1504. As an example, triggering event 1504 is a heat wave. Furthermore, the mitigation console 1502 indicates a mitigation target 1508 for mitigating triggering event 1504. Mitigation target 1508 may correspond to a specific partition 1506 in the cloud environment. In one example, as... Figure 15As shown, the value of mitigation target 1508 for partition P1 is (15). Furthermore, the mitigation console 1502 includes a ranking 1510 of a set of services 1512 executed in partition 1506. This set of services 1512 is a candidate for stopping operations in the cloud environment to mitigate the impact of triggering event 1504 on the cloud infrastructure. In one example, the mitigation console 1502 includes a weighted metric 1514 corresponding to service 1512. The weighted metric 1514 may represent the importance, significance, value, or degree of impact of the corresponding service 1512 and / or the service characteristics associated with service 1512. Additionally or alternatively, the mitigation console 1502 may include a mitigation factor 1516 corresponding to service 1512. The mitigation factor 1516 may represent the degree to which triggering event 1504 can be mitigated by stopping the corresponding service 1512. The mitigation factor 1516 can be compared with the mitigation target 1508 to determine the services 1512 used to satisfy the mitigation target 1508.

[0277] In one example, the mitigation console 1502 may include suggestions 1518 corresponding to various services 1512. Suggestions 1518 may indicate whether the system recommends stopping a specific service 1512, and / or whether the system recommends that a specific service 1512 continue to operate in the cloud environment. In one example, the mitigation console 1502 may include one or more selection buttons 1520. Users can interact with the selection buttons 1520 to provide input instructing the system to continue or not continue with suggestion 1518.

[0278] like Figure 15 As shown, service 1512 is ranked according to weighted metric 1514 and displayed in mitigation console 1502 according to rank 1510. The value of weighted metric 1514 for service E is (3), and it ranks first in the ranking, indicating that the value of service E is relatively low compared to the other services included in rank 1510. In addition, mitigation console 1502 indicates that the value of mitigation factor 1516 for service E is (2). The comparison of mitigation factor 1516 for service B with mitigation target 1508 (15) indicates that stopping service E may contribute little to mitigating the impact of the triggering event on the cloud infrastructure. Figure 15 As shown, the system recommends continuing service E in the cloud environment. Additionally, the system recommends stopping service A. The recommendation to stop service A (1518) may be based on a relatively low value (e.g., a value of 3) in service A's weighted metric (1514). Alternatively or additionally, the recommendation to stop service A (1518) may be based on service A's mitigation factor (1516) (a value of 7) indicating that stopping service B may significantly contribute to mitigating the impact of the triggering event on the cloud infrastructure. Figure 15As shown, the user selected selection button 1520a to provide the system with an instruction to continue stopping service A. Additionally, suggestion 1518 for service C indicates that the system recommends stopping service C. The weighted metric 1514 for service C has a value of (8). The mitigation tendency for service C is (8), indicating that stopping service C and service A would satisfy mitigation objective 1508 (e.g., 7+8=15). Figure 15 As shown, although the mitigation factor 1516 of service B is (16), satisfying the mitigation objective 1508 (15), the weighted metric 1514 of service B is (14), indicating that the value of service B for partition 1506 is higher than that of the combination of service C and service A (e.g., 5+8<14). The system's recommendation to stop service C can be based on the combination of the weighted metric 1514 and the mitigation factor 1516. In one example, the system can recommend stopping service C as well as service A to mitigate the impact of the triggering event on the cloud infrastructure. The user can provide the system with an instruction to continue stopping service C by selecting the selection button 1520b.

[0279] 7. Other matters; extension

[0280] Unless otherwise defined, all terms (including technical and scientific terms) shall be given the meanings that are common and customary to those skilled in the art, and are not limited to special or customary meanings, unless otherwise expressly defined herein.

[0281] This application may include references to certain trademarks. While the use of trademarks is permitted in a patent application, the exclusivity of the trademark should be respected, and every effort should be made to prevent the trademark from being used in any way that may adversely affect its validity.

[0282] The embodiments are directed to a system having one or more devices, which include a hardware processor and are configured to perform any of the operations described herein and / or recited in any of the following claims.

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

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

[0285] Any combination of the features and functions described herein may be used according to one or more embodiments. In the foregoing description, embodiments have been described with reference to numerous specific details that may vary depending on the implementation. Therefore, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive measure of the scope of this disclosure, and what the applicant intends to define as the scope of this disclosure, is the literal and equivalent scope of the set of claims issued in this application, in the specific form of such claims, including any subsequent corrections.

Claims

1. A method comprising: The occurrence of triggering events that threaten the operability of at least a portion of the cloud infrastructure in the cloud environment; Mitigation processing to mitigate the impact of the triggering event should be performed in at least the following ways: Identify a set of candidate services as candidates for stopping operations in the cloud environment; A ranking of the set of candidate services is generated based at least on a weighted metric associated with each service feature of the set of candidate services; Based at least on the ranking, the first service in the set of candidate services is selected to stop the operation in the cloud environment; Stop the operation of the first service in the cloud environment to at least partially mitigate the impact of the triggering event; The method is performed by at least one device including a hardware processor.

2. The method of claim 1, wherein the ranking is further based on a weighted metric associated with the set of candidate services.

3. The method of claim 1, further comprising: Before detecting the occurrence of a triggering event: receive user input, which assigns one or more weighted metrics among the weighted metrics associated with each service feature of the set of candidate services.

4. The method of claim 1, wherein the ranking is further based on a weighted metric associated with one or more service features on which one or more of the candidate services depend.

5. The method of claim 4, wherein generating the ranking comprises: Based on the dependency graph that plots the dependencies between services and service features in the cloud environment, a weighted metric is determined that is associated with each service feature of the set of candidate services.

6. The method of claim 1, wherein the ranking is further based on an operational impact metric associated with each service characteristic of the set of candidate services.

7. The method of claim 1, further comprising: Based on the fact that one or more previous occurrences of the second service in the set of candidate services have stopped due to one or more previous triggered events, the ranking adjustment corresponding to the second service is determined; Based on ranking adjustments, the rankings are adjusted, wherein the ranking adjustments result in one or more of the following: (a) the ranking of the first service is higher than the ranking without the adjustment, or (b) the ranking of the second service is lower than the ranking without the adjustment.

8. The method of claim 1, further comprising: Based on the fact that the first service stopped responding to one or more previously triggered events, determine the ranking adjustment corresponding to the first service; Based on ranking adjustments, the rankings are adjusted, wherein the ranking adjustments result in one or more of the following: (a) the ranking of the first service is higher than its ranking without adjustment, or (b) the ranking of the second service in the set of candidate services is lower than its ranking without adjustment.

9. The method of claim 1, wherein: The cloud environment is provided by the primary entity; The weighted metrics associated with each service feature of the set of candidate services are provided by a second entity; and The first entity at least partially controls the second entity's access to the cloud environment.

10. The method of claim 9, wherein: A cloud environment includes one or more partitions associated with a third entity; and The second entity at least partially controls the third entity's access to the one or more partitions.

11. 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-10.

12. 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-10.

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

Images