System and method for enforcing service control policies for services and service features

Abstract

Embodiments described herein generally relate to systems and methods for providing a cloud environment for use by tenants of a cloud infrastructure environment in accessing software products, services, or other provisioning items associated with the environment, including methods for defining and enforcing service control policies for services and service features. In accordance with an embodiment, the system includes a service control repository or service directory that provides definitions of services and service features along with service control policies or rules that define availability or access to the service features. A service control policy framework including a feature management service determines which different entities can control availability of a particular service or service feature to an end user by referring to a hierarchy of entities defining service control policies.

Description

[0001] Copyright Notice

[0002] This patent document contains copyrighted material. The copyright holder does not object to any fax reproduction of the patent document or patent disclosure as it appears in the patent documents or records of the Patent and Trademark Office, but otherwise retains all copyright.

[0003] Cross-referencing of priority claims and related applications:

[0004] This application claims U.S. Provisional Patent Application No. 63 / 462,868, 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 / 462,875, filed April 28, 2023, entitled "SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE"; and U.S. Provisional Patent Application 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 / 462,878, entitled "System and Method for Providing Dedicated Cloud Environments for Use with a Cloud Computing Infrastructure"; U.S. Provisional Patent Application No. 63 / 462,880, entitled "System and Method for Providing Dedicated Cloud Environments for Use with a Cloud Computing Infrastructure"; U.S. Provisional Patent Application No. 63 / 462,882, entitled "System and Method for Providing Dedicated Cloud Environments for Use with a Cloud Computing Infrastructure"; and U.S. Provisional Patent Application No. 63 / 462,882, entitled "System and Method for Providing Dedicated Cloud Environments for Use with a Cloud Computing Infrastructure"; all filed on April 28, 2023. U.S. provisional patent application No. 63 / 462,885, entitled "INFRASTRUCTURE";The priority interests of the United States Patent Application No. 18 / 639,811, filed April 18, 2024, entitled "SYSTEM AND METHOD FOR ENFORCING SERVICECONTROL POLICIES FOR SERVICES AND SERVICE FEATURES"; each of the foregoing applications and the contents thereof are incorporated herein by reference. Technical Field

[0005] The embodiments described herein generally relate to systems and methods for providing a cloud environment for tenants of a cloud infrastructure environment to use when accessing software products, services, or other provisioning items associated with that environment, including methods for defining and enforcing service control policies for services and service characteristics. 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.

[0007] 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; and allowing them to focus on managing their day-to-day operations. Summary of the Invention

[0008] The embodiments described herein generally relate to systems and methods for providing a cloud environment for tenants of a cloud infrastructure environment to use when accessing software products, services, or other provisioning items associated with that environment, including methods for defining and enforcing service control policies for services and service characteristics.

[0009] According to an embodiment, the system includes a service control repository or service catalog, which provides definitions of services and service features along with service control policies or rules. These policies or rules define the availability or access to service features. The service control policy framework (including a feature management service) determines which different entities can control the availability of specific services or service features to end users by referencing a hierarchy of entities that define the service control policies.

[0010] According to an embodiment, service control policies can be controlled based on the entity hierarchy or at multiple levels. At each level within the hierarchy, only entities at higher levels that have made a service feature available can be controlled by the service control policy of that level. Attached Figure Description

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

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

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

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

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

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

[0017] Figure 7 The illustration depicts a system, according to an embodiment, that provides a dedicated or privately tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0018] Figure 8 The illustration further illustrates the use of the cloud domain by tenants or customers in a cloud infrastructure environment according to an embodiment.

[0019] Figure 9 The illustration further illustrates the use of the cloud domain by tenants or customers in a cloud infrastructure environment according to an embodiment.

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

[0021] Figure 11 The illustration depicts an example cloud infrastructure environment that can utilize service control policies according to an embodiment.

[0022] Figure 12 The illustration shows how, according to an embodiment, a service or service feature can be enabled or disabled based on a hierarchy of entities that define service control policies.

[0023] Figure 13 The illustration further illustrates how, according to an embodiment, services or service features are enabled or disabled based on a hierarchy of entities that define service control policies.

[0024] Figure 14The illustration depicts a process, according to an embodiment, for use with a service control policy to enable or disable the availability or access to a service or service feature.

[0025] Figure 15 The illustration depicts another process, according to an embodiment, for use with service control policies to enable or disable the availability or access to service features.

[0026] Figure 16 The illustration depicts another process, according to an embodiment, for use with service control policies to enable or disable the availability or access to service features.

[0027] Figure 17 The illustration shows how, according to an embodiment, a hierarchy of entities defining service control policies can be used to indicate whether a service or service feature is enabled, disabled, deprecated, or retired.

[0028] Figure 18 The illustration shows an example use of a service control policy within a cloud infrastructure environment according to an embodiment.

[0029] Figure 19 The illustration further illustrates an example use of service control policies within a cloud infrastructure environment according to an embodiment.

[0030] Figure 20 The illustration further illustrates an example use of service control policies within a cloud infrastructure environment according to an embodiment.

[0031] Figure 21 The illustration further illustrates an example use of service control policies within a cloud infrastructure environment according to an embodiment.

[0032] Figure 22 The illustration shows how, according to an embodiment, service control policies are used to enable or disable processing of the availability or access to service features from the perspective of a client device or console.

[0033] Figure 23 The illustration shows the use of service control policies from the perspective of a service platform to enable or disable processing of the availability or access to service features, according to an embodiment.

[0034] Figure 24 The illustration shows how, according to an embodiment, service control policies are used to enable or disable processing of the availability or access to service features from the perspective of a feature management service.

[0035] Figure 25 The illustration shows an example user interface for managing the use of service control policies within a cloud infrastructure environment, according to an embodiment.

[0036] Figure 26A sample user interface for managing the use of service control policies within a cloud infrastructure environment is further illustrated according to an embodiment.

[0037] Figure 27 A sample user interface for managing the use of service control policies within a cloud infrastructure environment is further illustrated according to an embodiment. Detailed Implementation

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

[0039] 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; and allowing them to focus on managing their day-to-day operations.

[0040] cloud infrastructure environment

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

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

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

[0044] like Figure 1 As shown, according to an embodiment, cloud infrastructure environment 100 can operate on cloud computing infrastructure 102, which includes hardware (e.g., processor, 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 106.

[0045] According to the embodiment, the cloud infrastructure environment supports the use of availability domains, such as availability domains A 180 and B 182, which enables customers to create and access cloud networks 184 and 186, and run cloud instances A 192 and B 194.

[0046] According to an embodiment, a tenancy can be created for each cloud tenant / customer (e.g., tenants A 142 and B 144), which provides a secure and isolated partition within the cloud infrastructure environment where the customer 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.

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

[0048] 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 164, 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, for example, a client device.

[0049] According to an embodiment, the computing resource layer may include resources such as, for example, bare-metal cloud instance 152, virtual machine 154, graphics processing unit (GPU) computing cloud instance 156, and / or container 158. The computing resource layer may be used, for example, 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.

[0050] For example, according to an embodiment, a cloud infrastructure environment can provide control over physical host (bare metal) machines within a computing resource tier, which run directly on bare metal servers as computing cloud instances without the need for a hypervisor.

[0051] According to an embodiment, the cloud infrastructure environment can also provide control over virtual machines within the computing resource layer, which can be booted, for example, from 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.

[0052] According to an embodiment, the network resource layer may include multiple network-related resources, such as, for example, a virtual cloud network (VCN) 165, a load balancer 167, an edge service 168, and / or a connectivity service 169.

[0053] According to an embodiment, the storage resource layer may include multiple resources, such as, for example, data / block volume 172, file storage device 174, object storage device 176 and / or local storage device 178.

[0054] 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 enables organizations or enterprise customers to operate their applications and services in a highly available managed environment.

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

[0056] For example, according to an embodiment, such an environment may include racks physically managed by a cloud infrastructure provider; customer racks; access rights for cloud operators to perform setup and hardware support; customer data center power and cooling; customer floor space; customer data center personnel area; and physical access cages.

[0057] According to the implementation, the 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 available in the cloud infrastructure provider's public cloud zone, such as ERP, finance, HCM, and SCM. Customers can seamlessly extract and replace legacy workloads using the cloud infrastructure provider's services (such as bare metal computing, VMs, and GPUs; database services, such as autonomous databases; or container-based services, such as Kubernetes container engines).

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

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

[0060] According to the embodiments, IaaS customers can access resources and services via a wide area network (WAN) such as the Internet, and can use the services of the cloud infrastructure provider 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 a database, create buckets for workloads and backups, and even install enterprise software into the 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.

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

[0062] 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 disposition (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

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

[0064] 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 configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows for creating and / or managing the different components described in the configuration files can be generated.

[0065] 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 to the network and one or more virtual machines (VMs) will be configured. 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 desired and / or added.

[0066] 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 on which the code will be deployed must first be established. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, deployment tools can be used to deploy the code.

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

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

[0069] 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 various GNU / Linux operating systems (such as, for example, Chrome). Alternatively or additionally, 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.

[0070] According to an embodiment, the VCN may include a local peering gateway (LPG) 210, which may be communicatively coupled to an SSH VCN 212 via an LPG contained in a Secure Shell (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 contained in a 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 data plane VCN may be contained in a service lease 219 that may be owned and / or operated by a cloud infrastructure provider.

[0071] 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 one or more application subnets 226, and a control plane data layer 228 that may include one or more database (DB) subnets 230 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). The one or more LB subnets included in the control plane DMZ layer may communicatively couple to the one or more application subnets included in the control plane application layer and to an Internet gateway 234 that may be included in the control plane VCN, and the one or more application subnets may communicatively couple to the one or more DB subnets included in the control plane data layer, as well as a service gateway 236 and a Network Address Translation (NAT) gateway 238. The control plane VCN may include a service gateway and a NAT gateway.

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

[0073] According to an embodiment, the data plane VCN may include a data plane application layer 246, a data plane DMZ layer 248, and a data plane data layer 250. 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 an internet gateway of the data plane VCN. The one or more application subnets may communicatively couple to a service gateway and a 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.

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

[0075] 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 may not initiate API calls to the service gateway.

[0076] According to an embodiment, a secure host lease can be directly connected to a service lease, which may 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.

[0077] 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 VNICs, which can be included in both the data plane mirror application layer and the data plane application layer.

[0078] 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 requests 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 verified 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 can be stored in one or more DB subnets.

[0079] 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 to these resources.

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

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

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

[0083] like Figure 4 As shown, according to an embodiment, a 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.

[0084] 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 cannot be configured to invoke any entity contained within the control plane VCN. The customer may expect to deploy or otherwise use resources provided in the control plane VCN within the data plane VCN, and the data plane mirror application layer may facilitate the customer's expected deployment or other use of resources.

[0085] According to one embodiment, a cloud infrastructure provider's customers can apply filters to a data plane VCN. In this embodiment, customers 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.

[0086] 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 can be isolated from other cloud services, and the control plane VCN can be isolated from cloud services that may not be in the same region as the control plane VCN.

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

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

[0089] like Figure 5 As shown, according to an embodiment, one or more trusted application subnets 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 database subnets contained in a data plane data layer. One or more untrusted application subnets 264 can be communicatively coupled to a service gateway contained in a data plane VCN and one or more database subnets contained in a 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 a data plane VCN.

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

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

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

[0093] 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 or more untrusted application subnets containing VMs), 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 may not be configured to transmit or receive data with any other entity in the data plane VCN. After the code execution is complete, the cloud infrastructure provider can dispose of these containers.

[0094] 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 in each customer's VM and may run code from the customer may not be communicatively coupled to the one or more database subnets.

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

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

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

[0098] According to an embodiment, one or more untrusted application subnets may include primary VNICs that are 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 be communicatively coupled to an application subnet that may be included in a data plane application layer 281, 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.

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

[0100] According to an embodiment, Figure 6 The pattern shown can be regarded as Figure 5 Exceptions to the pattern illustrated, and patterns that customers might expect if the cloud infrastructure provider cannot communicate directly with the customer (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 can also be isolated from other entities contained within the data plane VCN. Containers can also be isolated from resources from other customers.

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

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

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

[0104] cloud environment

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

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

[0107] While the examples described herein illustrate various systems, methods, and / or technologies that can be used in the context of providing a private tag cloud (PLC) environment, the systems, methods, and technologies described herein can be used within or with other types of cloud environments, depending on the various embodiments.

[0108] like Figure 7As shown, according to an embodiment, a cloud infrastructure provider may supply one or more cloud environments (e.g., PLC environments) or domains to an operator 320 (e.g., a cloud infrastructure customer operating as a reseller). The operator / reseller may then customize and extend the cloud environment for use by its customer 330 to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0109] For illustrative purposes, examples of such subscription-based products, services, or other offerings may include a variety of cloud infrastructure software products, such as Oracle Fusion Applications, or other types of products or services that allow customers to subscribe to use these products or services.

[0110] Figure 8 The illustration further illustrates the use of the cloud domain by tenants or customers in a cloud infrastructure environment according to an embodiment.

[0111] like Figure 8 As shown, according to an embodiment, the system may include a cloud subscription service or component, referred to herein as a subscription manager in some embodiments, which exposes one or more subscription management APIs for creating orders for joining new customers or initiating a workflow that may create subscriptions and coordinate billing and pricing services or other components for cloud domain 400.

[0112] According to an embodiment, when an operator (e.g., a PLC operator) or its customers request a cloud environment, the system creates domains for use within regions 402 and 404; and leases 416 owned by one or more providers. These leases allow the domains to operate using their required service infrastructure and to be managed by the cloud infrastructure provider.

[0113] According to an embodiment, the first step in this process is to create an operator lease 406 for the operator, and then transfer the region and associated domains to the operator for subsequent management. The operator then becomes the administrator of the lease, and they can view and manage everything that happens within the region, including their customer accounts and those customers' use of cloud resources 412.

[0114] Generally, once a region is handed over or provided to an 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 troubleshoot any problems that may arise.

[0115] According to an embodiment, the operator can then create additional internal leases 408 for its own internal use, such as for evaluating end-user or customer experience, providing sales demonstration leases, or operating databases for its own internal use. The operator can also create one or more customer leases 410, with the end-user or customer acting as its administrator. The use of cloud infrastructure (e.g., compute, storage, and other infrastructure resources) is consolidated by the operator, reflecting its own and its customers' usage, and reported to the cloud infrastructure provider.

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

[0117] Figure 9 The illustration further illustrates the use of the cloud domain by tenants or customers in a cloud infrastructure environment according to an embodiment.

[0118] like Figure 9 As shown, according to an embodiment, the subscription manager 424 service or component exposes one or more subscription management APIs for creating orders for joining new customers, or initiating workflows for creating subscriptions and coordinating billing and pricing services or other components.

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

[0120] According to an embodiment, the system may also include a subscription pricing service (SPS) 426 or component that operates based on a product catalog that defines which products a customer can purchase, and a price list (e.g., a rate card) that can be used to provide the product, which the pricing service also owns.

[0121] According to an embodiment, to support sales processing via subscription creation in domains 420 and 422, products can be selected from a product hub. Once an order is created via subscription service 430, a subscription is created in the subscription manager, which then manages the subscription's lifecycle and supplies the content required for downstream services. The SPS component then manages pricing and usage aspects for the ability to collect final fees from the operator or for the operator to charge its 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.

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

[0123] like Figure 9 As further shown in the embodiments, according to one embodiment, an operator can control multiple domains A and B—for example, an operator operating in multiple countries might want to operate a completely isolated data center for the United States and a completely isolated separate data center for Europe, for example, to meet governance or regulatory requirements. According to one embodiment, usage associated with these multiple domains can be aggregated 434 for use by a central subscription manager 435 and (where applicable) a primary billing service 436 for billing the operator.

[0124] The examples of the various systems shown above are intended to illustrate what 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.

[0125] Cloud subscription

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

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

[0128] Examples of such subscription-based products, services, or other offerings can include a variety of cloud infrastructure software products or services that allow customers to subscribe to use.

[0129] According to an embodiment, the environment may include multiple components provided as operator singleton 438, domain singleton 439, and regional service 440, as further described below.

[0130] According to embodiments, subscriptions may include artifacts such as products, commitments, billing models, and states. A subscription manager service or component may expose one or more subscription management APIs for creating orders for joining new customers, or for initiating workflows to create subscriptions and coordinate the creation of appropriate footprints in the billing and pricing service or component, as further described below.

[0131] According to an embodiment, the billing service or component operates based on a logical container of billing accounts or subscriptions and preferences used to generate invoices. Each billing account generates one invoice per billing period. The billing service includes a first pipeline and a second pipeline. The first pipeline receives usage and costs from the metering service or component via a REST API, whereby billing writes usage to a database, and a billing worker aggregates and calculates the balance from that database. The second pipeline is responsible for retrieving the aggregated usage and commitments, and calculating the costs within the billing interval.

[0132] According to an embodiment, the Subscription Pricing Service (SPS) 426 or component operates based on a product catalog that defines which 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 all products, allowing the addition of new product prices and the modification of existing prices. The price list has a complete history, with the latest version being the current rate card. Because some contracts may require a snapshot of the rate card, the pricing service handles this by recording when a customer's rate card was created and then querying the price list at that time.

[0133] According to an embodiment, the SPS or pricing service is responsible for communicating with the product and pricing hub 421 to provide information about products, the global price list, and specific price lists and discounts for end-user or customer subscriptions. For example, according to an embodiment, the SPS can synchronize product information from the product hub and the global price list from the pricing hub.

[0134] According to an embodiment, the subscription manager service or component operates as an upstream service to receive new order requests from the order management component (e.g., from an Oracle FusionOrder Management environment). The subscription manager service or component can provide subscription information, including subscription details such as the quote configuration time or subscription type (commitment, PayG), to the SPS service to help the SPS determine the effective base price (rate card) for the subscription. The subscription manager service or component can also send subscription discounts received from the order management component, which the SPS stores as a pricing rule entity.

[0135] In one embodiment, the SPS service runs as a background process to manage a ratecard service or component responsible for generating ratecards for new subscriptions and updating these ratecards when prices change. The SPS service can provide APIs to access ratecards and pricing rules. The metering inline rate engine can leverage these APIs to obtain subscription-specific ratecards and pricing rules, and then use this data for cost calculations.

[0136] According to an embodiment, additional SPS components may include, for example, a pricing / product hub integration component that allows operator entities providing subscription-based products, services, or other offerings within the environment to manage their product and price lists, such as product and price lists provided by a product hub and a pricing hub, respectively.

[0137] For example, according to such an embodiment, the SPS product integration process can listen for creation / update events in the product hub and make calls to the SPS product API. Similarly, the SPS pricing integration process can pull new price lists from the pricing hub to create them and call the corresponding SPS pricing API.

[0138] According to an embodiment, the system may also include an SPS core module that provides APIs for managing and accessing pricing entities. Pricing entities can be accessed through internal services (e.g., an inline rate engine).

[0139] 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 price to be used for the subscription. All these price lists are grouped in rate cards. The rate card manager can create and maintain rate cards, listen for price list changes and update existing rate cards with the new prices, and listen for new subscriptions and assign rate cards based on subscription attributes.

[0140] According to an embodiment, the SPS service manages the pricing rules for subscriptions, including discounts offered to end users or customers. The applicability of pricing rules can be based on product attributes such as discount groups, product categories, or specific SKUs. The SPS internally 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 allows the inline rate engine to use this information for cost calculations. This compilation process can be triggered when a product or pricing rule is created or updated.

[0141] like Figure 10As shown in the example, according to the embodiment: at 441, product and pricing information (e.g., managed in FusionApplications) is sent to the SPS component.

[0142] At position 442, the order is sent to the subscription manager component to create the subscription, rate card, and billing account.

[0143] At point 443, the pricing configuration and pricing rules are sent to SPS for use with new orders.

[0144] At 444, the subscription manager component is used to set up billing accounts in a billing service or component.

[0145] At 445, the subscription manager component publishes the event to the subscription manager stream component.

[0146] At point 446, the expense data is sent to accounts receivable component 425 to generate an invoice.

[0147] At 447, the subscription manager component uses the recycling and subscription lifecycle (RASL) events from the subscription manager stream.

[0148] At 448, the activation service 427 reads the subscription manager event stream.

[0149] At point 449, the customer obtains activation data from activation portal 429.

[0150] At 450, the lease lifecycle service 461 provides leases as part of a subscription activation.

[0151] At point 451, the lease lifecycle service creates an account footprint during the account provisioning period within component 463 of the account.

[0152] At location 452, the lease lifecycle service sets a restriction template for the account supply period within the restricted service 467.

[0153] At 453, the account component acts as a downstream RASL client to handle legacy recycling and subscription lifecycle. 465.

[0154] At 454, the aggregated costs and usage are sent to billing service 428 or component.

[0155] At point 455, organizations can use the lease lifecycle service to create subleases.

[0156] At position 456, metering service 432 or component obtains subscription mapping data.

[0157] At 457, subscription service 430 obtains organization data 469 for subscription mapping.

[0158] At 458, the RASL component reads the subscription manager event stream.

[0159] At 459, the subscription service reads the subscription manager event stream; and at 460, the metering service or component obtains the rate card data for each subscription, which can then be used to collect the final charge from the operator or the operator to charge its customers.

[0160] The examples provided above are intended to illustrate how they 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.

[0161] Service control strategy

[0162] Within a cloud infrastructure environment, cloud operators (including the cloud infrastructure providers themselves) may not have appropriate control mechanisms to manage the supplies available to end users (e.g., customers).

[0163] For example, a cloud infrastructure provider's internal service team might use a complex set of restriction templates, feature flags, and allow lists to release features only when supported. However, such controls are not suitable for use by external entities, such as PLC domain operators or administrators.

[0164] According to an embodiment, the system includes a service control store or service catalog that provides and defines service features along with service control policies (SCPs) or rules that define the availability or access to service features. The service control policy framework, including feature management services, determines which different entities can control the availability of specific services or service features to end users by referencing the hierarchy of entities that define the service control policies.

[0165] According to an embodiment, service control policies can be controlled by an entity hierarchy or at multiple levels. At each level within the hierarchy, a service feature can only be controlled by a service control policy at that level if the entity at the higher level has made it available.

[0166] According to an embodiment, when used in a cloud infrastructure environment where services or service features are provided to customers on a subscription basis, for example, as products, the service catalog can operate in the manner of a product catalog used with these products.

[0167] According to an embodiment, the feature management service determines how different entities (e.g., cloud infrastructure providers or domain operators themselves) can control which services or service features will be available to end users (e.g., tenants).

[0168] For example, a cloud infrastructure provider's service team can define the service features or functions they want to expose to operators or end users (e.g., customers) for management or use. Service Control Policies (SCPs) are then used to restrict the availability of these service features to specific operators and customers.

[0169] This hierarchical structure reflects the reseller model; where, for example, at the first or higher level, cloud infrastructure providers need to enable specific service features, and then at the second or lower level, such as domain operators, they need to enable those features for their customers to use.

[0170] While the examples described herein illustrate various systems, methods, and / or technologies that can be used in the context of providing a private tag cloud (PLC) environment, the systems, methods, and technologies described herein can be used within or with other types of cloud environments, depending on the various embodiments.

[0171] According to an embodiment, an example process for determining whether a service feature is enabled (available) or disabled (unavailable) may include:

[0172] If a service control policy matching a specific criterion for disabling a specific service feature is found at the first level of the hierarchy of entities defining service control policies, then the associated service feature is indicated as disabled or unavailable (for example, the cloud infrastructure provider, domain operator, tenant, or customer making the request).

[0173] If a service control policy matching the standard for enabling a service feature is found, the workflow will continue scanning within the hierarchy of the entities that define the service control policy for any policies that match the standard for disabling that service feature; if no such policy is found, the associated service feature will be indicated as enabled or available.

[0174] According to an embodiment, the management user interface or console associated with the management service provides an adaptive user experience based on the assessment of service control policies associated with specific services or service characteristics. For example, console interface elements may be removed or greyed out based on the unavailability of characteristics as determined by the service control policies.

[0175] For example, when accessing a domain operator's or customer's environment via the console to manage services within it, if a specific service or associated service feature is disabled or turned off, then its functionality is hidden by the console plugin.

[0176] According to an embodiment, the feature management service can determine the access of a specific operator or user to a specific service feature in a specific lease or region by assessing the hierarchical structure of service control policies and relationships associated with a specific service feature and determining the status associated with the service and / or its associated service features.

[0177] As another example, in the case of data plane services, it is possible to determine whether to enable data plane services or one or more of their associated service features for use by a specific tenant or customer (operator).

[0178] As another example, in the case of allocating resources to, for example, tenants or customers, such as increasing the number of computing units they use, the feature management service can be used to determine whether to enable a specific service feature for a particular service (e.g., a data plane service) for that tenant or customer, and then approve or reject the requested operation based on the evaluation status of that service feature.

[0179] According to embodiments, various details of specific implementations or embodiments are provided below. This description is provided to illustrate the teachings herein and is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art.

[0180] Figure 11 The illustration depicts an example cloud infrastructure environment that can utilize service control policies according to an embodiment.

[0181] like Figure 11 As shown in the embodiments, and provided by way of example to illustrate the methods described herein, a cloud infrastructure environment may include one or more home regions 502 and subscription regions 504, each region may include service enclaves 503, 505 that provide services and service features.

[0182] According to an embodiment, service coverages 512 and 552 allow access to services provided within a cloud infrastructure environment via load balancers 513 and 553 that communicate with service platforms 520 and 560 (Splat). The service platform implements an internal API gateway that provides access to services and service features and provides feature status for processing requests.

[0183] According to an embodiment, a client-operated console 514, 554 (e.g., a software development kit (SDK) or command-line interface (CLI)) can access services and associated service features provided within the cloud infrastructure environment via a public load balancer 515, 555 and a feature status API that allows create, read, update, and delete (CRUD) operations.

[0184] According to embodiments, within a service zone, the system may include various components supporting access to services, including, for example, service deployment components 518 and 558, which deploy services within a cloud infrastructure environment; replication services 524 and 564, which transmit events from the primary zone to one or more subscription zones; and identity data planes 528 and 568, which provide authorization for requests. Service catalogs 530 and 570 (product catalogs) operate as service control repositories, used to store service and service feature definitions and service control policies or rules, which define the availability or access to service features. Kubernetes or other service operations 532 and 572 are used to maintain the state of services and service features; while the service health restriction component 540 performs health checks on the service catalog.

[0185] According to embodiments, the feature management service (which in some embodiments, as shown below, may be provided by the restricted service data plane) 542, 582 may operate as described below, for example, to provide feature status in response to a request. According to other embodiments, the feature management service may be provided as a separate component. Other services / segments 550, 590 may similarly access the restricted service data plane (feature management service) to obtain feature status.

[0186] The examples provided above are intended to illustrate the teachings herein; they are not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed; other types of architectures may be provided to implement or perform the methods described herein according to other embodiments.

[0187] Service and Feature Status

[0188] According to an embodiment, the system includes a service control repository or service catalog that provides services and service feature definitions, as well as service control policies or rules. These policies or rules define the availability or access to service features. Features can be grouped within services, and associated metadata is stored within the service catalog database.

[0189] Generally, service and feature definitions are managed by the internal services team of the cloud infrastructure provider that owns these services or features. Other operators will not be able to change the definitions of these entities.

[0190] According to one embodiment, feature availability operates as a permission or approval flow, moving from a higher-level internal operator to a lower-level customer. Any operator in this process can choose to stop the flow at its level, which would prevent it from being used by any other lower-level operator or customer.

[0191] According to an embodiment, the service feature supports at least two states: an available state, where the feature is available to lower-level operators or users; and an unavailable state, where the feature is hidden from lower-level operators and users. Additional states that can be supported include, for example, deprecation or retirement. According to an embodiment, the end user or customer will be the party actually using the service feature. For other operators, an unavailable feature would mean they will not have control over the feature or be unable to provide it to their tenants / customers.

[0192] Figure 12 The illustration shows how, according to an embodiment, a service or service feature can be enabled or disabled based on a hierarchy of entities that define service control policies.

[0193] like Figure 12 As shown, according to an embodiment, the hierarchy of entities defining service control policies or levels includes those policies or levels provided by internal operator 602, domain operator 604, organization operator 606, and lease operator 608. In the example shown, a specific service feature is enabled at all intermediate levels, thereby enabling that feature for end user or customer 610.

[0194] Figure 13 The illustration further illustrates how, according to an embodiment, services or service features are enabled or disabled based on a hierarchy of entities that define service control policies.

[0195] like Figure 13 As shown in the example, according to the embodiment, and in the example shown, a specific service feature is enabled by the internal operator but disabled by the domain operator, thereby disabling the feature for end users or customers.

[0196] According to an embodiment, the hierarchical structure of service control policies allows for control over the status of specific service features at multiple levels, each corresponding to a specific operator. At each level within the hierarchy, only features that a higher level has made available can be controlled as described above. For example, service control policies created at different levels can be evaluated sequentially, starting with those created by higher-level operators and ending with those created by lease administrators.

[0197] Figure 14 The illustration depicts a process, according to an embodiment, for use with a service control policy to enable or disable the availability or access to a service feature.

[0198] like Figure 14 As shown, according to an embodiment, a process can be used to determine whether a service or feature should be included in the service catalog and made available to customers.

[0199] For each feature definition, at position 622, determine whether there is a service control policy for that feature (F1).

[0200] If a service control policy exists for this service characteristic, then at step 624, determine whether the request matches the service control policy standard.

[0201] If the request matches the service control policy standard, then determine at 626 whether a domain operator exists.

[0202] If it is determined at 628 that the request originates from a domain operator, then the service feature definition will be included in the service catalog and made available to customers.

[0203] Otherwise, at 630, determine whether an operator service control policy exists for this service feature; and at 632, determine whether the request matches the service control policy criteria. If both are true, then include the service feature definition.

[0204] Figure 15 The illustration depicts another process, according to an embodiment, for use with service control policies to enable or disable the availability or access to service features.

[0205] like Figure 15 As shown in the example, according to the embodiment, a process can be used to determine whether a service or feature should be enabled or disabled for use by a specific customer.

[0206] At position 642, determine whether there is an internal service control policy for this feature (F1).

[0207] If an internal service control policy exists for this service characteristic, then determine at 644 whether the request matches the service control policy standard.

[0208] At position 646, it is determined whether the request is associated with an external tenant. If not, the service feature is enabled or made available, and the process ends.

[0209] If a domain operator exists at point 648, then at point 650 determine whether there is an operator service control policy for the service characteristics, and at point 652 determine whether the request matches the service control policy standard.

[0210] If both are true, then at 654 it is determined whether a rental service control policy exists for this service feature, and at 656 it is determined whether the request matches the service control policy criteria, in which case the service feature is enabled.

[0211] If, at any stage of processing (e.g., at 644, 652, 656), the request does not match the service control policy criteria for that stage, then the service feature is disabled or made unavailable.

[0212] Internal API for service and feature definitions

[0213] According to an embodiment, the service platform (Splat) implements an internal API gateway to provide access to services and service features, as well as feature states for processing requests.

[0214] According to an embodiment, the API can be provided as a control plane (CP) API, which can be used by the cloud infrastructure provider's internal service team to define and manage their services and service characteristics.

[0215] Service Definition

[0216] According to an embodiment, examples of various API operations used to define a service are shown below:

[0217] According to the embodiments, the above operations can utilize various fields, such as:

[0218] Feature definition

[0219] According to an embodiment, examples of various API operations used to define service characteristics are shown below:

[0220] According to the embodiments, the above operations can utilize various fields, such as:

[0221] According to an embodiment, the statesBehavior field may be provided as an optional field, which will store any specific behavior mapped to states associated with a particular service or service characteristic, such as:

[0222] According to an example, the cloud infrastructure provider's internal services team can use the API to evaluate specific characteristics, such as:

[0223] According to an example, the cloud infrastructure provider's internal service team can use APIs to obtain the status of specific characteristics (e.g., by domain or region), such as:

[0224] According to an embodiment, an API can be provided that allows the console to retrieve a list of all disabled features for a specific lease and attribute, for example:

[0225] According to the embodiments, other APIs can be provided to expose available services and service characteristics for different operators to control, for example:

[0226] According to the embodiments, when evaluating service control policy statements, the following rules apply: within a service control policy, statements are evaluated sequentially, and subsequent statements for the same feature take precedence over previous statements. When more than one policy is set for the same resource, the most restrictive policy is applied (e.g., a policy that disables a specific service feature takes precedence over a policy that enables that service feature).

[0227] Figure 16 The illustration depicts another process, according to an embodiment, for use with service control policies to enable or disable the availability or access to service features.

[0228] like Figure 16 As shown, according to an embodiment, the processing for assessing the condition of a service or feature may include processing the (next) service control policy associated with the service or feature at 662, and determining at 664 whether the policy affects the target feature.

[0229] If a service control policy matching the standard for disabling a service feature is found at 668, the result will be to disable the feature or make it unavailable according to that policy.

[0230] If a service control policy matching the standard for enabling a service feature is found at 670, the workflow will continue scanning for any policies that match the standard for disabling the feature. If no such policy is found, the service feature can be enabled or made available.

[0231] State transition

[0232] Figure 17 The illustration shows how, according to an embodiment, a hierarchy of entities defining service control policies can be used to indicate whether a service or service feature is enabled, disabled, deprecated, or retired.

[0233] like Figure 17As shown, according to an embodiment, a feature status can be changed from disabled to enabled at 681; or from enabled to deprecated at 682. Similarly, a previously enabled feature can be changed from enabled to disabled at 683. Deprecated service features can be enabled at 684 (if appropriate); or at 685, as part of a feature deprecation process, they can be changed from a deprecated state to a decommissioned state.

[0234] According to the embodiments, the transition from unavailable to available will have a similar impact from the customer's perspective as the release feature.

[0235] However, marking features that are already available and in use as unavailable introduces some complexities: for example, users should still be able to access their existing resources; users should not be able to create new resources; and users should still need to access the appropriate console plugin to manage their existing resources.

[0236] As another example, users who haven't used it before shouldn't see the console plugin at all. With that in mind, service features marked as available cannot be made unavailable; if operators want to mark a feature as unavailable, they can use the feature decommissioning process. For operators, the supported states will translate to the following API and console behaviors:

[0237] According to the implementation example, for end users, the supported states will be translated into the following API and console behaviors:

[0238] Use of service control policies

[0239] Figures 18-21 The illustration shows an example use of a service control policy within a cloud infrastructure environment according to an embodiment.

[0240] like Figure 18 As shown, according to an embodiment, console 702 may include the use of one or more plugins associated with managing or using services or service features. In the example shown, service A plugin 704 and service B plugin 706 may be associated with service A 732 and service B 734, respectively, to manage those services or their associated service features.

[0241] According to an embodiment, the feature management service 710 communicates with an internal API gateway 720 (e.g., provided by the service platform Splat as shown above), which operates to receive, for example, requests from client devices or users defining the availability or access to a service or its associated features; and provides availability information for use by console plugins.

[0242] According to an embodiment, the system may use other services, such as identity service 724, or additional services 726 as needed, such as determining information associated with a request, such as the user, customer, compartment, or lease associated with the request.

[0243] like Figure 19 As shown in the example, according to the embodiment, in the example shown, the feature management service communicating with the internal API gateway can, for example, respond to the request to determine whether service features F1 and F2 are enabled or available for service A; while for service B, feature F1 is enabled and feature F2 is disabled in response to the request.

[0244] like Figure 20 As shown, according to an embodiment, in order to perform its functions, the feature management service may utilize a restricted service data plane 740 and a service catalog 742 (data repository) for receiving and processing requests. The service catalog 742 provides the definition of service features and service control policies or rules, which define the availability or access to service features.

[0245] like Figure 21 As shown, according to an embodiment, the existing restricted service data plane can be modified to include the functionality of a feature management service and / or service catalog, for example, to provide feature status in response to a request. According to other embodiments, the feature management service may be provided as a separate component.

[0246] The examples provided above are intended to illustrate the teachings herein; they are not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed; other types of processing or components may be provided to implement or perform the methods described herein according to other embodiments.

[0247] Figure 22 The illustration shows, from the perspective of a client device or console, using service control policies to enable or disable processing of the availability or access to service features according to an embodiment.

[0248] According to an embodiment, the process includes providing multiple services within a cloud infrastructure environment for use by operators and their tenants or users; providing multiple service control policies or rules defining access to services and service features in a service control store; in response to a request from a specific operator or its tenant to access a specific service feature, determining a state associated with the service feature by evaluating the service control policies, the state indicating its availability to the operator or tenant; and, in response to determining the state associated with the service feature, performing one of the following: providing or restricting access to the specific service feature by the specific operator or its tenant.

[0249] For example, such as Figure 22As shown, according to an embodiment, and from the perspective of client device 802, the process may include receiving at 803 a request to perform an action associated with a service feature of a specific service (e.g., displaying a console interface).

[0250] At position 804, you can initiate a console plugin associated with a specific service.

[0251] At point 805, the process includes communicating with the feature management service to determine the availability of service features for a particular service.

[0252] At 806, the process includes receiving the availability status of service features from the feature management service.

[0253] Depending on whether the status of the feature received from the feature management service is enabled (available) or disabled (unavailable), the process continues, and at 808, actions associated with the service feature are allowed to be performed (e.g., displaying user interface elements associated with the service feature); or alternatively, at 810, actions associated with the service feature are not allowed (e.g., by disabling / hiding user interface elements associated with the service feature).

[0254] like Figure 22 As shown, according to an embodiment, additional states that can be associated with a service feature or behavior may include, for example, deprecation or retirement. For instance, in the case of a deprecated service, the associated user interface elements may be displayed in the console, but certain workflow operations may be disabled; while in the case of a retired service, the associated user interface elements may be disabled / hidden, so that the user cannot see the feature in the console and cannot access the API associated with the service.

[0255] According to an embodiment, service control policies can be defined using a policy language that allows defining (a) a service, (b) one or more service characteristics associated with the service, and (c) one or more policies that enable or disable access to the service characteristics. Examples of using the policy language are described in further detail below.

[0256] According to an embodiment, the feature management service determines the status associated with service features in real time based on the service control policy associated with the service and the instructions of the requesting operator or user.

[0257] According to an embodiment, service control policies are managed within a hierarchy of service control policies arranged in multiple levels, wherein at each level within the service control policy hierarchy, a service feature can only be controlled if a higher-level entity has made it available.

[0258] According to an embodiment, the feature management service determines the state associated with a service feature by evaluating the hierarchy of service control policies and the relationship between service control policies. This includes, within the hierarchy of service control policies, a first or higher-level service control policy defines a set of service features whose availability or access can be controlled by a second or lower-level service control policy, and wherein the second or lower-level service control policy controls access to the set of service features in response to a request to access the service features.

[0259] According to an embodiment, the service control policy hierarchy includes one or more cloud infrastructure provider policies associated with a specific service characteristic at a first or higher level, and one or more domain operator policies associated with a specific service characteristic at a second or lower level, for determining operator access to its tenants or users.

[0260] According to an embodiment, the service control policy hierarchy includes a first or higher level service control policy and a second or lower level service control policy; wherein the service control policy provided at the first or higher level, which defines the availability or access to a specific service, allows the service control policy provided at the second or lower level to control access to a subset of service features associated with that specific service.

[0261] According to an embodiment, the first or higher-level service control policy is a cloud infrastructure provider policy associated with a specific service and associated service features, and the second or lower-level service control policy is a domain operator policy associated with a specific service and associated service features, and is used to control tenant access to a subset of service features.

[0262] According to an embodiment, the management user interface or console associated with the management service provides an adaptive user experience based on the evaluation service control policy, including the ability to remove or otherwise indicate console interface elements based on the unavailability of features determined by the service control policy.

[0263] According to an embodiment, operators can create and deploy service control policies to restrict the availability of services / features defined by the service control policies within the operator's domain (e.g., the PLC domain).

[0264] According to an embodiment, the process includes: receiving a request from a feature management service to determine the availability status of a service feature at a lower level of the operator hierarchy; and identifying a set of service control policies, wherein the set of service control policies includes: (a) a first subset of service control policies configured from an intermediate level of the operator hierarchy; and (b) a second subset of service control policies configured from a higher level of the operator hierarchy, wherein the lower level is directly below the intermediate level in the operator hierarchy, and the intermediate level is directly below the higher level in the operator hierarchy.

[0265] According to an embodiment, the process further includes: determining a first subset of service control policies configured from an intermediate level of the operator hierarchy directly above a lower level of the operator hierarchy; evaluating one or more service control policies in the first subset of service control policies to determine the availability status of a service feature of a service at a lower level of the operator hierarchy; and performing one or more of the following: enforcing a response to a call to the service feature made from a lower level of the operator hierarchy based on the availability status of the service feature at a lower level of the operator hierarchy; and / or, based on the availability status of the service feature at a lower level of the operator hierarchy, causing a console plugin corresponding to the service feature to be displayed or hidden within a console used at a lower level of the operator hierarchy.

[0266] According to the embodiment, a set of possible values ​​for the availability state includes available and unavailable; the behavior of responding to calls to service features from lower levels of the operator hierarchy includes avoiding blocking the call if the availability state is available; the behavior of responding to calls to service features from lower levels of the operator hierarchy includes blocking the call if the availability state is unavailable.

[0267] According to an embodiment, if at least (a) the feature management service avoids prohibiting calls based on the availability status; and (b) the identity service allows access to the service feature based on one or more access policies, then a call to the service feature is permitted.

[0268] According to an embodiment, at least one of the service control policies in this group targets a service feature, and the access policy cannot target any service feature of any service.

[0269] According to the embodiment, the set of possible values ​​for availability status also includes deprecation and retirement; the behavior of responding to calls to service features from lower levels of the operator hierarchy includes: displaying a blank indicator if the availability status is deprecation; the behavior of responding to calls to service features from lower levels of the operator hierarchy includes: displaying a blank indicator if the availability status is retirement.

[0270] According to an embodiment, displaying or hiding a console plugin corresponding to a service feature in a lower-level console of the operator hierarchy based on the availability status of the service feature includes: transmitting the availability status of the service feature to the console, wherein the console displays or hides the console plugin based on the availability status of the service feature.

[0271] According to an embodiment, evaluating one or more service control policies in a first subset of service control policies to determine the availability status of a service feature at a lower level of the operator hierarchy includes: if at least one of the service control policies in the first subset indicates that the service feature is disabled at a lower level of the operator hierarchy, then the availability status is determined to be unavailable.

[0272] According to an embodiment, evaluating one or more service control policies in a first subset of service control policies to determine the availability status of a service feature at a lower level of the operator hierarchy includes: if none of the service control policies in the first subset indicate that the service feature is enabled at a lower level of the operator hierarchy, then the availability status is determined to be unavailable.

[0273] According to an embodiment, evaluating one or more service control policies in a first subset of service control policies to determine the availability status of a service feature at a lower level of the operator hierarchy includes: if none of the first subset of service control policies indicates disabling the service feature at a lower level of the operator hierarchy, and at least one of the first subset of service control policies indicates enabling the service feature at a lower level of the operator hierarchy, then the availability status is determined to be available.

[0274] According to an embodiment, the service or service feature is accessed at an endpoint of the internal API gateway.

[0275] According to an embodiment, the lower levels of the operator hierarchy include customers; the middle levels of the operator hierarchy include tenants; and the higher levels of the operator hierarchy include cloud service providers.

[0276] According to an embodiment, the lower level of the operator hierarchy includes sub-leases; the middle level of the operator hierarchy includes parent leases; and the higher level of the operator hierarchy includes cloud service providers.

[0277] Figure 23 The illustration shows the use of service control policies from the perspective of a service platform to enable or disable processing of the availability or access to service features, according to an embodiment.

[0278] like Figure 23As shown, according to the embodiment, and from the perspective of the service platform 842, the process can generally be operated as described above, for example, receiving a request to perform an action associated with a service feature of a specific service; communicating with the feature management service to determine the availability of the service feature of the specific service; and depending on the information received from the feature management service regarding whether the feature is enabled (available) or disabled (unavailable), either allowing the execution of the action associated with the service feature (e.g., displaying the user interface element corresponding to the service feature in the console); or alternatively disallowing the action associated with the service feature (e.g., disabling or hiding the user interface element corresponding to the service feature).

[0279] Figure 24 The illustration shows how, according to an embodiment, service control policies are used to enable or disable processing of the availability or access to service features from the perspective of a feature management service.

[0280] like Figure 24 As shown in the embodiment, and from the perspective of feature management service 862, the process may include: at 864, receiving a request to determine the availability of service features of a specific service (as described above). Figure 22-23 (as shown in (A)); at 866, the level of the entity hierarchy corresponding to the entity that made the request is determined; at 868, the service control policy created from the directly higher level of the entity hierarchy is searched in the service catalog; and at 870, based on the above subset of the service control policies, a search for the service control policy associated with the specific service is performed.

[0281] At point 872, determine if the specific service is available. If available, the process continues at point 874 to look for the service control policy associated with that service characteristic.

[0282] At point 876, it is determined whether the service feature is available. If available, the process continues at point 878 and returns a message indicating that the service feature's availability status is enabled or available.

[0283] Otherwise, at 880, a return message is provided indicating that the availability status of the service feature is disabled and unavailable (or decommissioned, abandoned). According to an embodiment, the availability status of the service feature is provided to the console or service platform that made the request (as described above). Figure 22-23 (as shown at point (B) in the text).

[0284] user interface

[0285] According to an embodiment, the system may include a management user interface or console associated with service management, which provides an adaptive user experience based on the evaluation of service control policies associated with specific services or service features. For example, console interface elements may be removed or grayed out based on feature unavailability as determined by service control policies. The console user interface allows different operators to view the current status of services and service features from their own perspective or according to their license levels.

[0286] Figures 25-27 The illustration shows an example user interface for managing the use of service control policies within a cloud infrastructure environment, according to an embodiment.

[0287] like Figures 25-27 As shown, according to an embodiment, the console user interface allows users to manage policies, including selecting services, determining their status (e.g., enabling or disabling), and enabling or disabling specific features associated with them.

[0288] According to the embodiments, the options available to users (e.g., cloud infrastructure provider operators, domain operators, or end users or customers) when defining the availability or access to service features will typically match the possible filtering criteria present in the policy language, such as: specific lease, where the operator should be able to see the feature status from the perspective of a specific lease; and regionality, since multiple teams will have to deal with the same dimension, so the console user interface can provide a uniform way of dealing with them to make it consistent for the operator.

[0289] Service Control Strategy Language

[0290] According to an embodiment, service control policies can be defined using a policy language that allows defining (a) a service, (b) one or more service characteristics associated with the service, and (c) one or more policies that enable or disable access to the service characteristics. Operators (e.g., cloud infrastructure providers or domain operators) can create any number of service control policies, each containing any number of policy statements.

[0291] According to the embodiment, the example policy syntax can be expressed as:

[0292] enable|disable

[0293] [all| #service-name]

[0294] [feature all | #feature-name]

[0295] [where request.tenancyID = / in #tenancy_list]

[0296] [request.region = / in #region-name]

[0297] The various items contained within the service control policy or the associated rules that implement the service control policy may include, for example:

[0298] According to an embodiment, when a request to access a service or feature is processed according to a service control policy, the caller can populate the request context with various details such as, for example, tenant ID or region.

[0299] The examples provided above are intended to illustrate the teachings herein; they are not intended to be exhaustive or to limit the scope of protection to the precise form disclosed; according to other embodiments, other types of service control policy languages ​​and syntaxes may be used to define the services, service characteristics, and service control policies associated therewith.

[0300] According to various embodiments, the teachings herein can be implemented using one or more computers, computing devices, machines, or microprocessors, including one or more processors, memories, and / or computer-readable storage media programmed according to the teachings herein. It will be apparent to those skilled in the art that a skilled programmer can easily prepare appropriate software code based on the teachings of this disclosure.

[0301] In some embodiments, the teachings herein may include a computer program product, which is one or more nontransitory computer-readable storage media having instructions stored thereon / therein that can be used to program a computer to perform any of the processing described herein. Examples of such storage media may include, but are not limited to, hard disk drives, solid disks, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory devices, or other types of storage media or devices suitable for nontransitory storage of instructions and / or data.

[0302] The above description is provided for illustrative and descriptive purposes only. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Further modifications and variations will be apparent to those skilled in the art.

[0303] The embodiments were chosen and described to better explain the principles taught herein and their practical application, thereby enabling others skilled in the art to understand the various embodiments and modifications suitable for the intended particular use. The scope of the invention is defined by the following claims and their equivalents.

Claims

1. A method for controlling access to service features, comprising: Provide multiple services within a cloud infrastructure environment for operators and their tenants or users; Multiple service control policies (SCPs) are provided within the service control store, which define access to services and service characteristics; In response to an access request for a specific service feature from a specific operator or its tenant, the feature management service determines the status associated with the service feature by evaluating service control policies, the status indicating the availability of the service feature to the operator or tenant; and In response to determining the state associated with the service feature, one of the following actions is taken: granting or restricting access to the specific service feature by a particular operator or its tenants.

2. The method of claim 1, wherein the service control policy is defined by a policy language that allows defining (a) a service, (b) one or more service features associated with the service, and (c) one or more policies that enable or disable access to the service features.

3. The method of claim 1, wherein the features The management service determines the status associated with service characteristics in real time based on the service control policies associated with the service and the instructions of the requesting operator or user.

4. The method of claim 1, wherein the service control policy is managed within a hierarchy of entities defining the service control policy, the hierarchy being arranged into multiple levels, wherein at each level within the hierarchy of entities defining the service control policy, only service features that have been made available by higher-level entities can be controlled.

5. The method of claim 1, wherein the features The management service determines the state associated with service features by assessing the hierarchy of entities that define service control policies and the relationships between service control policies. This includes: within the hierarchy of entities that define service control policies, a first or higher-level service control policy that defines a set of service features, the availability or access of which can be controlled by a second or lower-level service control policy, and wherein the second or lower-level service control policy controls access to the set of service features in response to a request to access the service features.

6. The method of claim 5, wherein the hierarchy of entities defining service control policies includes one or more cloud infrastructure provider policies associated with a specific service feature at a first or higher level, and one or more domain operator policies associated with said specific service feature at a second or lower level, for determining operator access to its tenants or their users.

7. The method of claim 5, wherein the hierarchy of entities defining service control policies includes first or higher-level service control policies and second or lower-level service control policies, and: The service control policies defined at the first or higher level for the availability or access to a specific service allow service control policies provided at the second or lower level to control access to a subset of service features associated with the specific service.

8. The method of claim 7, wherein the first or higher-level service control policy is a cloud infrastructure provider policy associated with a specific service and associated service features, and the second or lower-level service control policy is a domain operator policy associated with the specific service and associated service features, and is used to control tenant access to the subset of service features.

9. The method of claim 1, wherein the management user interface or console associated with the management service provides an adaptive user experience based on an evaluation service control policy, including the ability to remove or otherwise indicate console interface elements based on feature unavailability determined by the service control policy.

10. The method of claim 1, wherein the operator is capable of creating and deploying service control policies to restrict the availability of services / features defined by the service control policies within the operator's domain.

11. A method comprising: The feature management service receives a request for determining the availability status of the service features of the service at a lower level of the operator hierarchy. A set of service control policies (SCPs) is identified by a feature management service, wherein the set of service control policies includes (a) a first subset of service control policies configured from an intermediate level of the operator hierarchy; and (b) a second subset of service control policies configured from a higher level of the operator hierarchy, wherein the lower level is directly below the intermediate level in the operator hierarchy, and the intermediate level is directly below the higher level in the operator hierarchy. The first subset of service control policies determined by the feature management service is configured from the intermediate level that is directly above the lower level of the operator hierarchy. One or more service control policies from a first subset of the feature management service are evaluated to determine the availability status of the service features of the service at the lower level of the operator hierarchy. Perform one or more of the following: The feature management service, based on the availability status of the lower level of the operator hierarchy according to service features, enforces actions to respond to calls made to service features from the lower level of the operator hierarchy; and / or The feature management service determines the availability status of the lower-level operator hierarchy based on service features, causing console plugins corresponding to the service features to be displayed or hidden within the console used for the lower-level operator hierarchy.

12. The method of claim 11, wherein: Availability status has a set of possible values ​​including available and unavailable; The actions taken to respond to calls to service features from lower levels of the operator hierarchy include: avoiding blocking the call if the availability status is available; The actions taken to respond to calls to service features from lower levels of the operator hierarchy include: if the availability status is unavailable, then prohibiting the call.

13. The method of claim 12, wherein, Calls to a service feature are permitted if at least (a) the feature management service avoids prohibiting calls based on the availability status, and (b) the identity service allows access to the service feature based on one or more access policies.

14. The method of claim 13, wherein at least one of the set of service control policies is targeted at a service feature, and the access policy cannot be targeted at any service feature of any service.

15. The method of claim 12, wherein: The set of possible values ​​for availability status also includes decommissioning and retirement; The actions taken to respond to calls to service features from lower levels of the operator hierarchy include: displaying a blank indicator if the availability status is deprecated; The behavior of responding to calls to service features from the lower levels of the operator hierarchy includes displaying a blank indicator if the availability status is decommissioned.

16. The method of claim 11, wherein the availability status of the lower level of the operator hierarchy based on service characteristics by the feature management service, such that displaying or hiding a console plugin corresponding to the service characteristics within the console of the lower level of the operator hierarchy, comprises: The availability status of service features is transmitted to the console, which then shows or hides the console plugin based on the availability status of the service features.

17. The method of claim 11, wherein evaluating one or more service control policies from a first subset of the service control policies by the feature management service to determine the availability status of the service features of the service at the lower level of the operator hierarchy includes: If at least one instruction in the first subset of the service control policies disables service features at the lower level of the operator hierarchy, then the availability state is determined to be unavailable.

18. The method of claim 11, wherein evaluating one or more service control policies from a first subset of the service control policies by the feature management service to determine the availability status of the service features of the service at the lower level of the operator hierarchy includes: If none of the first subsets of service control policies indicates enabling service features for the lower levels of the operator hierarchy, then the availability status is determined to be unavailable.

19. The method of claim 11, wherein evaluating one or more service control policies from a first subset of the service control policies by the feature management service to determine the availability status of the service features of the service at the lower level of the operator hierarchy includes: If none of the first subsets of the service control policies indicates disabling service features at the lower level of the operator hierarchy, and at least one of the first subsets of the service control policies indicates enabling service features at the lower level of the operator hierarchy, then the availability status is determined to be available.

20. The method of claim 11, wherein the service or service feature is accessed at an endpoint of the internal API gateway.

21. The method of claim 11, wherein: The lower levels of the operator hierarchy include customers; The intermediate level of the operator hierarchy includes tenants; The higher levels of the operator hierarchy include cloud service providers.

22. The method of claim 11, wherein: The lower levels of the operator hierarchy include sub-leases; The intermediate level of the operator hierarchy includes the parent lease; The higher levels of the operator hierarchy include cloud service providers.

23. A method comprising: The feature management service receives a request, which is used to determine the availability status of the service features of the service to the intermediate level of the operator hierarchy. A set of service control policies (SCPs) configured from a higher level in the operator hierarchy is identified by the feature management service, wherein the intermediate level is directly below the higher level in the operator hierarchy. The feature management service evaluates one or more of the set of service control policies to determine the availability status of the service features of the service at the intermediate level of the operator hierarchy. The feature management service, based on the availability status of service features at the intermediate level of the operator hierarchy, allows or prohibits configuring one or more service control policies from the intermediate level of the operator hierarchy to control the second availability status of service features at a lower level of the operator hierarchy, wherein the lower level is directly below the intermediate level in the operator hierarchy.

24. The method of claim 23, comprising: The service feature indicates that the availability status of the first level of the operator hierarchy is available. The feature management service allows one or more control policies (SCPs) for service features to be configured from the intermediate level of the operator hierarchy to the lower level of the operator hierarchy. The method further includes: The feature management service receives configurations of one or more service control policies from the intermediate level of the operator hierarchy for the lower level of the operator hierarchy. The feature management service evaluates one or more of the second set of service control strategies to determine the service characteristics of the service to the second availability state of the lower level of the operator hierarchy. The feature management service enforces a response to calls made to service features from the lower level of the operator hierarchy based on the service features and the second availability state of the lower level of the operator hierarchy.

25. The method of claim 23, wherein the service control policy is defined by a policy language that allows defining (a) a service, (b) one or more service features associated with the service, and (c) one or more policies that enable or disable access to the service features.

26. The method of claim 23, wherein the features The management service determines the status associated with service characteristics in real time based on the service control policies associated with the service and the instructions of the requesting operator or user.

27. The method of claim 23, wherein the service control policy is managed within a hierarchy of entities defining the service control policy, the hierarchy being arranged into multiple levels, wherein at each level within the hierarchy of entities defining the service control policy, only service features that have been made available by higher-level entities can be controlled.

28. The method of claim 23, wherein the features The management service determines the state associated with service features by assessing the hierarchy of entities that define service control policies and the relationships between service control policies. This includes: within the hierarchy of entities that define service control policies, a first or higher-level service control policy that defines a set of service features, the availability or access of which can be controlled by a second or lower-level service control policy, and wherein the second or lower-level service control policy controls access to the set of service features in response to a request to access the service features.

29. The method of claim 28, wherein the hierarchy of entities defining service control policies includes one or more cloud infrastructure provider policies associated with a specific service feature at a first or higher level, and one or more domain operator policies associated with said specific service feature at a second or lower level for determining operator access to its tenants or their users.

30. The method of claim 28, wherein the hierarchy of entities defining service control policies includes a first or higher-level service control policy and a second or lower-level service control policy, and: The service control policies defined at the first or higher level for the availability or access to a specific service allow service control policies provided at the second or lower level to control access to a subset of service features associated with the specific service.

31. The method of claim 30, wherein the first or higher-level service control policy is a cloud infrastructure provider policy associated with a specific service and associated service features, and the second or lower-level service control policy is a domain operator policy associated with the specific service and associated service features, and is used to control tenant access to a subset of service features.

32. The method of claim 23, wherein the management user interface or console associated with the management service provides an adaptive user experience based on an assessment service control policy, including the ability to remove or otherwise indicate console interface elements based on feature unavailability determined by the service control policy.

33. The method of claim 1, wherein the operator is capable of creating and deploying service control policies to restrict the availability of services / features defined by the service control policies within the operator's domain.

34. A method comprising: The feature management service receives a request, which is used to determine the availability status of the service features of the service; A set of service control policies (SCPs) is identified by a feature management service, wherein the set of service control policies includes (a) a first subset of service control policies for multiple services, and (b) a second subset of service control policies for multiple service features, wherein the multiple services are associated with the multiple service features. The feature management service determines a relevant subset of the set of service control policies, wherein the relevant subset of service control policies includes one or more of the following: (a) a first service control policy (SCP) for the service in a first subset of service control policies, or (b) a second SCP for the service feature in a second subset of service control policies; The feature management service evaluates one or more subsets of the relevant service control policies to determine the availability status of the service features of the service; Perform one or more of the following: The feature management service enforces the behavior of responding to calls made for the service feature based on the availability status of the service feature; The feature management service displays or hides the console plugin corresponding to the service feature based on the availability status of the service feature.

35. The method of claim 34, wherein the service control policy is defined by a policy language that allows defining (a) a service, (b) one or more service features associated with the service, and (c) one or more policies that enable or disable access to the service features.

36. The method of claim 34, wherein the features The management service determines the status associated with service characteristics in real time based on the service control policies associated with the service and the instructions of the requesting operator or user.

37. The method of claim 34, wherein the service control policy is managed within a hierarchy of entities defining the service control policy, the hierarchy being arranged into multiple levels, wherein at each level within the hierarchy of entities defining the service control policy, only service features that have been made available by entities at higher levels can be controlled.

38. The method of claim 34, wherein the features The management service determines the state associated with service features by assessing the hierarchy of entities that define service control policies and the relationships between service control policies. This includes: within the hierarchy of entities that define service control policies, a first or higher-level service control policy that defines a set of service features, the availability or access of which can be controlled by a second or lower-level service control policy, and wherein the second or lower-level service control policy controls access to the set of service features in response to a request to access the service features.

39. The method of claim 38, wherein the hierarchy of entities defining service control policies includes one or more cloud infrastructure provider policies associated with a specific service feature at a first or higher level, and one or more domain operator policies associated with said specific service feature at a second or lower level for determining operator access to its tenants or their users.

40. The method of claim 38, wherein the hierarchy of entities defining service control policies includes first or higher-level service control policies and second or lower-level service control policies, and: The service control policies defined at the first or higher level for the availability or access to a specific service allow service control policies provided at the second or lower level to control access to a subset of service features associated with the specific service.

41. The method of claim 40, wherein the first or higher-level service control policy is a cloud infrastructure provider policy associated with a specific service and associated service features, and the second or lower-level service control policy is a domain operator policy associated with the specific service and associated service features, and is used to control tenant access to a subset of service features.

42. The method of claim 34, wherein the management user interface or console associated with the management service provides an adaptive user experience based on an evaluation service control policy, including the ability to remove or otherwise indicate console interface elements based on feature unavailability determined by the service control policy.

43. The method of claim 34, wherein the operator is capable of creating and deploying service control policies to restrict the availability of services / features defined by the service control policies within the operator's domain.

44. A system comprising: A computer, comprising a processor device and a non-transitory memory operatively coupled to the processor device, wherein the computer performs a method comprising: Provide multiple services within a cloud infrastructure environment for operators and their tenants or users; Multiple service control policies (SCPs) are provided within the service control store, which define access to services and service characteristics; In response to an access request for a specific service feature from a specific operator or its tenant, the feature management service determines the status associated with the service feature by evaluating service control policies, the status indicating the availability of the service feature to the operator or tenant; and In response to determining the state associated with the service feature, one of the following actions is taken: granting or restricting access to the specific service feature by a particular operator or its tenants.

45. A non-transitory computer-readable storage medium having instructions thereon, which, when executed in a computer system including a processor, cause the computer to perform a method, the method comprising: Provide multiple services within a cloud infrastructure environment for operators and their tenants or users; Multiple service control policies (SCPs) are provided within the service control store, which define access to services and service characteristics; In response to an access request for a specific service feature from a specific operator or its tenant, the feature management service determines the status associated with the service feature by evaluating service control policies, the status indicating the availability of the service feature to the operator or tenant; and In response to determining the state associated with the service feature, one of the following actions is taken: granting or restricting access to the specific service feature by a particular operator or its tenants.

Images