Content delivery network-based routing of application programming interface requests to cloud service instances

Abstract

The invention relates to content delivery network-based routing of application programming interface requests to cloud service instances. A process includes receiving, by a server associated with a content delivery network, a first request specifying an application programming interface (API) call to a cloud service. The first request includes data representing an authorized bearer token, a geographic service area identifier, and an API call group. The process includes routing, by the server, the API call to an instance of the cloud service. The routing includes determining, by the server, a client identifier based on an authorized bearer token; and identifying, by the server, a location of the instance based on the client identifier, the geographic area identifier, and the API call group identifier. The routing includes sending, by the receiver, a second request corresponding to the API call to the location in response to the identification.

Description

Background Art

[0001] A cloud service provider may provide an Application Programming Interface (API) for allowing a client (e.g., an application) to configure, manage, and interact with a cloud service instance hosted by the provider via an API call. The API call may specify a function, action, or operation to be performed by the cloud service instance. Brief Description of the Drawings

[0002] Figure 1A is a block diagram of a computer network having a Content Delivery Network (CDN) that dynamically routes API requests to global and regional cloud service instances according to an example embodiment.

[0003] Figure 1B is according to an example embodiment Figure 1A illustration of a global routing table.

[0004] Figure 2A is an illustration of an API request provided by a client according to an example embodiment.

[0005] Figure 2B is an illustration of an API request provided by the CDN in response to an API request provided by a client according to an example embodiment.

[0006] Figure 3 is an illustration of the routing of an API request by the CDN according to an example embodiment.

[0007] Figure 4 is a sequence flow diagram depicting actions and communications associated with routing an API request to a cloud service instance according to an example embodiment.

[0008] Figure 5 is a sequence flow diagram depicting actions and communications associated with migrating a client workload between cloud service instances according to an example embodiment.

[0009] Figure 6 is a flowchart depicting a process of using a CDN to route an API request according to an example embodiment.

[0010] Figure 7 is an illustration of a non-transitory storage medium storing machine-readable instructions that, when executed by a machine associated with a Point of Presence (PoP) of the CDN, cause the machine to route an API request to an instance of a service according to an example embodiment.

[0011] Figure 8 is a block diagram of an apparatus including a hardware processor associated with the CDN and executing machine-readable instructions to route an API request to an instance of a service according to an example embodiment. Detailed Description

[0012] Commercial enterprises may deploy compute-related workloads to the cloud for any of a variety of reasons to take advantage of the benefits of cloud services. For example, by deploying the workload to the cloud, a commercial enterprise can avoid the complexity and cost associated with managing and maintaining information technology (IT) infrastructure and / or the software that processes the workload. As another example, a commercial enterprise can scale the cloud-hosted IT infrastructure up or down as needed to accommodate changing workload sizes. In the cloud, the deployed workload is processed by cloud service instances.

[0013] Cloud services can be regional or global. Cloud service instances for regional cloud services are hosted in a specific geographical region or zone, which can be advantageous for customers of that service. For example, a data center can be selected to host a cloud service instance for a particular customer based on the specific geographical region in which the data center is located. In one example, the data center can be in the same geographical region as the customer or customer device being served by the regional cloud service. Regional cloud services can reduce latency, meet disaster recovery criteria, comply with jurisdictional privacy regulations, or otherwise provide solutions that fit the customer's location-related policies. Cloud service instances for global cloud services are not partitioned according to different geographical regions or zones.

[0014] Developers of applications that consume cloud services can rely on documentation of example reusable API cloud service calls (or "API calls"). One factor that affects the availability of such documentation for a particular API call is the number of ways in which the API call signature can change to accommodate different use cases. An API call can take the form of a message or an API request, which includes a message header (and other possible headers) and a payload portion or body. The API call signature corresponds to the content of the message header and body. In addition to other content of the message header, the message header can include data representing a uniform resource locator (URL) (also referred to herein as the "request URL"). The request URL contains information identifying the endpoint location of the instance hosting the cloud service (e.g., a domain name).

[0015] In one approach, DNS-based routing alone can be relied upon to route API requests from a client (e.g., an application instance) to a particular cloud service instance. With this approach, the request URL specifies the location of the endpoint of the cloud service instance. A cloud service provider can offer multiple concurrent instances of a cloud service, which means that there can be several potential endpoints (and corresponding numbers of potential request URLs). Thus, if DNS-based routing alone is relied upon to route API requests to cloud service instance endpoints, the corresponding API call signature variability can limit the availability of documented example reusable API calls.

[0016] According to an example embodiment, a combination of content delivery network (CDN) routing and DNS routing is used to convey API requests between a client (e.g., an application instance) and an endpoint of a cloud service instance. As described herein, the combination of CDN and DNS routing facilitates API call signature consistency. According to an example embodiment, a client can provide an API request (referred to herein as a "client-provided API request") that specifies a request URL, which includes a domain name that points the API request to a CDN endpoint via DNS routing. In one example, the request URL can specify a domain name that has a portion corresponding to a cloud service provider and an additional subdomain that is used as a geographic service area identifier. For example, the domain name of the request URL can have the format "<region>.<cloud provider>". Here, "<>" denotes one or more domains. For example, "<cloud provider>" represents a combination of a top-level domain, a second-level domain, and possibly one or more subdomains corresponding to the cloud service provider. Additionally, "<region>" represents one or more subdomains that identify whether the cloud service is a regional cloud service or a global cloud service. For a regional cloud service, the (multiple) subdomains corresponding to "<region>" also identify a specific geographic service area.

[0017] In one example, the subdomain of "<region>" in a specific request URL can be "global" or a similar text string indicating that the API request is directed to a global cloud service. In another example, the subdomain name of "<region>" in a specific request URL can be "us_west", "us-west", "uswest", or a similar text string indicating that the API request is directed to a regional cloud service and a specific geographic service area (e.g., the western region of the United States).

[0018] According to an example embodiment, a CDN may have geographically distributed Points of Presence (POPs). One or more edge servers may be located at each POP. In one example, in response to an API request provided by a client, a DNS server associated with the CDN points the API request to an edge server of the CDN. As a more specific example, in response to a DNS query for an Internet Protocol (IP) address of a certain domain name, the DNS server selects an edge server of the CDN and provides a DNS response containing the IP address of the selected edge server. According to an example embodiment, a routing engine of the selected edge server receives and processes the API request provided by the client for routing or forwarding the API request provided by the client to an appropriate endpoint for a cloud service instance. For this purpose, according to an example embodiment, the routing engine extracts information from the API request provided by the client, which allows the routing engine to look up the address of the endpoint of the cloud service instance from a global routing table. Then, according to an example embodiment, the routing engine may generate another API request (referred to herein as a "CDN-provided API request") specifying the endpoint address (e.g., a domain name or an IP address) for the cloud service instance, along with other information from the original API request provided by the client. The routing engine sends the CDN-provided API request to the cloud service instance endpoint via DNS routing.

[0019] According to an example embodiment, for the purpose of looking up the endpoint address for a cloud service instance, the routing engine extracts the following list of elements or tuple from the API request provided by the client: a geographic service area identifier; a customer identifier; and an API call group identifier. The routing engine uses the tuple as an index to the global routing table to identify and read an entry or record of the global routing table, which contains the location or address of the service instance endpoint.

[0020] A cloud service provider can provide multiple concurrent cloud service instances for a specific cloud service. In one example, a specific cloud service instance can be a multi-tenant instance serving multiple tenants. In this document, a "tenant" refers to a user. As an example, the tenants of a multi-tenant service instance can be users associated with different customer accounts or can be users associated with the same customer account. For any of a variety of reasons, it can be beneficial for the cloud service provider to move or migrate the workload of a specific client from one cloud service instance to another cloud service instance. In one example, for a multi-tenant cloud service instance A, due to resource contention among multiple clients of instance A, performance issues may occur. To resolve the resource contention issue, the cloud environment management engine of the cloud service provider can decide to migrate the workload of a specific client from the multi-tenant cloud service instance A to another cloud service instance D. For the purpose of changing the subsequent API request routing for the client, the cloud environment management engine can modify the appropriate record in the global routing table (e.g., write to the appropriate record in the table) to change the service instance endpoint address to the endpoint address for cloud service instance D. It can be understood that the endpoint address for a cloud service instance can be dynamically changed by the cloud service provider in a manner transparent to the clients of the instance, and this does not affect the API call signature.

[0021] Figure 1A depicts a computer network 100 according to an example implementation. Referring to Figure 1A , the cloud service provider can manage and maintain global resources 160 and regional resources 164 for providing one or more cloud services. More specifically, the global resources 160 can provide one or more global cloud service instances 168 (or "global service instances 168"), and each regional resource 164 can provide one or more regional cloud service instances 188 (or "regional service instances 188").

[0022] In the context used in this document, a "cloud service instance" (or "service instance") refers to a computing environment corresponding to the allocation of computing-related resources. In one example, the computing environment can correspond to actual physical infrastructure, such as bare metal. In another example, the computing environment can correspond to virtual infrastructure, such as a virtual machine. In another example, the computing environment can correspond to a combination of virtual and physical infrastructure.

[0023] For purposes of requesting and managing functions, operations, or actions related to (from the client side) global service instance 168 and regional service instance 188 and interacting with global service instance 168 and regional service instance 188, a client such as application instance 115 may provide a client-provided API request 116. As further described herein, the client-provided API request 116 is sent via DNS routing to CDN 130 of computer network 100. According to an example embodiment, CDN 130 converts the client-provided API request 116 associated with regional service instance 188 into a corresponding API request 190 (referred to herein as "CDN-provided API request 190"), which is directed via DNS routing to an appropriate endpoint 186 for regional service instance 188. Additionally, according to an example embodiment, CDN 130 converts the client-provided API request 116 associated with global service instance 168 into a corresponding API request 192 (referred to herein as "CDN-provided API request 192"), which is routed via DNS routing to an appropriate endpoint 164 for global service instance 168.

[0024] In the context used herein, an application programming interface or "API" refers to a collection of software components (e.g., software components associated with a cloud service instance) that together provide one or more functions, operations, or actions. As described herein, an API call involves invoking one or more functions, operations, or actions of a particular API. A cloud service instance may provide a response to an API call ("API response"). An API call to a cloud service instance may be transmitted to the cloud service instance in the form of an API request (e.g., a hypertext transfer protocol (HTTP) request or a secure HTTP (HTTPS) request). Additionally, according to an example embodiment, the API request and the API response may correspond to a representational state transfer or "REST" API call model. According to another embodiment, the API request and the API response may correspond to an API call model other than the REST API call model. According to another embodiment, the API request and the API response may correspond to a remote procedure call (RPC) model or another API call model.

[0025] API requests can involve any one of multiple different actions or functions, action operations, invoked by a cloud service instance, depending on the underlying cloud service provided by the instance and the specific API of the instance. In one example, for a cloud service instance associated with a network management system (NMS) service, the API request can be related to an operation of configuring a network device with parameters corresponding to a specific network telemetry report subscription. In another example, an API request to the NMS cloud service instance can be related to an operation of updating the firmware of a network device. In another example, an API request to the NMS cloud service instance can be related to an operation of configuring a network device. In another example, for a cloud service instance associated with a compute operation (or "compute ops") service, the API request can be directed to initiate a firmware package upgrade of a managed server. In another example, an API request to the compute operation service instance can be related to initiating an installation of an operating system or another operation on a managed server. In another example, for a cloud service instance associated with a backup and restore service, the API request can be directed to initiate a backup of a specific storage volume. In other examples, depending on the specific underlying cloud service, the API request can involve functions, operations, or actions related to machine learning processing, network configuration, sales management, human resources management, big data analysis, big data mining, accounting, identity and access management, record customer relationship management, database operations, cloud service management, high performance computing (HPC), and other functions, operations, or actions.

[0026] Depending on the particular implementation, the API request 116 provided by the client can be generated by any one of various different entities and in any one of various different ways. In the context used herein, a "client" refers to the entity that generates the API request. The client can have one of a variety of different forms. In one example, the client can be an application instance 115 executing on a client device 114 (e.g., a computer platform such as a laptop computer, desktop computer, tablet computer, smart phone, wearable computer, or network device). In one example, for a cloud service instance corresponding to a software as a service (SaaS) cloud service model, the client can be an Internet browser instance (e.g., an Internet browser instance having a specific plug-in or executing a specific script 116 for generating the API request). In another example, for the purpose of interacting with a cloud service instance, the client can be an application instance 115 provided by the cloud service provider and dedicated to providing the API request 116. In another example, the client can correspond to an API platform application that constructs and generates the API request. In another example, the client can be a web-based developer portal 124 that constructs, generates, and tests the API request. In another example, the client can be an operating system (e.g., an operating system hosted on the client device 114), and the API request 116 can be generated in response to a command provided to the operating system via a shell or script (e.g., a curl command for a LINUX operating system). In another example, the client can be a microservice (e.g., a microservice provided by a cluster of pods hosted on the client device 114).

[0027] In the context used herein, an "endpoint" of a cloud service instance refers to a network-addressable communication interface associated with the cloud service instance. In one example, the endpoint can be virtual (e.g., an endpoint provided via a virtual service mesh gateway or virtual network device). In another example, the endpoint can correspond to a physical hardware component (e.g., an actual or physical network device). In one example, the endpoint can be an API endpoint dedicated to receiving API requests directed to the associated cloud service instance. The endpoint has an associated location or address. In one example, the address of the endpoint can be an IP address. DNS associates a domain name with the IP address, and the domain name is another example of an endpoint address.

[0028] In the context used herein, a "domain name" refers to a string of human-readable text associated with an IP address. The string includes a series of domains that are sorted according to the DNS hierarchy and separated by a "." delimiter. Generally, a domain name includes a top-level domain, a second-level domain, and zero, one, or more other domains that can be referred to as "subdomains". The DNS hierarchical order is indicated in the direction from right to left of the domain name.

[0029] To generate the CDN-provided API requests 190 or 192 from the API request 116 provided by the client, the CDN 130 extracts information from the API request 116, which is used as an index value for use with the global routing table 156 of the global data repository 154. In this way, according to an example embodiment, the index value identifies a particular entry or record of the global routing table 156, and the CDN 130 reads data from the identified record, which represents the endpoint location for the cloud service instance corresponding to the API request 116. The CDN 130 can then generate a request URL for the API request 190 or API request 192 provided by the routing engine, which includes the endpoint location.

[0030] According to an example embodiment, components of the computer network 100, such as the client device 114 hosting the cloud service client (e.g., the application 115), the CDN 130, the global resources 160, and the regional resources 184, can be interconnected via the network fabric 120. According to an example embodiment, the network fabric 120 can be associated with one or more types of communication networks, such as (by way of example) a Fibre Channel network, a Compute Express Link (CXL) fabric, a dedicated management network, a local area network (LAN), a WAN, a global network (e.g., the Internet), a wireless network, or any combination thereof.

[0031] As Figure 1A depicted, according to an example embodiment, the regional resources 184 can be located in different geographic service regions 180 (also referred to herein as "geographic regions"). For any of a variety of reasons, it can be beneficial to geographically partition resources into different geographic service regions for a particular cloud service. In one example, as Figure 1A depicted, the regional cloud service can manage the devices 110 of a particular deployment 104. In one example, the particular deployment 104 can be a set of managed servers 110 located in or near one of the multiple geographic regions 180. For this example, a regional cloud service, such as a compute operations (or "compute ops") cloud service, can be used to manage the servers 110. The compute operations service can, for example, manage the installation of firmware package upgrades on the servers or the installation of the operating system on the servers. For reasons such as coordinating maintenance windows for scheduling with server downtime, it can be advantageous for the regional resources 184 hosting the compute operations service instances to be in the same or a nearby time zone as the servers 110.

[0032] In another example, the managed devices 110 of a particular deployment 104 can be a set of network devices located in or near one of multiple geographic service regions 180. For this example, a network management system (NMS) cloud service can be used to manage the managed devices 110. For example, an instance of the NMS cloud service can monitor network telemetry metrics reported by the network devices 110, perform ongoing network performance analysis, or perform other management functions. For various reasons such as enhancing the responsiveness of the NMS service to changing network conditions and enhancing telemetry metric reporting, it can be advantageous for the regional resources 184 hosting the NMS service instance to be geographically close to the managed network devices 110.

[0033] Compared to regional cloud services, global cloud services generally do not benefit from geographic restrictions imposed on their hosted resources. In one example, the global resources 160 can host global service instances 168 related to identity and access management (IAM) of cloud resources. In other examples, the global resources 160 can host global service instances 168 related to managing information related to user accounts and subscriptions for compute operations or NMS services.

[0034] In the context used herein, "resource" (also referred to herein as "compute-related resource") refers to a virtual or physical component that supports a computing environment. In an example, a resource can be a computer platform (e.g., a blade server or a rack server) or a partition of a computer platform (e.g., multiple nodes of a particular server associated with different operating system instances). In another example, a resource can be a hardware component such as a memory device, a central processing unit (CPU) core, a graphics processing unit (GPU) core, a trusted platform module (TPM), a baseboard management controller (BMC), an intelligent input / output (I / O) peripheral device (or "data processing unit" or "DPU"), an expansion card, an I / O bridge, a security inserter device, a storage controller, a storage device, a cache, or a bus controller. In other examples, a resource can be software such as an operating system, a hypervisor, middleware, utilities, applications, or firmware. In other examples, a resource can be a virtualization technology component such as a container management engine, a container, a container pod, a container pod cluster, a network virtualization layer, a storage virtualization layer, a virtual machine, a hypervisor, a virtual TPM, or a virtual BMC. In other examples, a resource can be a physical file system, a virtual file system, a hybrid file system, or a network file system. In another example, a resource can be a database. In another example, a resource can be a microservice.

[0035] A cloud service instance (e.g., global service instance 168 or regional service instance 188) can correspond to any one of several cloud service models. In one example, a cloud service instance can correspond to an Infrastructure as a Service (IaaS) cloud service model, where the cloud service provider provides the infrastructure (e.g., computing, virtualization management, storage, and network components) for a computing environment, and the customer is responsible for providing and managing the non-infrastructure resources of the computing environment, such as virtual machines, containers, middleware, operating systems, applications, and data. In another example, a cloud service instance can correspond to a SaaS cloud service model, where the cloud service provider provides and manages a specific application, including providing and managing the entire application stack and the infrastructure that supports the computing environment. In another example, a cloud service instance can correspond to a Platform as a Service (PaaS) cloud service model, where the cloud service provider provides and manages the infrastructure and support software for a computer environment designed for developing a customer's application. In other examples, a cloud service instance can correspond to another cloud service model, such as a Container as a Service (CaaS) cloud service model or a Desktop as a Service (Daas) cloud service model.

[0036] The global resources 160 and the regional resources 184 can physically be located in any one of several different computing facilities. In one example, the global resources 160 can be located in one or more data centers (e.g., a single data center, multiple data centers located in the same availability zone, or multiple data centers distributed across multiple availability zones). In one example, the regional resources 184 for a specific geographic service area 180 can be located in one or more data centers within the geographic service area 180 (e.g., a single data center in the geographic service area 180, multiple data centers within the same availability zone in the geographic service area 180, or multiple data centers distributed across multiple availability zones within the geographic service area 180).

[0037] According to some embodiments, the computer network 100 can be associated with a public cloud. In this way, the cloud service provider can maintain and manage the global resources 160 and the regional resources 184 for providing cloud service instances to public subscription members over the Internet. Additionally, in one example, the global resources 160 and the regional resources 184 can be owned by the cloud service provider.

[0038] According to additional embodiments, computer network 100 may be associated with a private cloud. In one example, a commercial enterprise may own global resources 160 and regional resources 184, and the commercial enterprise may act as a provider for managing and maintaining the global resources 160 and the regional resources 184 for providing service instances for the commercial enterprise's own use. In another example, the global resources 160 and the regional resources 184 may be located in leased space in a (multiple) co-located data center, and the commercial enterprise may act as a provider of service instances for the commercial enterprise's own use. In another example, a cloud service provider other than the commercial enterprise may own the global resources 160 and the regional resources 184, and the cloud operator may manage and maintain the global resources 160 and the regional resources 184 for providing cloud service instances for the commercial enterprise. In another example, a cloud service provider other than the commercial enterprise may own and maintain the global resources 160 and the regional resources 184, and the global resources 160 and the regional resources 184 may be located on property owned or leased by the commercial enterprise. Additionally, for this example, the cloud service provider may manage and maintain the global resources 160 and the regional resources 184 for providing cloud service instances to the commercial enterprise.

[0039] According to additional embodiments, computer network 100 may be associated with a cloud other than a public cloud or a private cloud. In one example, computer global resources 160 and regional resources 184 may correspond to a community cloud that provides cloud services for members of a particular community group or members sharing a common interest. In another example, global resources 160 and regional resources 184 may correspond to a hybrid cloud that is a hybrid of two or more of a private cloud, a public cloud, and a community cloud.

[0040] In the context used herein, "content delivery network" or "CDN" refers to a geographically distributed infrastructure that enhances communication between a server and a client of the server. For Figure 1A the example embodiments depicted, the CDN enhances communication between a cloud service instance (which may be considered a server) and a client of the cloud service instance. In the example embodiments described herein, the CDN 130 enhances communication by performing dynamic routing of API requests provided by the client. According to example embodiments, the CDN 130 may enhance communication between a server and a client of the server in one or more additional ways. In one example, the CDN 130 may cache frequently provided static content from a server (e.g., a service instance) to offload overhead from the server and reduce latency otherwise incurred in delivering the content to the client. In another example, the CDN 130 may employ one or more measures (e.g., a relatively high bandwidth connection to the server and predictive prefetching of data from the server) to enhance the delivery of dynamic data from a server (e.g., a service instance) to a server.

[0041] According to an example embodiment, the CDN 130 has edge servers 140 that are geographically distributed across different Points of Presence (POPs) 134. In this manner, as depicted in Figure 1A one or more edge servers 140 can be located at a particular POP 134. The "edge" designation of the servers 140 refers to servers that are located at the edge of the network. In this context, the "network edge" refers to a portion of the network (e.g., computer network 100) that is associated with an entry point of the network. A local branch network (e.g., a Local Area Network (LAN)) is an example of the network edge. According to an example embodiment, the edge servers 140 can be geographically distributed across branch networks that include client devices 114 such that each client device 114 is geographically close to a particular POP 134 and the edge servers 140 of the POP.

[0042] According to an example embodiment, the CDN network 130 is associated with a DNS server that, in response to a DNS query for certain domain names, provides an IP address corresponding to an edge server 140. In one example, in response to a request URL that includes a particular domain name (e.g., a domain name in the format "<region>.<cloud provider>"), the DNS server selects an edge server 140 and provides a DNS response that includes the IP address of the selected edge server 140. The selection of a particular edge server 140 by the DNS server can be based on any one of several criteria, such as the number of hops from the edge server 140 to the client, the geographical location of the edge server 140, the instantaneous time of communication between the edge server 140 and the client, the load on all edge servers 140 associated with a particular POP 134, or one or more of other criteria.

[0043] Regardless of how an edge server 140 is selected for the purpose of processing an API request 116 provided by a particular client, according to an example embodiment, the routing engine 150 of the selected edge server 140 receives and processes the API request 116 provided by the client for routing or forwarding the API request 116 provided by the client to an appropriate cloud service instance endpoint. More specifically, according to an example embodiment, the routing engine 150 extracts information from the API request 116 provided by the client, which allows the routing engine 150 to look up the address of the endpoint of the cloud service instance from a global routing table 156. Then, according to an example embodiment, the routing engine 150 can generate a CDN-provided API request (e.g., API request 190 or 192) that specifies the endpoint address (e.g., a domain name or an IP address) of the cloud service instance, as well as other information from the original API request 116 provided by the client. The routing engine 150 sends the CDN-provided API request to the cloud service instance endpoint via DNS routing.

[0044] According to an example embodiment, for the purpose of routing an API request 116 provided by a client, a routing engine 150 processes the request 116 to extract a geographic service area identifier (also referred to herein as a "geographic area identifier"), an API call group identifier, and a client identifier from the request 116. The geographic service area identifier indicates whether the API request 116 provided by the client is directed to a global or regional cloud service instance, and for a regional cloud service instance, the geographic service area identifier also identifies a specific geographic service area. The API call group identifier indicates the category or classification of the underlying API call (e.g., a compute operation management API call group, a device management API call group, or a backup and recovery API call group). The client identifier identifies the client that generated the API request 116 provided by the client.

[0045] According to an example embodiment, the geographic service area identifier corresponds to a subdomain (e.g., the subdomain corresponding to "<region>") of a domain name specified by a request URL of the API request 116 provided by the client (e.g., a domain name having the format "<region>.<cloud provider>"). In one example, the geographic service area identifier for a global cloud service instance may be "global", and an API request 116 provided by a client that is directed to the global service instance 168 includes a request URL that specifies the following domain name: "global.<cloud provider>".

[0046] In another example, an API request 116 provided by a client that is directed to a regional cloud service instance has a subdomain in its corresponding request URL that identifies the appropriate geographic service area 180. In one example, the regional geographic service area identifier for the western United States region may be the subdomain "us-west". Continuing with this example, an API request 116 provided by a client that is directed to the regional service instance 188 located in the western United States geographic service area may include a request URL that specifies the following domain name: "western united states.<cloud provider>".

[0047] According to an example embodiment, an API call group identifier is specified in a resource path of a request URL of an API request 116 provided by a client. In one example, the request URL may include the following: "<region>.<cloud provider> / <API group>". Here, "<API group>" represents the API call group identifier. In one example, the API call group identifier may be a string of human-readable text corresponding to a specific cloud service. In one example, for an API call for a network device management cloud service, "devices", "device-mngmt", or another descriptive text string may be used as the API call group identifier and included as part of the resource path of the request URL. For example, the request URL may include the following: "<region>.<cloud provider> / devices…". In one example, for an API call for an identity and access management (IAM) cloud service, "iam", "id&access-mngmt", or another descriptive text string may be used as the API call group identifier and included as part of the resource path of the request URL. In one example, for an API call for a network cloud service, "network", "networking", or another descriptive text string may be used as the API call group identifier and included as part of the resource path of the request URL. In one example, for an API call for a backup and recovery cloud service, "b&r", "backup-recovery", or another descriptive text string may be used as the API call group identifier and included as part of the resource path of the request URL.

[0048] According to an example embodiment, the resource path of a URL can include content representing one or more subcategories of an API call group. In one example, a request URL can include the following content: "<region>.<cloud provider> / <API group> / <subgroup>", where "<subgroup>" represents a text string or other identifier corresponding to an API call subgroup (e.g., a numeric or alphanumeric identifier (including numbers and letters)). In one example, "topology" or a similar text string can represent a subgroup of API calls for a network service that is directed to a network topology. In one example, "version-one", "V1", or a similar text string can represent a specific version of an API call for an API call group. In another example, a request URL can include the following content: "<region>.<cloud provider> / <API group> / <subgroup-1>... / <subgroup-n>", where "<subgroup-n>" corresponds to the nth subgroup out of n subgroups of an API call group. In one example, a request URL for a network service-related API that is directed to version one and to topology can include the following content: "<region>.<cloud provider> / v1 / topology".

[0049] According to an example embodiment, the client identifier is represented by an authentication bearer token (ABT) of an API request 116 provided by the client. Generally speaking, an ABT is a value assigned by a server to a client in response to a client's request to access a protected resource controlled by the server. A server hosting a cloud service instance or otherwise associated with managing access to a cloud service instance can assign an ABT to a client after the server authenticates the client. The client can then include the ABT in an API request, such as API request 116 provided by the client, to obtain access to the cloud service instance via an API call. According to an example embodiment, the server that provides the ABT token injects the client identifier into the ABT token. As the name implies, the client identifier specifically identifies the client that provides API request 116.

[0050] The server can inject the client identifier into the ABT token in any of a variety of different ways. In one example, the server can inject the client identifier into the ABT token by concatenating a token value (e.g., a randomly generated or pseudo-randomly generated value) and the client identifier to form an ABT. In another example, the ABT can be a JavaScript Object Notation (JSON) web token or a "JWT", and the server can embed the client identifier into the payload of the JWT. Regardless of how the client identifier is injected into the ABT, the routing engine 150 has knowledge of how to extract the client identifier from the ABT.

[0051] Figure 1B depicts an example global routing table 156 according to an example embodiment. In conjunction with Figure 1A reference to Figure 1B , in the context used herein, the table 156 being "global" means that the table 156 is accessible by an entity regardless of the geographical location of the entity. The routing engine 150 can access the global routing table 156 for determining the endpoint location of a cloud service instance, and furthermore, as described herein, the global routing table 156 can be accessed and updated by the cloud environment management engine 162, the cloud service manager, for dynamically changing the CDN routing of an API request.

[0052] The global routing table 156 includes entries or records 193. Each record 193 is associated with a specific cloud service instance and sets forth the location or address of the endpoint of the cloud service instance. More specifically, according to an example embodiment, the record 193 includes three fields that serve as a tuple-based index to uniquely identify the record 193: a field 194 that contains data representing a client identifier; a field 195 that contains data representing a geographical service area identifier; and a field 196 that contains data representing an API call group identifier. The record 193 also contains a field 197 that contains data representing the location or address of the endpoint for the cloud service instance corresponding to the client identifier, geographical service area identifier, and API call group identifier. In one example, the location or address of the endpoint can be a domain name or an IP address.

[0053] The routing engine 150 can determine the endpoint address for a cloud service instance as follows. The routing engine 150 can first read data from the global routing table 156 for identifying a specific record 193 of the table 156 that corresponds to the client identifier, geographical service area identifier, and API call group identifier extracted from an API request 116 provided by a client. The routing engine 150 can then read data from the endpoint field 197 of the identified record 193, which represents the endpoint address.

[0054] According to an example embodiment, the global routing table 156 can be updated by the cloud environment management engine 162 to dynamically change the mapping between a client and the corresponding cloud service instance. According to an example embodiment, a (client identifier, geographical service area identifier, API call group identifier) tuple maps to a single cloud service instance. Furthermore, according to an example embodiment, a specific cloud service instance can be a multi-tenant instance. Thus, multiple different (client identifier, geographical service area identifier, API call group identifier) tuples can be mapped to the same cloud service instance.

[0055] The cloud environment management engine 162 can determine to switch the workload of a specific client from one cloud service instance to another. To implement this change from the perspective of API request routing, the cloud environment management engine 162 can update the corresponding record 193 of the global routing table 156 by writing to field 197 to replace the endpoint address associated with the old cloud service instance with the endpoint address associated with the new cloud service instance. Since the cloud service provider can control CDN-based API routing in this way, the client is unaware of the endpoint location of the cloud service instance, and changing the CDN routing does not affect the content of the API request 116 provided by the client.

[0056] In the context used herein, "workload" generally refers to information associated with a client. In one example, the workload can include a set of computing system-related jobs or tasks (e.g., computing, networking, storage, or database-related operations) to be processed by a cloud service instance. In another example, the workload can include the configuration associated with the client. In another example, the workload can include the data associated with the client. In another example, the workload can correspond to the tasks, data, and configuration associated with the execution of an application. In another example, the workload can correspond to the database associated with the client. In another example, the workload can correspond to the tasks, data, and configuration associated with developing an application. In another example, the workload can correspond to the tasks, data, and configuration associated with a virtualized environment (such as virtual machines, containers, container pods, or container pod clusters). In another example, the workload can correspond to management-related tasks, data, and configuration, such as tasks, data, and configuration related to managing a server group or managing a network device group. In another example, the workload can correspond to HPC tasks and related data and configuration.

[0057] Return reference Figure 1A Returning to reference, according to some embodiments, the edge server 140 includes one or more hardware processors 146 and a memory 144. In one example, the hardware processor 146 can include one or more central processing unit (CPU) cores and / or one or more graphics processing unit (GPU) cores. In another example, the hardware processor 146 can include one or more semiconductor CPU packages (or "sockets"). In another example, the hardware processor 146 can include one or more GPU packages.

[0058] Memory 144 and other memories of computer network 100 include non-transitory storage media, which may be formed by semiconductor storage devices, memristor-based storage devices, magnetic storage devices, phase change storage devices, and combinations of devices of one or more of these storage technologies, etc. Memory 144 may represent a memory collection of both volatile memory devices and non-volatile memory devices.

[0059] In one example, hardware processor 146 may execute machine-readable instructions, such as machine-readable instructions 145 stored in memory 144, to provide one or more software components of edge server 140, such as routing engine 150. According to additional embodiments, hardware processor 146 may be a hardware circuit that does not execute machine-executable instructions, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device, a programmable logic device (PLD), or other hardware dedicated to providing one or more functions for edge server 140.

[0060] According to some embodiments, cloud environment management engine 162 may be hosted on a server. The server may include, for example, one or more hardware processors 174 and memory 170. In one example, hardware processor 174 may include one or more CPU cores and / or one or more GPU cores. In another example, hardware processor 174 may include one or more CPU sockets and / or one or more GPU packages.

[0061] In one example, hardware processor 174 may execute machine-executable instructions, such as machine-readable instructions 172 stored in memory 170, for the purpose of providing cloud environment management engine 162. In another example, hardware processor 174 may be a hardware circuit that does not execute machine-executable instructions, such as an ASIC, an FPGA, a PLD, or other hardware.

[0062] As used in the context herein, a "network device" refers to an actual or physical electronic component that enables data communication between other components. In one example, a network device may be a switch that operates at layer two (L2) of the Open Systems Interconnection (OSI) model to connect components of a computer network together. In another example, a network device may be a layer three (L3) switch that connects components of a computer network together and connects computer networks together. In other examples, a network device may be a gateway, a multicast router, a bridge, a component of a Gen-Z or CXL network, a processor device, a network interface controller (NIC), or a fabric switch that includes one of multiple aforementioned devices. A network device may be a wired or wireless device.

[0063] Figure 2AFIG. 200 is an illustration of a client-provided API request according to an example embodiment. The client-provided API request 200 is a more specific example of the client-provided API request 116 discussed above in connection with Figure 1A Referring to Figure 2A , according to an example embodiment, the client-provided API request 200 includes a message header 202 and a body 260. In one example, the message header 202 includes data representing a method 204 and data representing a request URL 212.

[0064] The method 204 specifies an operation. In one example, for a REST API, the method can specify get, post, put, patch, delete, or other operations. The request URL 212 includes a CDN endpoint domain name 214. As described herein, generally, the CDN endpoint domain name 214 routes the client-provided API request 200 to an edge server of the CDN, such as Figure 1A the CDN 130. The CDN endpoint domain name 214 can include a domain 216 that designates the client-provided API request 200 as being affiliated with an API call and with a particular cloud service provider.

[0065] The CDN endpoint domain name 214 can also include a subdomain 220 corresponding to a specific geographic service area identifier 224. In an example of a client-provided API request 200 that points to a regional service instance, the CDN endpoint domain name 214 can be in the format "<specific geographic region>.<cloud provider>", where "<specific geographic region>" represents one or more domains corresponding to a specific geographic service area. In an example of a client-provided API request 200 that points to a global service instance, the CDN endpoint domain name 214 can be in the format "<global>.<cloud provider>", where "<global>" represents one or more domains that specify a global cloud service.

[0066] The request URL 212 also includes a resource path 228. The resource path 228 can specify an API call group identifier 232. Additionally, the resource path 228 can specify one or more API call subgroups. According to an example embodiment, the resource path 228 can also include one or more parts that specify a resource that operates on or is accessed by the underlying API call. The request URL 212 can also specify one or more query parameters 236. In one example, the (multiple) query parameters 236 can include one or more API call parameters 240 specific to the underlying API call. In one example, the (multiple) API call parameters 240 can specify one or more resource selection criteria specific to the underlying API call.

[0067] The API request 200 provided by the client may include one or more headers in addition to the message request header 202. As depicted in FIG. 2, according to an example embodiment, the API request 200 provided by the client includes a header 250, and the header 250 contains data representing the ABT 254. In addition, according to an example embodiment, the ABT 254 includes an injected subset of data representing the client identifier 258. Since the header 250 is not part of the message request header 202, including the ABT 254 in the header 250 does not change the signature associated with the API request 200 provided by the client.

[0068] Among its other features, the API request 200 provided by the client may include a body 260. The content of the body 260 may depend on the specific underlying API call. In one example, for the operations of the POST or PUT methods 204, the body 260 may contain payload data for the operation. In another example, the body 260 may contain data specifying the format of the data to be returned in the corresponding API response. In another example, the body 260 may specify one or more parameters for the underlying API call.

[0069] Figure 2B is an illustration of the API request 270 provided by the CDN according to an example embodiment. The API request 270 provided by the CDN is a more specific example of the API request 190 or API request 192 provided by the CDN discussed above in connection with Figure 1A discussed CDN-provided API requests 190 or API request 192. In connection with Figure 2A Reference Figure 2B According to an example embodiment, the API request 270 provided by the CDN has information carried from the corresponding client-provided API request 200. In one example, the API request 270 provided by the CDN contains data representing the method 204, query parameters 236, authorization bearer token 254, and body 260 from the corresponding client-provided API request 200.

[0070] In addition to including data representing the method, the message request header 272 of the API request 270 provided by the CDN also includes a request URL 272, which is different from the request URL 212 of the client-provided API request 200. Specifically, the request URL 272 specifies a service instance endpoint address 274. In this way, the service instance endpoint address 274 can be obtained from a global routing table (such as Figure 1B the global routing table 156). In one example, the service instance endpoint address 274 may be a domain name. In another example, the service instance endpoint address 274 may be an IP address.

[0071] According to an example embodiment, a resource path 276 of a request URL 272 of an API request 270 provided by a CDN includes information carried by a resource path 228 of an API request 200 provided by a client. In one example, the resource path 276 is the same as the resource path 228. In another example, the resource path 276 is the same as the resource path 228 except that some items are removed (e.g., an API call group identifier).

[0072] Figure 3 is an illustration 300 of CDN-based routing of an API request according to an example embodiment. Referring Figure 3 , example API requests 304, 316, 330, and 344 provided by a client are routed to a CDN 301 via DNS routing. In one example, the CDN 301 may have features that are the same as or similar to Figure 1A the CDN 130. The CDN 301 routes the API requests 304, 316, 330, and 344 provided by the client to endpoints 378, 388, 392, and 396 for corresponding cloud service instances, respectively. Although Figure 3 not depicted in, as described herein, the routing of the API requests provided by the client by the CDN 301 involves generating corresponding CDN-provided API requests that are sent from the CDN 301 to the cloud service instances.

[0073] The API request 304 provided by the client includes a request URL 308 that includes content in the format of "<US West>.<Cloud Provider ABC> / <Data Service>". For this example, "<US West>" represents one or more domains corresponding to the geographic service region 376 of the western United States; "<Cloud Provider ABC>" represents one or more domains corresponding to a specific cloud service provider; and "<Data Service>" represents one or more domains corresponding to API calls related to a set of data services. The API request 304 provided by the client also includes an ABT 310 with an injected client identifier 312. Based on the client identifier 312, the "<US West>" geographic service region identifier, and the "<Data Service>" API call group identifier, the CDN 301 routes the API request 304 provided by the client to the endpoint 378, as represented by the routing path 360. In this context, "routing" an API request provided by the client (e.g., API request 304) to an endpoint (e.g., endpoint 378) includes modifying the API request provided by the client to provide a CDN-provided API request, as described herein.

[0074] For this example, endpoint 378 corresponds to a Data Service Cloud Computing (DSCC) instance 380, which is a cloud service instance hosted by resources in the Western United States geographic service region 376. Figure 3 Another Data Service Cloud Computing instance 382 of the Western United States geographic service region 376 is also depicted, which is associated with endpoint 382 and is not assigned or mapped to client identifier 312.

[0075] The client-provided API request 316 includes a request URL 320, which contains content in the format of "<Central Europe of the European Union (EU)>. <Cloud Provider ABC> / <Networking Service>". For this example, "<Central Europe of the EU>" represents one or more domains corresponding to the Central Europe of the EU geographic service region 386, and "<Networking Service>" represents one or more domains corresponding to a set of API calls related to network services. The client-provided API request 316 also includes an ABT 324 with an injected client identifier 326. Based on the client identifier 326, the "<Central Europe of the EU>" geographic service region identifier, and the "<Networking Service>" API call group identifier, the CDN 301 routes the client-provided API request 316 to endpoint 388, as indicated by the routing path 364. For this example, endpoint 388 corresponds to a Network Service Cloud Computing (NWSCC) instance 390, which is a cloud service instance hosted by resources in the Central Europe of the EU geographic service region 386.

[0076] The client-provided API request 330 includes a request URL 334, which contains content in the format of "<Southern Asia-Pacific (AP)>. <Cloud Provider ABC> / <Networking Service>". For this example, "<Southern Asia-Pacific>" represents one or more domains that specify the API request 330 as being directed to the Southern Asia-Pacific geographic service region 391. The client-provided API request 330 also includes an ABT 338 with an injected client identifier 340. Based on the client identifier 340, the "<Southern Asia-Pacific>" geographic service region identifier, and the "<Networking Service>" API call group identifier, the CDN 301 routes the client-provided API request 330 to endpoint 392, as indicated by the routing path 368. For this example, endpoint 392 is an NWSCC instance 393 hosted by resources in the Southern Asia-Pacific geographic service region 391.

[0077] The API request 344 provided by the client includes a request URL 348, and the request URL 348 includes content in the format of "<Global>.<Cloud Provider ABC> / <Identity and Access Management Service>". For this example, "<Global>" indicates that the API request 344 is specified as one or more domains directed to the global cloud service, and "<Identity and Access Management Service>" indicates one or more domains corresponding to a set of identity and access management related API calls. The API request 344 provided by the client also includes an ABT 352 with an injected client identifier 344. Based on the client identifier 344, the "<Global>" geographic service area identifier, and the "<Identity and Access Management Service> API call group identifier", the CDN 301 routes the API request 344 provided by the client to the endpoint 396, as represented by the routing path 372. For this example, the endpoint 396 corresponds to a global service instance 395 hosted by a global resource 394.

[0078] Figure 4 Is a sequence flow diagram 400 depicting actions and communications associated with routing an API request to a cloud service instance according to an example implementation. For this example, the edge server 410 and the global routing table 406 can be the same as or similar to the edge server 140 (see Figure 1A ) and the global routing table 156 (see Figure 1A and 1B ). Figure 4 Also depicted are a global service instance endpoint 424 associated with a global service instance hosted by a global resource 420 and a regional service instance endpoint 434 associated with a regional service hosted by a regional resource 430.

[0079] Refer to Figure 4 , the routing engine 414 of the edge server 410 can receive an API request 440. In one example, the API request 440 can be provided by a cloud service client. As depicted at 444, the routing engine 414 extracts a subdomain from the API request. According to an example implementation, the subdomain corresponds to a geographic service area identifier.

[0080] As depicted at 448, if the routing engine 414 determines that the API request 440 is directed to a global service instance, then the routing engine 414 determines the endpoint location for the global service instance. According to an example embodiment, this determination can include the routing engine 414 looking up the endpoint location of the global service instance from the global routing table 406 (e.g., looking up the endpoint location based on the geographic service area identifier, client identifier, and API call group identifier included in the API request 440). As depicted at 452, the routing engine 414 routes or forwards the API request 440 to the global service instance endpoint 424. The global service instance endpoint 424 can then process the forwarded API request 456, as depicted at 460. In this context, “forwarding” a client-provided API request (e.g., API request 440) to an endpoint (e.g., endpoint 424) includes modifying the client-provided API request to provide an API request provided by the CDN, as described herein.

[0081] As depicted at 448, if the routing engine 414 determines that the API request 440 is directed to a regional service instance, then the routing engine 414 determines the endpoint location for the regional service instance. According to an example embodiment, this determination can include the routing engine 414 extracting the client identifier, geographic service area identifier, and API call group ID from the API request 440, as depicted at 464. As depicted at 468, the routing engine 414 can then access the global routing table 406 for looking up the endpoint location 472 for the regional service instance. As depicted at 476, the routing engine 414 routes or forwards the API request 440 to the regional service instance endpoint 434. This includes the routing engine 414 modifying the API request 440 to modify the request URL in addition to other possible modifications such that the corresponding forwarded API request 480 is routed to the regional service instance endpoint 434. The regional service instance endpoint 434 can then process the forwarded API request 480, as depicted at 484.

[0082] Figure 5 is a sequence flow diagram 500 depicting actions and communications associated with migrating client workload 518 between regional service instances 512 and 520 according to an example embodiment. The sequence flow diagram illustrates the dynamic API request routing capabilities created via the global routing table 504. For this example, regional service instances 512 and 520 are part of the same geographic service area 516. Additionally, for this example, the cloud environment management engine 508 can have the same or similar characteristics as the cloud environment management engine 162 (reference Figure 1A )

[0083] Reference Figure 5, as depicted at 508, the cloud environment management engine 508 can determine whether the client workload 518 should be migrated from the regional service instance 512 to another regional service instance (for the example of being the regional service instance 520). In Figure 5 the example depicted in, the regional service instance 512 is a multi-tenant service instance that supports the client workload 518 and one or more other client workloads 521. In this way, Figure 5 the client workload 518 associated with the regional service instance 512 is depicted at 517, and the additional client workload 521 (for other tenants) associated with the regional service instance 512 is depicted at 519.

[0084] The cloud environment management engine 508 can determine whether to migrate a workload such as workload 518 from one service instance to another based on one or more criteria. In one example, the cloud environment management engine 508 can detect a resource contention issue among the tenants of the instance 512. Continuing with this example, the cloud environment management engine 508 can determine that for the purpose of resolving the contention issue, the client workload 518 should be migrated to the regional service instance 520. In another example, the client associated with the client workload 518 can request an expansion of the resources for the client workload 518. In response to this request, the cloud environment management engine 508 can determine to migrate the workload 518 to the regional service instance 520. In another example, based on the measured performance metrics associated with the regional service instance 512, the cloud environment management engine 508 can determine to migrate the client workload 518 to the regional service instance 520. In another example, for instance, the client associated with the client workload 518 can upgrade the service subscription so that the client workload 518 will be processed by a single-tenant workload, and in response to the upgrade, the cloud environment management engine 508 instantiates the regional service instance 520 and migrates the client workload 518 to the regional service instance 520.

[0085] As depicted at 530, if the cloud environment management engine 508 determines to migrate the client workload 518, then the cloud environment management engine 508 identifies the destination service instance for the workload 518. For Figure 5 the example implementation depicted in, the regional service instance 520 is the destination service instance. As depicted at 534, the cloud environment management engine 508 migrates the client workload from the regional service instance 512 to the regional service instance 520. This migration can include the cloud environment management engine 508 initiating migration operations for the regional service instance 512 and the regional service instance 520, as depicted at 544 and 550.

[0086] In one example, migration operations 544 and 550 may include the operation of migrating one or more virtual machines from regional service instance 512 to regional service instance 520. In another example, migration operations 544 and 550 may include the operation of migrating one or more applications from regional service instance 512 to regional service instance 520. In another example, migration operations 544 and 550 may include the operation of migrating one or more databases from regional service instance 512 to regional service instance 520. After migration operations 544 and 550 are completed, the now-migrated client workload 518 is associated with regional service instance 520, as depicted at 518.

[0087] Associated with the migration of client workload 518, as depicted at 540, cloud environment management engine 508 updates global routing table 504 to remap client workload 518 to regional service instance 520. According to an example embodiment, the remapping includes cloud environment management engine 508 updating a corresponding record (i.e., a record corresponding to the client identifier associated with client workload 518, the geographic service region associated with region 516, and the appropriate API call group identifier) to change the endpoint location from regional service instance 512 to regional service instance 520.

[0088] According to an example embodiment, a client workload may be migrated from one global cloud service instance to another global cloud service instance in a similar manner.

[0089] Referring Figure 6 , according to an example embodiment, process 600 includes a server associated with a content delivery network receiving (block 604) a first request specifying an application programming interface (API) call to a cloud service. The first request includes data representing an authorization bearer token, a geographic service region identifier, and an API call group identifier. In one example, the server may be associated with a point of presence (POP). In one example, the server may be an edge server. In one example, the edge server may be located in a branch network containing the client (e.g., an application) that generated the first request. SaaS, IaaS, PaaS, CaaS, or DaaS cloud service instances.

[0090] In one example, the first request may include a request for a Uniform Resource Locator (URL). In one example, the requested URL may specify an endpoint location corresponding to a server. In one example, the requested URL may include a domain name having a subdomain corresponding to a geographic service area identifier. In one example, the cloud service may be a regional cloud service, and the subdomain name may identify a specific geographic service area. In one example, the geographic service area identifier may indicate that the service instance is a global instance. In one example, the requested URL may include query parameters that identify one or more API call parameters.

[0091] Process 600 includes the server routing (block 608) an API call to an instance of a cloud service. The routing includes: the server determining a client identifier based on an authorization bearer token; the server identifying the location of the instance based on the client identifier, a geographic region identifier, and an API call group identifier; and in response to the identification, the server sending a second request corresponding to the API call to the location.

[0092] In one example, the client identifier may be injected into the authorization bearer token of the API request. The authorization bearer token may include an authorization value assigned by the server to the client that generated the first request. In one example, the authorization bearer token may be a concatenation of the authorization value and a value corresponding to the client identifier. In another example, the authorization bearer token may be a JSON web token, and the client identifier may be represented by data in the payload of the JSON web token. In one example, the authorization bearer token may be included in the header of the first request separate from a message header that includes a geographic service area identifier and an API call group identifier. In one example, the location of the instance may be represented by a domain name. In another example, the location of the instance may be represented by an IP address. In one example, identifying the location of the instance includes accessing a global routing table. In one example, identifying the location of the instance includes identifying an entry or record in the global routing table and reading the location from the identified record.

[0093] In one example, the API call group identifier identifies a specific group of related API calls for the cloud service. In one example, the API call group identifier may be specified in the resource path of the URL of the first request. In one example, the second request may include data from the first request that is modified to replace the endpoint corresponding to the server with the location of the instance.

[0094] Reference Figure 7, According to an example embodiment, the non-transitory storage medium 700 stores machine-readable instructions 710 that, when executed by a machine associated with a point of presence of a content delivery network, cause the machine to access an application programming interface (API) request directed to a service; process the API request to determine a client identifier associated with the API request, a geographic region associated with the API request, and an API service group associated with the API request. In one example, the machine can be an edge server. In one example, the machine can be located in a branch network that includes a client (e.g., an application) that generated a first request. In one example, the API request can correspond to an API call directed to a SaaS, IaaS, PaaS, CaaS, or DaaS cloud service instance.

[0095] In one example, the API request can include a request uniform resource locator (URL). In one example, the request URL can specify an endpoint location corresponding to the machine. In one example, the request URL can include a domain name having a subdomain corresponding to a geographic service area identifier. In one example, the cloud service can be a regional cloud service, and the subdomain name can identify a specific geographic service area. In one example, the geographic service area identifier can indicate that the service instance is a global instance. In one example, the request URL can include query parameters that identify one or more API call parameters.

[0096] According to an example embodiment, the instructions 710, when executed by the machine, also cause the machine to access location information stored in a global data repository based on the client identifier, the geographic region, and the API service group. The location corresponds to an instance of the service. The instructions 710, when executed by the machine, also cause the machine to route the API request to the instance based on the location information.

[0097] In one example, the client identifier can be injected into an authorization bearer token of the API request. The authorization bearer token can include an authorization value assigned by a server to the client that generated the first request. In one example, the authorization bearer token can be a concatenation of the authorization value and a value corresponding to the client identifier. In another example, the authorization bearer token can be a JSON web token, and the client identifier can be represented by data in the payload of the JSON web token. In one example, the authorization bearer token can be included in a header of the first request separate from a message header that includes a geographic service area identifier and an API call group identifier. In one example, the location of the instance can be represented by a domain name. In another example, the location of the instance can be represented by an IP address. In one example, identifying the location of the instance includes accessing a global routing table. In one example, identifying the location of the instance includes identifying an entry or record in the global routing table and reading the location from the identified record.

[0098] ReferenceFigure 8 , according to an example embodiment, apparatus 800 includes a hardware processor 812 and a memory 804. The hardware processor 812 is associated with a point of presence of a content delivery network. The memory 804 stores machine-readable instructions 808 that, when executed by the hardware processor 812, cause the hardware processor 812 to receive an API request directed to a service; determine a geographic region identifier from a subdomain name of a uniform resource location (URL) based on first data represented by the API request, and determine an API call group identifier from a path of the URL. In one example, the hardware processor 812 may include a CPU processing core or a GPU core. In one example, the hardware processor 812 may be a component of an edge server. In one example, the machine may be located in a branch network that includes a client (e.g., an application) that generated the first request. In one example, the API request may correspond to an API call directed to a SaaS, IaaS, PaaS, CaaS, or DaaS cloud service instance.

[0099] In one example, the API request may include a requested uniform resource location (URL). In one example, the requested URL may specify an endpoint location corresponding to the machine. In one example, the requested URL may include a domain name having a subdomain corresponding to a geographic service region identifier. In one example, the cloud service may be a regional cloud service, and the subdomain name may identify a specific geographic service region. In one example, the geographic service region identifier may indicate that the service instance is a global instance. In one example, the requested URL may include query parameters that identify one or more API call parameters.

[0100] When executed by the hardware processor 812, the instructions 808 further cause the hardware processor 812 to determine a client identifier based on an authorization bearer token represented by second data of the API request; determine a location corresponding to the service instance based on the geographic region identifier, the API call group identifier, and the client identifier. When executed by the hardware processor 812, the instructions 808 further cause the hardware processor 812 to forward the API request to the location.

[0101] In one example, the client identifier can be injected into the authorization bearer token of the API request. The authorization bearer token can include an authorization value that is assigned by the server to the client that generated the first request. In one example, the authorization bearer token can be a concatenation of the authorization value and a value corresponding to the client identifier. In another example, the authorization bearer token can be a JSON web token, and the client identifier can be represented by data in the payload of the JSON web token. In one example, the authorization bearer token can be included in the header of the first request separate from the message header that includes the geographic service area identifier and the API call group identifier. In one example, the location of the instance can be represented by a domain name. In another example, the location of the instance can be represented by an IP address. In one example, identifying the location of the instance includes accessing the global routing table. In one example, identifying the location of the instance includes identifying an entry or record in the global routing table and reading the location from the identified record.

[0102] According to an example embodiment, identifying the location of the instance includes the server identifying an entry in the table based on the client identifier, the geographic service area identifier, and the API call group identifier; and reading the entry to determine the location of the instance. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner transparent to the cloud service clients.

[0103] According to an example embodiment, in response to the cloud service manager determining to migrate the workload associated with the client identifier from the first instance to the second instance, the entry is updated with data representing the location of the second instance. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner transparent to the cloud service clients.

[0104] According to an example embodiment, the data represents a uniform resource location (URL) and a header. The header includes an authorization bearer token. The client identifier can be determined based on the authorization bearer token. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner transparent to the cloud service clients.

[0105] According to an example embodiment, the data represents a uniform resource location (URL), and the URL includes a subdomain name that includes the geographic service area identifier. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner transparent to the cloud service clients.

[0106] According to an example embodiment, the data represents a Uniform Resource Locator (URL), and the URL includes a path that contains an API call group identifier. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner that is transparent to the cloud service clients.

[0107] According to an example embodiment, identifying the location of an instance includes: identifying a record in a lookup table based on a client identifier, a geographic service area identifier, and an API call group identifier; and in response to the identification of the record, reading the location of the instance from the record. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner that is transparent to the cloud service clients.

[0108] According to an example embodiment, the location of the instance corresponds to a second server among a plurality of servers located in a geographic service area corresponding to the geographic service area identifier. The plurality of servers host at least one other instance of the service. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner that is transparent to the cloud service clients.

[0109] According to an example embodiment, a third server other than the second server among the plurality of servers hosts an instance of at least one other instance. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner that is transparent to the cloud service clients.

[0110] According to an example embodiment, the location of the instance is in a geographic service area corresponding to the geographic service area identifier. The client identifier is constrained to a single instance of the service corresponding to the geographic service area. Among these specific advantages, the consistency of API call signatures is promoted, and the cloud service provider can dynamically control the allocation of service instances to cloud service clients in a manner that is transparent to the cloud service clients.

[0111] The detailed description set forth herein references the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the prior description to refer to the same or like parts. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only. Although several examples are described in this document, modifications, adaptations, and other embodiments are possible. Therefore, the detailed description does not limit the disclosed examples. Instead, the appropriate scope of the disclosed examples may be defined by the appended claims.

[0112] The terms used herein are for the purpose of describing particular examples only and are not intended to be limiting. As used herein, unless the context clearly dictates otherwise, the singular forms "a", "an" and "the" are also intended to include the plural forms. The term "plurality" as used herein is defined as two or more than two. The term "another" as used herein is defined as at least a second or more. Unless otherwise stated, the term "connected" as used herein is defined as either directly connected without any intermediate element or indirectly connected with at least one intermediate element. Two elements may be mechanically, electrically coupled, or communicatively linked through a communication channel, path, network or system. The term "and / or" as used herein refers to and encompasses any and all possible combinations of the associated listed items. It should also be understood that although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, since these terms are only used to distinguish one element from another, unless otherwise stated or the context dictates otherwise. As used herein, the term "comprising" means including but not limited to, and the term "comprises" means including but not limited to. The term "based on" means at least partially based on.

[0113] Although the present disclosure has been described with respect to a limited number of embodiments, those skilled in the art having the benefit of the present disclosure will appreciate the various modifications and variations therefrom. The appended claims are intended to cover all such modifications and variations.

Claims

1. A method comprising: receiving, by a server associated with a content delivery network, a first request specifying an application programming interface (API) call to a cloud service, wherein the first request includes data representing an authorization bearer token, a geographic service region identifier, and an API call group; as well as The server routes the API call to an instance of the cloud service, wherein the routing comprises: determining, by the server, a client identifier based on the authorization bearer token; identifying, by the server, a location of the instance based on the client identifier, the geographic region identifier, and the API call group identifier; and In response to the identification, the server sends a second request corresponding to the API call to the location.

2. The method of claim 1 , wherein identifying the location of the instance comprises: identifying, by the server, an entry in a table based on the client identifier, the geographic service area identifier, and the API call group identifier; as well as The entry is read to determine the location of the instance.

3. The method according to claim 2, further comprising: In response to a determination by the cloud-service manager to migrate a workload associated with the client identifier from the instance to a second instance of the cloud service, the entry is updated with data representing a location of the second instance.

4. The method of claim 1, wherein the data represents a uniform resource location (URL) and a header, and the header includes an authorization bearer token, the method further comprising determining the client identifier based on the authorization bearer token.

5. The method of claim 1, wherein the data represents a uniform resource location (URL), and the URL includes a subdomain name that includes the geographic service area identifier. 6 . The method of claim 1 , wherein the data represents a uniform resource location (URL), and the URL includes a path including the API call group identifier.

7. The method of claim 1 , wherein identifying the location of the instance comprises: identifying a record of a lookup table based on the client identifier, the geographic service area identifier, and the API call group identifier; as well as In response to the identification of the record of the lookup table, the location of the instance is read from the record.

8. The method according to claim 1, wherein: the location of the instance corresponds to a second server among a plurality of servers located in a geographic service area corresponding to the geographic service area identifier; as well as The plurality of servers hosts at least one other instance of the service. 9 . The method of claim 8 , wherein a third server of the plurality of servers other than the second server hosts an instance of the at least one other instance.

10. The method of claim 1, wherein the location of the instance is within a geographic service area corresponding to the geographic service area identifier, the method further comprising constraining the client identifier to a single instance of the service corresponding to the geographic service area.

11. A non-transitory storage medium storing machine-readable instructions that, when executed by a machine associated with a point of presence of a content delivery network, cause the machine to: Access API requests directed to services; processing the API request to determine a client identifier associated with the API request, a geographic region associated with the API request, and an API call group associated with the API request; accessing location information stored in a global data repository based on the client identifier, the geographic region, and the API call group, wherein the location information corresponds to an instance of the service; as well as The API request is routed to the instance based on the location information.

12. The storage medium of claim 11, wherein the instructions, when executed by the machine, further cause the machine to: Processing the API request to extract, from a uniform resource location URL of the API request, a subdomain of a domain name contained in the URL; and The geographic area is determined based on the sub-domain.

13. The storage medium of claim 11, wherein the instructions, when executed by the machine, further cause the machine to: Processing the API request to extract a resource path from a uniform resource location URL of the API request; and The API call group is determined based on the resource path.

14. The storage medium of claim 11, wherein the instructions, when executed by the machine, further cause the machine to: processing the API request to extract an authorization bearer token from a header of the API request; and The client identifier is determined based on the authorization bearer token.

15. The storage medium of claim 11, wherein the instructions, when executed by the machine, further cause the machine to: accessing a global routing table of the global data repository; identifying a record of the global routing table based on the client identifier, the geographic region identifier, and the API call group identifier; and Data representing the position information is read from the record.

16. An apparatus comprising: a hardware processor associated with a point of presence of a content delivery network; as well as a memory for storing machine-readable instructions that, when executed by the hardware processor, cause the hardware processor to: Receive API requests directed to the service; Based on a uniform resource location URL represented by the first data of the API request, determining a geographic region identifier from a subdomain of the URL, and determining an API call group identifier from a path of the URL; determining a client identifier based on an authorization bearer token represented by second data of the API request; determining a location corresponding to an instance of the service based on the geographic region identifier, the API call group identifier, and the client identifier; as well as The API request is forwarded to the location.

17. The apparatus of claim 16, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to: generating a second API request, wherein the second API request includes a URL identifying the location corresponding to the instance; and The API request is sent to the location.

18. The apparatus of claim 16, wherein the API request corresponds to a presentation layer state transfer REST API model.

19. The apparatus of claim 16, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to: identifying an entry in a table based on the client identifier, the geographic service area identifier, and the API call group identifier; and The entry is read to determine the position.

20. The apparatus of claim 19, wherein the instructions, when executed by the hardware processor, further cause the hardware processor to access a global data store to read the entry.

Images