Cross-Cloud Service Broker for Unified Resource Provisioning

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current cloud environments are closed ecosystems, restricting customers to using only the services offered by a specific cloud service provider, making it difficult for customers to access services from different providers.

Innovation Solution

The implementation of a computer-implemented method that allows for the provisioning and management of cross-cloud services by enabling a service from one cloud environment to configure virtual resources on a physical resource hosted within another cloud environment, while presenting the virtual resource as if it were hosted within the requesting cloud environment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a cloud environment provides a closed ecosystem for its subscribing customers, then the cloud service provider can maintain control and security over its services, but customers are restricted to using only the services offered by that specific cloud service provider and cannot access services from different providers

Engineering Contradiction:
Improvecontrol and securityVSAvoidservice access flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements a service broker as an intermediary component that sits between the customer's cloud environment and external cloud services. This broker translates service requests into appropriate API calls to external providers while maintaining security boundaries. The broker acts as a controlled gateway that enables cross-provider service access without compromising the closed ecosystem's security model, effectively mediating between the need for control and the desire for versatility.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The service broker is designed with universal functionality to handle multiple types of cloud services from different providers through a unified interface. It implements a standardized service registry and request routing mechanism that can accommodate diverse service types (IaaS, PaaS, SaaS) from multiple cloud providers, making the system adaptable to various service needs while maintaining a single point of control within the customer's environment.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Ease of manufacture

If cloud environments are designed as closed ecosystems, then each provider can optimize their service delivery and management, but customers experience difficulty in accessing and using services from different cloud providers through a unified interface

Engineering Contradiction:
Improveservice delivery optimizationVSAvoidcross-cloud service access
Core Design Contradiction:
Ease of manufactureVSEase of operation

Solution Approach 1:

The patent segments the cloud service access architecture into distinct functional components: a service registry that catalogs available services, a service broker that manages requests, and integration adapters that connect to specific external providers. This segmentation allows each component to be optimized independently for its specific function while working together to provide unified cross-cloud access, resolving the conflict between provider optimization and customer ease of operation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The service broker serves as an intermediary that abstracts the complexity of accessing multiple external cloud providers from the customer interface. It handles service discovery, request translation, authentication, and response aggregation, allowing customers to access cross-cloud services through a simple unified interface while the broker manages the operational complexity of interfacing with multiple optimized external systems.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If a cloud service provider hosts physical resources within another cloud environment's infrastructure, then the service can be made available to customers of the hosting cloud environment, but the service must be configured and managed across different cloud control planes

Engineering Contradiction:
Improvecross-cloud service availabilityVSAvoidmulti-control plane configuration
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the service configuration and management logic from the external cloud provider's control plane and consolidates it within the customer's cloud environment through the service broker. The broker maintains local service definitions, credentials, and configuration parameters, extracting the complexity of cross-cloud management from the hosting environment and concentrating it within the customer's controlled boundary, thereby reducing overall system complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The service broker creates and maintains local copies of service configurations, authentication credentials, and management parameters within the customer's cloud environment. Instead of requiring real-time connections to external control planes for every operation, the broker stores replicated configuration data locally, enabling service provisioning and management without continuous external control plane involvement, thus simplifying the multi-control plane complexity.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS20250156209A1Managing a service offered by a first cloud service provider via a cloud environment of a second cloud service provider
Publication Date: 2025.05.15 ORACLE INT CORP
  • US20250156209A1 patent drawing
  • US20250156209A1 patent drawing
  • US20250156209A1 patent drawing

AI summary

Techniques are disclosed herein for provisioning cross-cloud services. The techniques include receiving, by a service of a first cloud environment, a request to configure a virtual resource and causing, by the service, a control plane of the first cloud environment to configure the virtual resource on a physical resource of the first cloud service provider. The first cloud environment can be implemented on a first cloud infrastructure of a first cloud service provider and the request can be received from a second cloud environment upon input of a customer of a second cloud service provider at a portal of the second cloud environment. The input can indicate at least one parameter of the request and the second cloud environment can be implemented on a second cloud infrastructure of the second cloud service provider.