Cloud to on-premises debug service routing

Described embodiments provide systems and methods for routing service requests. The system includes a first network of computing devices including a server hosting a service. The system includes a release router in the first network, the release router configured to receive a request for the service, the request forwarded to the release router responsive to resolving a hostname specified in the request using a DNS mapping the hostname to the release router, the hostname associated with the service hosted by the server. The release router is configured to identify a relay agent registered with the release router for debugging the service, the relay agent executed by a test platform in a second network, and to forward the request to the test platform in the second network, wherein the test platform resolves the hostname specified in the request using a local DNS mapping the hostname to a localhost address.

BACKGROUND

Network accessible computing systems, e.g., servers in a data center, provide various services over a network (e.g., the Internet). These systems are sometimes referred to as “cloud based” or “in the cloud” in reference to their off-premises location within the network (which is often depicted in figures as a cloud). Cloud-based services may be hosted on servers owned or managed by a third-party, e.g., under a tenancy or co-tenancy arrangement. The third-party providing the hardware (or time on shared hardware) may be referred to a cloud-services provider.

Cloud-based services may interact with each other. For example, a front-end (public-facing) interface server (such as a web host) may rely on a back-end database server or content host. These back-end services often reside in the same autonomous system (“AS”) network as the front end services, eliminating any security or infrastructure barriers. However, provisioning services on a third-party cloud infrastructure may require administrative configuration, additional costs from the cloud-services provider, and risk of disruption to an existing services deployment. These problems can make it prohibitive to test new services or new versions of services in the cloud.

However, testing new services or new versions of services on a local computing system (that is, one not in the cloud) may also be difficult. For example, if the service is part of a deployment interacting with other services, then the other services also need to interact with the test version. This could be achieved by recreating all of the other services on a test platform, although this (too) may be prohibitively complex and/or inadequate for testing production-realistic scenarios.

These and other technical problems are addressed by the subject matter described.

SUMMARY

In at least one aspect, described is a method for routing service requests. The method includes receiving, by a release router in a first network, a request for a service hosted by a server in the first network, the request forwarded to the release router responsive to resolving a uniform resource locator (“URL”) hostname specified in the request using a Domain Name System (“DNS”) mapping the URL hostname to the release router, the URL hostname associated with the service hosted by the server. The method includes identifying, by the release router, a relay agent registered with the release router for debugging the service, the relay agent executed by a test platform in a second network. The method includes forwarding, by the release router, the request to the test platform in the second network, wherein the test platform resolves the URL hostname specified in the request using a local DNS mapping the URL hostname to a localhost address.

In at least one aspect, described is a system for routing service requests. The system includes a first network of computing devices including a server hosting a service. The system includes a release router in the first network, the release router configured to receive a request for the service hosted by the server in the first network, the request forwarded to the release router responsive to resolving a uniform resource locator (“URL”) hostname specified in the request using a Domain Name System (“DNS”) mapping the URL hostname to the release router, the URL hostname associated with the service hosted by the server. The release router is configured to identify a relay agent registered with the release router for debugging the service, the relay agent executed by a test platform in a second network, and to forward the request to the test platform in the second network, wherein the test platform resolves the URL hostname specified in the request using a local DNS mapping the URL hostname to a localhost address.

DETAILED DESCRIPTION

The subject matter described covers topics that, among other things, enables a first service deployed in a network cloud to interact with another service running on a test platform, which may be on another network separate from the cloud autonomous system (“AS”). This can facilitate experimental service provisioning, enabling realistic testing and debugging. A service that is part of a multi-service deployment can be integrated into the deployment with minimal configuration, simplifying validation and pre-provisioning experimentation.

FIG. 1Adepicts an illustrative network environment100. The network environment100includes a production network104a, a developer network104b, and one or more other networks such as a transit network104c(the networks104a,104b, and104care referred to generally as networks104). Within the network environment100, client devices102communicate with servers134, and the servers134provide one or more network services to the client devices102. As shown inFIG. 1A, servers134are situated in the production network104a. The client devices102may communicate with the servers134directly through the production network104aor through some intermediary network, e.g., the transit network104c. Network communications between the client devices102and the servers134flow through network devices144such as switches, routers, hubs, filters, firewalls, gateways, and so forth. The production network104aincludes a gateway132that directs traffic from client devices102to the servers134. The host network104aalso includes a distributor136, which is a network device that acts as a redirection agent or proxy. The distributor136, can redirect traffic128from a client device102to another network104such as the developer network104b, e.g., via a transit network104c. One or more network devices144in the transit network104cpropagate the communication to a gateway device162in the other network104b, which may filter communications or otherwise control access to the network104b. As shown inFIG. 1A, the developer network104bmay include a local server164and/or a local workstation168. The local server164is shown with access to a data storage166, e.g., a local database system.

Suitable examples of client devices102include various processor-based devices that execute instructions for interactions with servers134via a network104. Some example client devices102receive input from a user and present output to the user. The client device102may be any kind of computing device, including, for example, a desktop computer, a laptop or notepad computer, a thin client, a mobile device such as a tablet or electronic “pad,” a smart phone or data phone, a gaming system, or any other device capable of the functions described herein. The client devices102are capable of exchanging information with other computing devices via the network104. For example, a client device102may exchange information over the network104using protocols in accordance with the Open Systems Interconnection (“OSI”) layers, e.g., using an OSI layer-4 transport protocol such as the User Datagram Protocol (“UDP”) or the Transmission Control Protocol (“TCP”), layered over an OSI layer-3 network protocol such as Internet Protocol (“IP”), e.g., IPv4 or IPv6. In some embodiments, the client device102supports network communication using Secure Socket Layer (“SSL”) or Transport Layer Security (“TLS”), which encrypts communications layered over a reliable transport protocol (such as TCP). In some embodiments, the client device102is a thin-client, or functions as a thin-client, executing a thin-client protocol or remote-display protocol such as the Independent Computing Architecture (“ICA”) protocol created by Citrix Systems, Inc. of Fort Lauderdale, Fla. The ICA protocol allows presentation at the client device102of software executing remotely (e.g., at a server134), as though the remotely executed software were executed locally on the client device102. In some embodiments, one or more of the servers134with which the client devices102communicate supports a custom instruction set, e.g., an application programming interface (“API”), and a custom application executed on the client device102implements the API. An application can implement an API using, for example, a library such as a dynamic link library (“DLL”) or a software development kit (“SDK”) provided to the application's developer.

In some embodiments, the client device102includes one or more hardware elements for facilitating data input and data presentation. In some embodiments, the client device102is implemented using special purpose logic circuitry, e.g., an application specific integrated circuit (“ASIC”). In some embodiments, the client device102is implemented using a system on a chip (“SoC”) semiconductor device that includes at least one processor (or microprocessor) core. In some embodiments, the client device102is implemented using a general purpose computing processor.FIG. 1B, described in more detail below, illustrates a computing device101that, in some configurations, is suitable for use as a client device102.

The networks104a,104b, and104c(referred to generally as a network104) link devices for communication. In some embodiments, data flows through the network104as a flow of data packets in accordance with the OSI layers, e.g., as a TCP or ICA flow. An illustrative network104is the Internet; however, other networks may be used. Each network104may be an autonomous system (“AS”), i.e., a network that is operated under a consistent unified routing policy (or at least appears to from outside the AS network) and is generally managed by a single administrative entity (e.g., a system operator, administrator, or administrative group). A network104may be composed of multiple connected sub-networks or AS networks. Networks meet at boundary nodes, e.g., network devices144such as gateway nodes or routers. A network104may include wired links, optical links, and/or radio links. A network104may include a telephony network, including, for example, a wireless telephony network implementing a wireless communication protocol such as the Global System for Mobile Communications (“GSM”), Code Division Multiple Access (“CDMA”), Time Division Synchronous Code Division Multiple Access (“TD-SCDMA”), Long-Term Evolution (“LTE”), or any other such protocol. The network104may be public, private, or a combination of public and private networks. Each network104may be any type and/or form of data network and/or communication network.

The network devices144are network nodes that forward network data (e.g., data packets) between other network nodes. Suitable examples of network devices144include switches, routers, hubs, multi-homed computing devices, or any other device used for network communications. A network device144may include two or more network interfaces (or physical “ports,” which should not be confused with transport protocol ports) and logic circuitry for identifying, for particular data, an egress interface connected to another device that will move the particular data towards a destination. In some embodiments, the network devices144direct traffic based on routing configuration data to forward data towards traffic destinations. In some embodiments, the network devices144forward data according to routing tables. In some embodiments, the network devices144forward data according to a configuration, e.g., a configuration set by a software defined network (“SDN”) controller. In some embodiments, a network device144includes a content-addressable memory (“CAM”) or ternary content-addressable memory (“TCAM”), used in identifying egress interfaces for routing data. In some embodiments, a network device144implements additional network functionality, or directs traffic through additional network nodes providing network functionality. For example, a network device144may pass traffic through a firewall, a network address translator (“NAT”), a network filter, or some other node providing network functionality.

One or more servers134may be logically grouped (e.g., as a server farm), and may either be geographically co-located (e.g., on premises) or geographically dispersed (e.g., cloud based) from client devices102and/or other servers134. In some embodiments, a server134or group of servers134executes one or more applications on behalf of one or more of client devices102(e.g., as an application server). In some embodiments, the servers134provide functionality such as, but not limited to, file server, gateway server, proxy server, or other similar server functions. In some embodiments, client devices102may seek access to hosted applications on servers134. In some embodiments, a network device such as the gateway132or specific servers134may provide load balancing across multiple servers134to process requests from client devices102, act as a proxy or access server to provide access to the one or more servers134, provide security and/or act as a firewall between a client102and a server134, provide Domain Name Service (“DNS”) resolution, provide one or more virtual servers or virtual internet protocol servers, and/or provide a secure virtual private network (“VPN”) connection from a client102to a server138, such as a secure socket layer (“SSL”) VPN connection and/or provide encryption and decryption operations.

In described embodiments, client devices102, servers134, and other devices shown inFIG. 1Amay be deployed as (or executed on) any type and form of computing device, such as any desktop computer, laptop computer, or mobile device capable of communication over at least one network and performing the operations described herein. For example, the client devices102, servers134, and other devices may each correspond to one computer, a plurality of computers, or a network of distributed computers such as the computing device101shown inFIG. 1B.

As shown inFIG. 1B, a computing device101may include one or more processors103, volatile memory122(e.g., RAM), non-volatile memory128, user interface (UI)123, one or more communications interfaces118(e.g., a network interface card (“NIC”)), and a communication bus150. The user interface123may include hardware for a graphical user interface (“GUI”)124(e.g., a touchscreen, a display, etc.), one or more input/output (“I/O”) devices126(e.g., a mouse, a keyboard, a speaker, etc.). Non-volatile memory128stores an operating system115, one or more applications116, and data117such that, for example, computer instructions of operating system115and/or applications116are executed by processor(s)103out of volatile memory122. Data117may be entered using an input device of GUI124or received from I/O device(s)126. Various elements of the computing device101may communicate via communication bus150. The computing device101as shown inFIG. 1Bis shown merely as an example, as client devices102, servers138, and other network devices may be implemented by any computing or processing environment and with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein.

The processor(s)103may be implemented by one or more programmable processors executing one or more computer programs to perform the functions of the system. As used herein, the term “processor” describes an electronic circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard coded into the electronic circuit or soft coded by way of instructions held in a memory device. A “processor” may perform the function, operation, or sequence of operations using digital values or using analog signals. In some embodiments, the “processor” can be embodied in one or more of an application specific integrated circuit (“ASIC”), microprocessor, digital signal processor, microcontroller, field programmable gate array (“FPGA”), programmable logic arrays (“PLA”), multi-core processor, or general-purpose computer processor with associated memory. The “processor” may be analog, digital, or mixed-signal. In some embodiments, the “processor” may be one or more physical processors or one or more “virtual” (e.g., remotely located or cloud-based) processors.

The communications interface118may include one or more interfaces to enable the computing device101to access a computer network104such as a LAN, a WAN, or the Internet through a variety of wired and/or wireless or cellular connections. In some embodiments, the communications interface118includes one or more network connection points (ports) and an interface controller. Network connection points may be wired connection points (e.g., Ethernet ports) or wireless (e.g., radio circuitry for Wi-Fi or mobile network communications).

The non-volatile memory128may include one or more of a hard disk drive (“HDD”), solid state drive (“SSD”) such as a Flash drive or other solid state storage media, or other magnetic, optical, circuit, or hybrid-type storage media. In some embodiments, the non-volatile memory128includes read-only memory (“ROM”). In some embodiments, storage may be virtualized, e.g., using one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes.

In described embodiments, a first computing device101(e.g., a server134) may execute an application on behalf of a user of a second computing device101(e.g., a client device102). For example, the first computing device may execute a virtual machine providing an execution session within which applications execute on behalf of a user of the second computing device. For example, the first computing device may provide a hosted desktop session, may execute a terminal services session to provide a hosted desktop environment, or may provide access to a computing environment including one or more of: one or more applications, one or more desktop applications, and one or more desktop sessions in which one or more applications may execute. For example, in some embodiments, the client device102is a thin-client, or functions as a thin-client, executing a thin-client protocol or remote-display protocol such as the Independent Computing Architecture (“ICA”) protocol created by Citrix Systems, Inc. of Fort Lauderdale, Fla.

FIG. 2is a block diagram200of cloud services230interacting with a test platform260. The cloud services230are hosted on computing systems101in a network104(e.g., the production network104ashown inFIG. 1A). The network104also provides a domain name system (“DNS”)148for network address resolution. DNS services may be provided by one or more DNS servers. The cloud services230include a first cloud service232that may interact with a production instance234of a second cloud service. The cloud services230include a release router236, which receives requests for a service (e.g., for the second service) and determines whether to route the request to the production instance234or to a debug instance268hosted on a test platform260. For example, described in more detail below,FIG. 3Ais a flowchart for an example method300by which a test platform260may receive service requests, andFIG. 3Bis a flowchart for an example method350by which a release router236may submit service requests to a test platform260. In some embodiments, the test platform260implements the method300illustrated inFIG. 3A. In some embodiments, the release router236implements the method350illustrated inFIG. 3B. In some embodiments, the release router236is hosted on a computing device101in the network104. In some embodiments, the release router236is a proxy for the server hosting the production instance234.

Still referring toFIG. 2, the illustrated network104(e.g., the autonomous system (“AS”) network of the cloud services230host) includes a service bus240. In some embodiments, the service bus240maintains a communication channel with the test platform260, e.g., initiated by a registration request from the test platform260. In some embodiments, the service bus240is a cloud service230hosted by the same provider. In some embodiments, the service bus240is in the same network104as the cloud services230. In some embodiments, the service bus240is in a separate network from the cloud services230.

The release router236, when forwarding a request to a debug instance268sends the request the service bus240for distribution to the test platform260. The test platform260includes a relay agent262interfacing with the service bus240, domain name resolution data264, and the debug instance268. For example, the test platform260may be a computing device101(such as the server164or developer workstation168described in reference toFIG. 1A) executing the relay agent262and the debug instance268. In some embodiments, requests may be specifically directed to a uniform resource locator (“URL”) indicating a debug request. For example, the URL may include a subdomain such as “debug” or “test.” The release router236, upon receiving a request directed to a debug-specific URL forwards the request to the service bus240. In some embodiments, the release router236may be configured to redirect production requests to the debug instance268. The debug instance268may handle a subset of production requests. In such instances, the release router236selects a subset of requests for forwarding to the debug instance268and forwards the rest to the production instance234.FIG. 4is a flowchart for an example method400by which the release router may determine whether to submit a service request to the test platform260. These and similar strategies allow a production service deployed in the cloud to interact with a test instance of a service running on a test platform, which may be on another network separate from the cloud autonomous system (“AS”).

FIG. 2illustrates a series of communications (shown as arrows) that are described in more detail in reference toFIG. 3A,FIG. 3B, andFIG. 4. Arrow272illustrates a communication from the relay agent262to the service bus240to register the debug instance268. Arrow280illustrates a request from the first cloud service232to a DNS148for forwarding to a second cloud service provided by the production instance234and the debug instance268. Network devices use the domain name system to resolve a network address for a network communication (e.g., requests) addressed to a uniform resource locator (“URL”). The URL includes domain information that maps to one or more specific network addresses. A first cloud service232may send requests to another cloud service (e.g., production instance234) using a URL instead of a specific network address. That is, by using DNS, a service can reach another service without needing to know the exact network address of the object service. This allows for deployment flexibility as the network address can be changed without requiring reconfiguration of other services. Arrow282illustrates resolution of the URL to a network address for the release router236. If the release router236determines to forward the request to the test platform260, then it forwards the request to the service bus240. Arrow284illustrates transmission of the request from the release router236to the service bus240. The service bus240then propagates the request to the test platform260, e.g., based on the earlier registration. Arrow286illustrates transmission of the request from the service bus240to the test platform260. The relay agent262acts as the main listener at the test platform260and attempts to resolve the URL. However, DNS resolution begins with local domain name resolution data264, which is configured at the test platform260to map the URL to the localhost. Accordingly, the test platform260passes the request to the debug instance268. Arrow290illustrates the localhost resolution causing the request to be passed to the debug instance268. From the perspective of the first cloud service232, the request280is processed by an instance of the second cloud service—only the request is processed by the debug instance268instead of the production instance234. If the release router236determines, instead, not to forward the request from the first cloud service232to the debug instance268, then it forwards the request to the production instance234. Arrow288illustrates transmission of the request from the release router236to the production instance234. These communications are described in more detail in reference toFIG. 3A,FIG. 3B, andFIG. 4.

FIG. 3Ais a flowchart for an example method300by which a test platform260may receive service requests. In broad overview of the method300, at stage310, a relay agent262for a test platform260registers a service debug instance268with a service bus240. At stage320, the relay agent262receives a request directed to a cloud service forwarded from the service bus240. At stage330, the relay agent262resolves the localhost as the network address for the cloud service. At stage340, the relay agent262forwards the request to the service debug instance268.

Referring toFIG. 3Ain more detail, at stage310, a relay agent262for a test platform260registers a service debug instance268with a service bus240. In some embodiments, the registration originates with the test platform260, the relay agent262, or the debug instance268of the service hosted by the test platform. The registration is illustrated inFIG. 2as arrow272. In some embodiments, the registration is a message from the test platform260to the service debug instance268identifying the service to be tested or debugged. In some embodiments, the registration includes authentication data, authorization data, and/or configuration data. For example, in some embodiments, the registration includes a network address for the test platform260, identification of the service to be tested, and an expiration or time-to-live value. In some embodiments, the registration request is transmitted by the test platform260to the service bus240, and the service bus240then registers the relay agent262with the release router236. For example, in some embodiments, the service bus240forwards the registration request to the release router236.

In some embodiments, the service debug instance268is registered with the service bus240separately, e.g., manually configured by an administrator. In some such embodiments, the test platform260completes the registration by sending a message from the relay agent262to the service bus240, e.g., piercing a network firewall. In some embodiments, registration includes adding the service domain to local domain name resolution data264mapping the service domain to localhost.

At stage320, the relay agent262receives a request directed to a cloud service forwarded from the service bus240. Receiving the request at stage320is illustrated inFIG. 2as arrow286. The received request is directed to a uniform resource locator (“URL”) that includes domain information corresponding to the service being tested. In some embodiments, the URL indicates a production service. In some embodiments, the URL specifically indicates a request directed to a debug or test instance. The service bus240forwards the request to the relay agent262based on the registration from stage310.

At stage330, the relay agent262resolves the localhost as the network address for the cloud service. The relay agent262uses local domain name resolution data264to identify a next-hop for the received request. However, the local domain name resolution data264is configured to map the URL of the received request to the localhost, or to a network address corresponding to the host of the service debug instance268. In the Internet Protocol version 4 (“IPv4”), localhost is usually 127.0.0.1, although it may be any loopback address such as addresses in the range 127.0.0.0/8. In the Internet Protocol version 6 (“IPv6”), localhost is::1.

At stage340, the relay agent262forwards the request to the service debug instance268. Passing the request to the debug instance268is illustrated inFIG. 2as arrow290. In some embodiments, the relay agent262transmits the request to the resolved localhost address. In some embodiments, the relay agent262passes the request to the service debug instance268internally. The service debug instance268may then process the request.

In some embodiments, the service debug instance268is identical to the production instance234. In some embodiments, the service debug instance268is an instrumented version of the production instance234. For example, it may be configured to generate additional reports or outputs for monitoring purposes. In some embodiments, the service debug instance268is a new or revised version of the production instance234. It may be run as a debugging instance to verify functionality prior to deployment in the production environment.

FIG. 3Bis a flowchart for an example method350by which a release router236may submit service requests to a test platform260. In broad overview of the method350, at stage360, the release router236receives a request for a service. At stage370, the release router236identifies a relay agent registered for debugging the service and, at stage380, forwards the request to a test platform260.

Referring toFIG. 3Bin more detail, at stage360, the release router236receives a request for a service. Receiving the request at stage360is illustrated inFIG. 2as arrow282. The request received by the release router236may be a request for a service hosted by a server in the same network104as the release router236, e.g., the service production instance234. In some embodiments, the request is addressed to a uniform resource locator (“URL”) generally identifying the service. In some embodiments, the request is addressed to a URL specifically indicating that it is a test or debug request. For example, the URL main include a specific subdomain such as “test” or “debug.” In some embodiments, the release router236receives the request based on a DNS148configuration mapping the domain (or subdomain) to the release router236. In some embodiments, the request originates with another service in the same network104, e.g., the cloud service232. In some embodiments, the request originates from another system, e.g., an external computer such as a client device102in another network.

At stage370, the release router236identifies a relay agent registered for debugging the service. In some embodiments, the release router236implements the method400illustrated inFIG. 4. In some embodiments, the release router236consults a set of routing rules. In some embodiments, the release router236identifies the relay agent262registered with the service bus240for debugging the service. In some embodiments, the release router236identifies the relay agent262registered with the release router236for debugging the service. For example, as described above in reference toFIG. 3A, in some embodiments, when the relay agent262registers with the service bus240, the service bus240then propagates the registration to the release router236.

At stage380, the release router236forwards the request to the test platform260. In some embodiments, the release router236forwards the request to the test platform260via the service bus240. Forwarding the request to the service bus240is illustrated inFIG. 2as arrow284. The service bus240then forwards the request to the relay agent262at the test platform260. Forwarding the request to the test platform260is illustrated inFIG. 2as arrow286.

FIG. 4is a flowchart for an example method400by which the release router may determine whether to submit a service request to the test platform260. In broad overview of the method400, at stage460, a release router236receives a request for a service. At stage470, the release router236consults routing rules for the service and determines, as stage475, whether to transfer the request to a testing platform260. If not, then at stage480, the release router236forwards the request to a production instance234of the service. However, if at stage475, the release router236determines to transfer the request to the testing platform260, then at stage490, the release router236forward the request to a debug instance268hosted by the testing platform260. In some embodiments, the release router236forwards the request to the debug instance268at stage490via the service bus240.

Referring toFIG. 4in more detail, at stage460, a release router236receives a request for a service. In some embodiments, stage460is equivalent to stage360of the method350described in reference toFIG. 3B. In some embodiments, the request received at stage460includes one or more characteristics that may be used by the release router236for determining whether to use the request for testing. For example, the request may explicitly be designated for testing (e.g., it may be specifically addressed to a test or debug domain). In some embodiments, the release router460selects a random subset of requests to a service for redirection to a test instance of the service as “canary” requests.

At stage470, the release router236consults routing rules for the service and determines, as stage475, whether to transfer the request to a testing platform260. In some embodiments, the routing rules are a set of parameters. In some embodiments, the routing rules are a list of domain names designated for test or debug purposes. In some embodiments, the routing rules may be easily modifiable, e.g., from a remote developer workstation. In some embodiments, the routing rules may be statistics driven, e.g., requiring a set percentage of requests to be redirected. In some embodiments, the routing rules may include a set of conditions that, if satisfied by the request, indicate that the request should be forwarded to the debug instance268. In some embodiments, the set of routing rules are maintained based on a registration for one of: the test platform260, the relay agent262, or a test instance268of the service hosted by the test platform260. The release router236checks the set of routing rules for debug service requests, and identifies the test platform260or the relay agent262based on the set of routing rules.

At stage480, if the release router236determines at stage475not to transfer the request to the testing platform260, then the release router236forwards the request to a production instance234of the service. In some embodiments, the release router236forwards the request using an application programming interface (“API”) for the production instance234of the service. In some embodiments, the release router236forwards the request via the network104.

At stage490, if the release router236determines at stage475to transfer the request to the testing platform260, then the release router236forwards the request to a debug instance268hosted by the testing platform260. In some embodiments, the release router236forwards the request to the debug instance268at stage490via the service bus240. The forwarded request may retain the same URL as the original request.

The systems and methods described may be used in a variety of embodiments. For example, and without limitation:

In at least one aspect, the above describes a method for routing service requests. The method includes receiving, by a release router in a first network, a request for a service hosted by a server in the first network, the request forwarded to the release router responsive to resolving a uniform resource locator (“URL”) hostname specified in the request using a Domain Name System (“DNS”) mapping the URL hostname to the release router, the URL hostname associated with the service hosted by the server. The method includes identifying, by the release router, a relay agent registered with the release router for debugging the service, the relay agent executed by a test platform in a second network. The method includes forwarding, by the release router, the request to the test platform in the second network, wherein the test platform resolves the URL hostname specified in the request using a local DNS mapping the URL hostname to a localhost address.

In some embodiments of the method, the test platform is a computing device hosting a test instance of the service and configured for debugging the service. In some embodiments of the method, the release router is a proxy for the server and hosted on a computing device in the first network.

Some embodiments of the method include checking, by the release router, a set of routing rules for debug service requests and identifying the relay agent based on the set of routing rules. Some embodiments of the method include updating the set of routing rules based on a registration for one of: the test platform, the relay agent, or a test instance of the service hosted by the test platform.

Some embodiments of the method include forwarding the request to the test platform in the second network, by the release router, via a service bus external to the second network, wherein the relay agent is registered with the service bus to receive the request. Some embodiments of the method include configuring the service bus to forward, to the second network, requests directed to resource identifiers specifying a name for the service, wherein the URL of the received request specifies the name for the service. In some embodiments, the service bus is situated in the first network.

Some embodiments of the method include receiving, by the release router in the first network, a second request for the service hosted by the server in the first network, checking a set of routing rules, and forwarding the second request to the server in the first network responsive to the set of rules.

In at least one aspect, these methods may be encoded as computer-readable instructions for execution by one or more processors. The computer-readable instructions can be encoded on non-transitory computer-readable media.

In at least one aspect, the above describes a system for routing service requests. The system includes a first network of computing devices including a server hosting a service. The system includes a release router in the first network, the release router configured to receive a request for the service hosted by the server in the first network, the request forwarded to the release router responsive to resolving a uniform resource locator (“URL”) hostname specified in the request using a Domain Name System (“DNS”) mapping the URL hostname to the release router, the URL hostname associated with the service hosted by the server. The release router is configured to identify a relay agent registered with the release router for debugging the service, the relay agent executed by a test platform in a second network, and to forward the request to the test platform in the second network, wherein the test platform resolves the URL hostname specified in the request using a local DNS mapping the URL hostname to a localhost address.

In some embodiments of the system, the test platform is a computing device hosting a test instance of the service and configured for debugging the service. In some embodiments of the method, the release router is a proxy for the server and hosted on a computing device in the first network. In some embodiments of the system, the release router includes a processor coupled to memory and configured to execute instructions stored in the memory.

In some embodiments of the system, the release router is configured to check a set of routing rules for debug service requests and to identify the relay agent based on the set of routing rules. In some embodiments of the system, the release router is configured to update the set of routing rules based on a registration for one of: the test platform, the relay agent, or a test instance of the service hosted by the test platform.

In some embodiments of the system, the release router is configured to forward the request to the test platform in the second network via a service bus external to the second network, wherein the relay agent is registered with the service bus to receive the request. In some embodiments, the service bus is configured to forward, to the second network, requests directed to resource identifiers specifying a name for the service, wherein the URL of the received request specifies the name for the service. In some embodiments, the service bus is situated in the first network.

In some embodiments of the system, the release router is configured to receive, in the first network, a second request for the service hosted by the server in the first network, check a set of routing rules, and forward the second request to the server in the first network responsive to the set of rules.

It will be further understood that various changes in the details, materials, and arrangements of the parts that have been described and illustrated herein may be made by those skilled in the art without departing from the scope of the following claims.