Hot swapping and hot scaling containers

Techniques for hot swapping and hot scaling containers between cloud services are disclosed. In one example, a method includes storing, with a cloud exchange, data indicating an association of a first container of a first private network with a second container of a second private network, wherein the first private network and the second private network are coupled to the cloud exchange to send and receive data packets via the cloud exchange. The method further includes sending, with the cloud exchange based on the association, state of the first container to the second container.

TECHNICAL FIELD

The disclosure relates to computer networks and, more specifically, to cloud services.

BACKGROUND

Cloud computing refers to the use of dynamically scalable computing resources accessible via a network, such as the Internet. The computing resources, often referred to as a “cloud,” provide one or more services to users. These services may be categorized according to service types, which may include for examples, applications/software, platforms, infrastructure, virtualization, and servers and data storage. The names of service types are often prepended to the phrase “as-a-Service” such that the delivery of applications/software and infrastructure, as examples, may be referred to as Software-as-a-Service (SaaS) and Infrastructure-as-a-Service (IaaS), respectively.

The term “cloud-based services” or, more simply, “cloud services,” refers not only to services provided by a cloud, but also to a form of service provisioning in which cloud service customers contract with cloud service providers for the online delivery of services provided by the cloud. Cloud service providers (“CSPs”) manage a public, private, or hybrid cloud to facilitate the online delivery of cloud services to one or more cloud service customers.

A cloud exchange may allow private networks of a customer of the cloud exchange to be interconnected to any other customer of the cloud exchange at a common point, thereby allowing direct exchange of network traffic between the networks of the customers. Customers may include network carriers (or network service providers), enterprises, and other users of cloud services offered by one or more CSPs. One example use of a cloud exchange is to interface a group of customers to a group of CSPs. Each CSP may provide customer access to a “cloud” computing network, wherein the customer stores, manages, and processes data on a network of remote servers rather than on a local server or personal computer of the customer.

SUMMARY

In general, this disclosure describes techniques for facilitating inter-container communications via a cloud exchange to perform hot swaps and hot scaling of containers, including applications or other resources executing in the containers, to additional containers that may execute on the same or different cloud service networks. The hot swaps may involve copying all code, data, and other state for applications, runtime, and other resources from one container to another, by a cloud exchange, while the container is executing. The cloud exchange may thereby swap (or copy or transfer) the first container to a second container, while the first container is hot, or in the midst of execution, without interrupting or interfering with the execution of the first container and its applications and/or other resources.

The hot scaling may involve the cloud exchange copying portions of code, data, and other state for applications, runtime, and other resources from one container to a number of containers, by a cloud exchange, while the container is executing. The hot scaling may involve the cloud exchange orchestrating and cloning events being executed by the container without impacting applications being executed by the container. This may involve the cloud exchange briefly placing a hold on application transactions during a copy or transfer of code, data, or other state from the first container to the second container, before quickly resuming execution of the events by the containerized applications in the new container. The cloud exchange may thereby scale, or expand, the first container to a number of additional containers, while the first container is hot, or in the midst of execution, also without interrupting or interfering with the execution of the first container and its applications and/or other resources.

For example, a cloud exchange may provide connectivity between an enterprise network that executes one or more applications (e.g., micro-services) using containers, and one or more cloud service provider networks that also execute one or more applications using containers. By causing the containers to register and communicate with the cloud exchange, and to communicate data from one or more first containers to one or more second containers via the cloud exchange-provisioned connectivity, various techniques of this disclosure may enable hot swaps and hot scaling of containerized applications and other resources for the enterprise, elastically and automatically across a wealth of container provisioning resources, including across containers executing at networks or cloud services with different underlying technology infrastructures.

The techniques of this disclosure may provide various advantages. For instance, a cloud exchange provider may leverage the techniques of this disclosure to provide, via a cloud exchange, a hot swap and hot scaling service to an enterprise customer. The enterprise customer may purchase cloud-based resources from a cloud service provider (“CSP”) for executing container-based applications deployed to the CSP by the enterprise. The cloud exchange may provision connectivity between containers executing at one or more CSPs, and potentially containers executing at the enterprise's network, and may enable automatic hot swapping and hot scaling of the containers across a potentially large and potentially heterogeneous array of container provisioning resources. A cloud exchange configured to perform hot container swap and hot container scaling techniques of this disclosure may thus expand the scope and flexibility of container resources available to a cloud service customer without imposing container management burden on the enterprise customer.

The hot container swap and hot container scaling techniques of this disclosure may also contribute to additional services and functions performed by a cloud exchange, such as automatic backup, disaster recovery, and expanding scale to handle sudden increases in application demand. For example, in the event of a failure of a first container or other triggering event, the cloud exchange may hot swap the first container for a second container, potentially from a first container at the enterprise network to a second container at a CSP or from a first container at a first CSP to a second container at a second CSP, and redirect application loads for the first container to the second container. As another example, in the event of an overload of a first container or other triggering event, the cloud exchange may hot scale the first container across one or more additional containers, and direct some of the application loads for the first container across the one or more additional containers. In ways such as these, the cloud exchange facilitates seamless application replication and backup services to the cloud. In addition, in some examples, the techniques may permit an enterprise that uses cloud services to avoid an application outage during scheduled or unscheduled downtime of a cloud service provider.

In one example, this disclosure describes a method comprising: storing, with at least one processor of a cloud exchange, data indicating an association of a first container of a first private network with a second container of a second private network, wherein the first private network and the second private network are coupled to the cloud exchange to send and receive data packets via the cloud exchange; and sending, with the at least one processor of the cloud exchange, based on the association, state of the first container to the second container.

In another example, this disclosure describes a computing system comprising at least one memory device and at least one processor comprised in a cloud exchange, operably coupled to the at least one memory device, and configured to execute instructions to: store data indicating an association of a first container of a first private network with a second container of a second private network, wherein the first private network and the second private network are coupled to the cloud exchange to send and receive data packets via the cloud exchange; and send, based on the association, state of the first container to the second container.

In another example, this disclosure describes a computer-readable storage medium comprising instructions for causing at least one programmable processor of a cloud exchange to: store data indicating an association of a first container of a first private network with a second container of a second private network, wherein the first private network and the second private network are coupled to the cloud exchange to send and receive data packets via the cloud exchange; send, based on the association, state of the first container to the second container; receive, by the cloud exchange, cloud service traffic from an enterprise network; and redirect, by the cloud exchange, the cloud service traffic from the first container to the second container.

DETAILED DESCRIPTION

In general, the disclosure describes techniques for inter-container communications between containers (e.g., Docker containers, LXC containers, CoreOS Rocket containers) for enabling hot swaps and hot scaling of containers, via a cloud exchange, for containers executing at logically isolated networks. For example, techniques are described for transferring the state of a first container, including executable code and data involved in the applications and runtime executing on the first container, to a second container, while the applications of the first container are executing, such that the applications continue executing at the second container. Such transferring of the state of the first container may involve swapping the containerized code and data to a different container, or involve scaling at least some of the containerized code and data to additional containers to elastically increase the processing capability devoted to the containerized applications. The hot swap or hot scaling of the containerized applications may be to different containers located within the same subnet of the same cloud service, to different containers in different subnets of the same cloud service, or to an entirely different cloud service, in different implementations. In cases of hot swaps or hot scaling across different cloud services, which may have different cloud service infrastructure and which may be private or public cloud services, techniques of this disclosure may internally manage all aspects of translating code, data, and state for applications, runtime, and other resources between different cloud infrastructure technology stacks. Techniques of this disclosure may thus ensure that the containerized applications are swapped or scaled across the different cloud services smoothly and with all technology infrastructure differences automatically managed and made compatible by the cloud exchange, as if the potentially heterogeneous underlying cloud services were a uniform container provisioning resource, while also providing transparency into the hot swapping or hot scaling processes to the customers or other users.

FIG. 1is a block diagram illustrating an example system in accordance with example techniques of this disclosure. A cloud exchange may facilitate virtual connections for cloud services delivery with hot swap and hot scaling capability from multiple cloud service providers to one or more cloud service customers. The cloud exchange may enable cloud customers to bypass the public Internet to directly connect to cloud service providers (“CSPs”) so as to improve performance, reduce costs, increase the security and privacy of the connections, and leverage cloud computing for additional applications. In this way, enterprises, network carriers, and SaaS customers, for instance, can integrate cloud services with their internal applications as if such services were part of or otherwise directly coupled to their own data center network. The cloud exchange includes an orchestration engine that performs hot swaps and hot scaling of containers and applications executing in the containers.

Cloud exchange102may interface cloud service customers such as enterprise116to a plurality of cloud services124A-124B (collectively, “cloud services124”) provided by CSP networks122A-122B (hereinafter, “CSPs122”), in a cloud environment100. As one example of a cloud exchange, an Equinix Cloud Exchange (ECX) provided by Equinix, Inc. may interface a plurality of cloud service customers (e.g., enterprises, organizations, and individuals) to a plurality of CSPs (e.g., such as Microsoft Azure and Amazon Webservices). Cloud exchange102may provide one or more interconnections for cloud services delivery from the multiple CSPs122to enterprise116, as well as interconnections between the multiple CSPs122. An interconnection may represent a physical cross-connect or a virtual circuit in various examples. Additional details of interconnecting networks via a cloud exchange are found in U.S. Provisional Application No. 62/072,976, U.S. patent application Ser. No. 14/927,306, and U.S. patent application Ser. No. 15/099,407, the contents of each of which are hereby incorporated in their entirety by reference herein.

A CSP may provide a virtual machine hypervisor (VM) to a cloud service customer for access to the cloud network. A VM emulates virtual hardware. In other words, each VM provides a virtualized operating system and application suite for customer access. Because the VM is virtualized, the cloud service customer and its applications are isolated from both the hardware of the host and the VMs of other customers. This allows the CSP to provide cloud services that are safe and secure to the cloud service customer. The CSP may implement dozens or hundreds, for example, of VMs on a single network for access by a group of customers. However, because each VM virtualizes a complete operating system, it may consume a significant level of network resources.

A more efficient alternative to a virtual machine in many applications is a virtualized container, such as provided by the open-source Docker container application. Like a VM, each container is virtualized and may remain isolated from a host machine and other containers. However, unlike a VM, each container may omit a full individual operating system, and instead provide only an operating system kernel interface, an application suite, and application-specific libraries. Each container may be executed by the host machine as an isolated user-space instance, and may share an operating system and common libraries with other containers executing on the host machine. Thus, a cloud network using containers may require significantly less processing power, storage, and network resources than a cloud network implementing VMs.

Enterprise116deploys an enterprise network118, such as an enterprise on-premises data center or private cloud, to execute containers125A,125B, which provide an operating environment for applications deployed by enterprise116. In some cases, applications executed by containers125A,125B may be microservices. In general, microservices each implement a set of focused and distinct features or functions, and a microservice conforms to (or is usable in) an architectural pattern in which many dozens or hundreds of microservices can be independently developed and deployed. Microservices may be organized around a business capability and may implement a “broad-stack” of software for the business capability, including persistent storage and any external collaboration. The various microservices expose interfaces that enable the microservices to invoke one another to exchange data and perform the respective sets of functions in order to create one or more overall applications. Each of the microservices may adhere to a well-defined Application Programming Interface (API) and may be orchestrated by invoking the API of the microservice. Each of the microservices executes independently and exposes an interface for asynchronous invocation with respect to the other microservices.

Via cloud exchange102, CSPs122A-122B may make available cloud services124A-124B, respectively, to cloud service customers such as enterprise116, and thereby provide execution environments for applications of enterprise116. Orchestration engine106may provision a virtual circuit127A between enterprise116and cloud service124A, as further described below. In the illustrated example, each cloud service124may host or include a plurality of containers126that each provides an execution environment for at least one application (e.g., microservice) deployed by enterprise116. For example, cloud service124A may comprise containers126A,126B, and126C, and cloud service124B may comprise containers126D,126E, and126F. While a few representative containers are depicted inFIG. 1, each cloud service124A,124B may include up to a very large number of containers.

Further, a cloud service may group a plurality of containers into network subnets for organizational and network addressing purposes. In the example ofFIG. 1, cloud service124A may group containers126A and126B into subnet128A, while cloud service124B may group containers126D and126E into subnet128B. Containers126A and126B of subnet128A may execute on the same or on different hosts, the one or more hosts being addressable by a network address that is a member of subnet128A. In one example, a cloud service may group a plurality of containers into a plurality of subnets to organize services into different subnets. In another example, a cloud service may group a plurality of containers into a plurality of subnets to divide containers among customers of the cloud service.

Cloud exchange102includes an interconnection platform103that may expose a collection of software interfaces, also referred to and described herein as application programming interfaces (APIs)105, which may allow access to capabilities and assets of the interconnection platform in a programmable fashion. The APIs105may provide an extensible framework that allows software developers associated with customers and partners of cloud exchange102to build software applications that access interconnection platform103that automatically manages interconnection with multiple cloud service providers122participating in interconnection platform103, to provide interconnection and other services described herein to customers of the provider of cloud exchange102. Developers from network services providers, cloud service providers, managed service providers, and other enterprises may use the software interfaces exposed by interconnection platform103and defined by APIs105to build custom applications and frameworks for seamless interaction with interconnection platform103, to facilitate the delivery of cloud services from cloud service providers122to cloud service customers.

These software interfaces defined by APIs105enable machine-to-machine communication for near real-time setup and modifications of interconnections, and facilitate inter-container communications and container control as described herein. The software interfaces defined by APIs105may also eliminate or reduce the need for human interaction for the interconnection setup and management process. In this way, the software interfaces provide an automated and seamless way to use and manage containers executing at multiple different cloud services or networks connected to cloud exchange102.

Enterprise116may interface a plurality of enterprise workstations120A-120B (collectively, “enterprise workstations120”) of enterprise116to networks outside of enterprise116. Enterprise116may interface enterprise workstations120to websites connected to the Internet114, for example, website portal112, which may provide enterprise workstations120with access to the website of one of CSPs122. Further, enterprise116may interface enterprise workstations120to cloud exchange102. As used herein, actions imputed to enterprise116, cloud exchange102, or CSPs122may refer to a human operator or automated agent directed by the enterprise116, cloud exchange102, or CSP122.

Enterprise workstations120may access customer portal104to log into cloud exchange102. Customer portal104may represent a web-based application exposed to customers via a website and accessible using a browser. Customers may use customer portal104to sign up for or register cloud services. After a customer has registered with cloud exchange102via customer portal104, the customer may receive a service license identifier (e.g., a registration key). The service license identifier may identify the customer, the type of customer (e.g., business or individual), the services the customer has access to (e.g., public cloud services provided by, e.g., Microsoft Azure or Amazon Web Services), and service parameters such as an amount of service purchased in terms of, e.g., cloud service provider resources (e.g., bandwidth, processing units). Enterprise116may receive service license identifiers from the cloud service providers and register the service license identifiers with cloud exchange102using customer portal104.

In some examples, interconnection platform103may conform to a microservice-based application architecture. In the example ofFIG. 1, interconnection platform103includes an internal orchestration engine106that organizes, directs and integrates underlying microservices, as well as other software and network sub-systems, for managing various services provided by the cloud exchange102. Internal orchestration engine106includes container hot swap manager140, as further described below.

Orchestration engine106of the interconnection platform103for cloud exchange102may facilitate the dynamic creation of private connections between enterprise116and any of CSPs122, as well as between CSPs122, cloud service customers, network service providers, a cloud exchange administrator, or other customers of the cloud exchange. Orchestration engine106may receive registration information and service license identifiers from Customer Portal104obtained from users at registration. The orchestration framework may use this information to coordinate interactions between a heterogeneous set of unrelated APIs, microservices, Web services, sockets, remote method invocations (RMIs), and the like, that are orchestrated through a workflow, to seamlessly create a private connection (e.g., a virtual circuit) between the enterprise and the multiple cloud service providers. Orchestration engine106may be responsible for handling the entire request, which may be received from various channels such as a web portal and an API. Specific techniques for the design and implementation of an orchestration engine are described in U.S. Provisional Application No. 62/072,976 and U.S. patent application Ser. No. 14/927,306, the entire contents of both of which are incorporated by reference herein.

Networking platform108may comprise a plurality of routers and switches110A-110N (collectively, “routers110”), where “N” represents a number of routers and switches. Networking platform108may use routers110to transfer data between and among enterprise116and cloud services124A-124B. Orchestration engine106may administer the operations of networking platform108to facilitate the dynamic creation of private connections between enterprise116and cloud services124A-124B. In the example ofFIG. 1, orchestration engine106may provision a virtual circuit127A in the form of a virtual local area network (VLAN)-based and/or IP-VPN-based connection, for instance, between enterprise116and networking platform108to allow for data transfer between enterprise116and CSP122A. Thus, in accordance with example techniques of this disclosure, orchestration engine106may act to facilitate secure, fast, and efficient connections among enterprise116and cloud service provider122networks.

In accordance with example techniques of this disclosure, cloud exchange102may facilitate communications between two containers executing at different networks connected to cloud exchange102. For example, cloud exchange102may facilitate communications between container125A executing at enterprise116and container126A executing at a network of CSP122A providing cloud service124A. Cloud exchange102may also facilitate inter-container communications between containers of two different cloud services, e.g., containers126executing at a network of CSP122A providing cloud service124A and containers126executing at a network of CSP122B providing cloud service124B, including inter-container communications for hot swaps and hot scaling, as described further below. Facilitating communication between different cloud services may include orchestration engine106provisioning a virtual circuit127B to interconnect the respective networks of CSPs122A and122B, as described further below with reference toFIG. 2.

FIG. 2is a block diagram illustrating an example system in accordance with example techniques of this disclosure. As inFIG. 1, cloud exchange102may facilitate virtual connections for cloud services delivery with hot swap and hot scaling capability from multiple cloud service providers to one or more cloud service customers. Cloud exchange102includes orchestration engine106that performs hot swaps and hot scaling of containers and applications executing in the containers, particularly between containers of different CSPs, e.g., CSPs122A,122B. Orchestration engine106may enable cloud exchange102to operate connections, e.g., VLANs129A,129B, with CSPs122A,122B. Orchestration engine106may thereby implement a high-bandwidth virtual circuit127B between CSPs122A,122B. Orchestration engine106may use virtual circuit127B to facilitate hot swaps and hot scalings between the containers of CSPs122A and122B.

To implement communication between the containers of CSPs122A and122B, cloud exchange102may receive, from the respective CSP122, for each container, a container identifier for identifying the container, and a network address for identifying a host executing the container. In one example, container126A in CSP122A may generate a data communication to be directed by cloud exchange102to container126D in CSP122B, such that the data communication has a particular container identifier and is executed by a particular host within cloud service124B. This data communication may be forwarded as Layer 2 and/or Layer 3 (L2/L3) traffic by cloud service124A to routers110of networking platform108. Orchestration engine106may coordinate the operations of networking platform108such that routers110may forward the data communication to cloud service124B, such that the data communication is directed to the host executing container126D within cloud service124B. In some examples, the cloud exchange102may switch traffic from container126A in CSP122A to container126E in CSP122B by changing the mapping between a cloud exchange address and container host addresses in the different CSPs122A,122B.

Containers126of the various CSPs124may register, via APIs105, with orchestration engine106to provide respective container registration data including, e.g., host network address data and container identification data. The container registration data for a selected container, including a host network address for the container and a container identifier for the container, may also be referred to as a registration handle. Using the container registration data, orchestration engine106may facilitate inter-container communications and hot swap/hot scaling capability between containers126of the different CSPs124, as well as potentially other functions such as a backup service, a disaster recovery service, and/or other services.

For example, orchestration engine106may send a container registration handle obtained from container126A in CSP122A to container126E in CSP122B. Orchestration engine106, in conjunction with container126A deployed to cloud service124A, in this way extends network connectivity over the virtual circuit127B from container126A in CSP122A to container126E in CSP122B and may enable CSP122A to use the container registration handle of container126A to directly address and send data to container126E of CSP122B via virtual circuit127B. Likewise, orchestration engine106may, using the container registration handle of container126A, enable directly addressing and sending data from container126A in CSP122A to container126E in CSP122B via virtual circuit127B. In some examples in a hot swap or hot scaling process, orchestration engine106may indicate a URI of the second container126E in association with the first container126A, to implement redirecting all application traffic, data, or other interactions (in a hot swap) or at least some application traffic, data, or other interactions (in a hot scaling) addressed to the first container126A to the second container126E.

Using such extended network connectivity, cloud exchange102may in some instances facilitate hot swap and hot scaling functions for applications executed using containers126in CSPs122A,122B. For example, hot swap manager140of orchestration engine106may associate a first container126A of cloud service124A with a second container126E of a different cloud service124B, and cause first container126A to communicate all or part of its application code, data, and state to second container126E in the second CSP122B for purposes of a hot swap or hot scaling. Hot swap manager140of orchestration engine106may associate or register the container registration handle for the second container126E in the second CSP122B with the first container126A in the first CSP122A via cloud exchange102, such that interactions addressed to first container126A in CSP122A may be communicated to second container126E in CSP122B. In some examples, hot swap manager140may first identify a need, potential benefit, or fulfillment of a criterion for performing a hot swap or hot scaling of container126A in first CSP122A, and may then direct the creation of one or more new containers (potentially including second container126E) in the different CSP122B, before proceeding with a hot swap or hot scaling of container126A to the new one or more containers in the second CSP122B. Cloud exchange106may retrieve and temporarily store some or all of the code, data, and other state from container126A in first CSP122A, and deliver the code, data, and other state from container126A to the new one or more containers (e.g., container126E) in the second CSP122B once the new one or more containers in the second CSP122B are “spun up” or initiated and ready to commence functioning.

Hot swap manager140of orchestration engine106may thus swap the applications, runtime data, and other state from first container126A in first CSP122A to second container126E in second CSP122B, or scale the applications, runtime data, and other state from first container126A in first CSP122A across both first container126A and container126E in second CSP122B, and potentially additional containers (e.g., containers126D,126F) in second CSP122B. Hot swap manager140of orchestration engine106may thus swap or scale the applications, runtime data, and other state from first container126A in first CSP122A to one or more containers126in second CSP122B while the applications continue running without interruption, and with necessary functions of the swapping or scaling performed by container hot swap manager140of orchestration engine106. Orchestration engine106may thus hot swap and/or hot scale containerized applications across different CSPs to potentially reduce management of the swapping and/or scaling by the customer.

In some instances, a customer or other user, such as enterprise116or an agent thereof, may establish hot swap and hot scaling configuration settings or scheduling via customer portal104. Hot swap manager140of orchestration engine106may then perform hot swaps or hot scaling in accordance with the customer-selected configuration settings or schedule, e.g., selected via customer portal104. In some examples, orchestration engine106may detect that container126A at CSP122A has failed (e.g., due to a time-out or a software bug), and either customer-selected configuration settings or default settings may indicate for failed containers in a first CSP to be hot swapped to new containers in a second CSP. Some configuration settings or default settings may further include criteria for evaluating multiple container failures in one CSP, and criteria such that detecting signs of multiple failures in a first CSP triggers a hot swap or hot scaling from containers in the first CSP to containers in a different CSP. In these examples, hot swap manager140of orchestration engine106may then hot swap the failed container125A or multiple failed containers in the first CSP to one or more new containers126D-F at a second CSP122B in accordance with the customer-selected configuration settings or the default settings.

In some examples, hot swap manager140may first direct the creation of one or more new containers126D-F in a second CSP122B to be able to hot swap one or more containers126A-C in the first CSP122A to the one or more new containers126D-F in second CSP122B. Orchestration engine106may then redirect application traffic from containers of first CSP122A to corresponding hot swap or hot scaled containers in second CSP122B, e.g., from container126A in CSP122A to container126E in CSP122B. For example, an API gateway that receives application requests for CSP122A may be configured by orchestration engine106to redirect application traffic from container126A to container126E in CSP122B, across virtual circuit127B, in response to orchestration engine106determining that container126A in CSP122A has failed, or has become overloaded, or has met some other configured criterion indicating that container126A would benefit from being hot swapped or hot scaled to a new container.

In other examples, orchestration engine106may detect that container126A at CSP122A is being overloaded by increased levels of application traffic, and either customer-selected configuration settings or default settings may indicate for overloaded containers in a first CSP to be hot scaled to new containers in a second CSP. In these examples, hot swap manager140of orchestration engine106may then direct orchestration engine106to hot scale the overloaded container126A of CSP122A to one or more additional containers in a different CSP122B, such as new container126E, in accordance with the customer-selected configuration settings or the default settings. In some examples, hot swap manager140may first direct the creation of one or more new containers at the second CSP122B including container126E to be able to hot scale container126A in CSP122A to the new containers in CSP122B. Orchestration engine106may then redirect at least some application traffic from container126A to the one or more new containers in CSP122B including container126E.

In some cases, hot swap manager140may copy and persist a state of container126A to a container hot swap data store, e.g., by storing transactions or state data. As part of a hot swap or hot scaling function, hot swap manager140may push and copy the state of the first container126A of the first CSP122A to the second container of the second CSP122B, e.g., container126E, such that, e.g., second container126E of second CSP122B may take over and seamlessly transition execution of the applications from the first container126A of first CSP122A. In some examples, orchestration engine106may dynamically create virtual circuit127B between first CSP122A and second CSP122B to enable communications between containers126A-C executed by first CSP122A and containers126D-F executed by second CSP122B. Although illustrated as a separate virtual circuit127B, virtual circuit127B may represent an extension of underlying virtual circuit elements (e.g., Virtual Local Area Networks (VLANs)129A,129B or an Internet Protocol-Virtual Private Network (IP-VPN) shared in common), thereby enabling containers126A-C executed by first CSP122A to exchange data with containers126D-F executed by second CSP122B as well as with orchestration engine106.

In some examples, container hot swap manager140receives state from a primary container126D executing in cloud service network124B. The state is usable by container hot swap manager140to replicate, to another container, at least one of the operating environment provided by container126D (e.g., a container image), one or more applications executed by the container126D, a transaction being performed by the container126D, and/or an operating state of the container126D and the one or more applications. In some cases, container hot swap manager140may receive a container registration handle from the container126D via APIs105and request state from the container126D. In some cases, container126D (e.g., using a network module described herein) sends the state to container hot swap manager140autonomously. In some cases, an application executed by container126D or another container of cloud service124B may send the state to container hot swap manager140.

Container hot swap manager140may store the state to an in-memory data store or other database or data store of the cloud exchange102. The database may include, for instance, a Redis data structure store. Container hot swap manager140may be configured to hot swap or hot scale a primary container126D executing in cloud service provider network122B to a cloud service provider network122A. For example, an enterprise116may request, using customer portal104or via APIs105, that cloud exchange102provide a hot swap or hot scaling service for container126D using cloud service124A. Customer portal104may present a portal interface by which enterprise116may configure identifying information for container126D (e.g., a URI or container registration data as described herein) and also may select cloud service124A to support the hot swap or hot scaling service.

In response to a hot swap or hot scaling event, container hot swap manager140“stands up,” “spins up,” or establishes a new secondary container126A in cloud service124A for primary container126D in cloud service124B to provide an operating platform for a workload previously being executed by primary container126D. For example, container hot swap manager140may configure a new container in cloud service124A. Container hot swap manager140may also use an existing container in cloud service124A. In some cases, container126A has registered a container registration handle with container hot swap manager140. A hot swap or hot scaling event may include a request from enterprise116, a message from container126D indicating failure or overloading of the container126D, a triggering of a policy rule of cloud exchange102, or other event that causes container hot swap manager140to stand up a new secondary container to support primary container126D.

To stand up the new secondary container126A, container hot swap manager140sends state data from container126D and stored by container hot swap manager140to container126A, which uses the state data to replicate the operating environment of primary container126D. As such, the operating environment of secondary container126A may process workloads previously processed by primary container126D.

Container hot swap manager140may configure network platform108to redirect workloads from enterprise116, previously directed to primary container126D, to secondary container126A. Enterprise116may direct requests, via virtual circuit127A configured in networking platform108(as shown inFIG. 1), to containers to execute a workload. Container hot swap manager140may configure routing information in routers110or network address translation (NAT) mapping in a NAT device (not shown) to cause requests directed for primary container126A to be forwarded by network platform108to secondary container126E. In some cases, e.g., a NAT mapping may be configured to cause the NAT device to rewrite a destination network address for packets that include a request from enterprise116to a network address of a host for secondary container126E instead of a network address of a host for primary container126A. In some cases, container host swap manager140may reconfigure a Domain Name Service (DNS) record to cause redirects of requests to secondary container126E.

Secondary container126E may satisfy the request and, if necessary, return results to enterprise116via virtual circuit127A. In this way, hot swaps and hot scalings may be transparent to enterprise116.

In some examples, enterprise116may purchase service licenses for cloud services124from CSPs122. In some examples, each service license may grant enterprise116permission to register and deploy a number of containers on the cloud service provided by the CSP. For example, enterprise116may purchase a license to deploy fifty containers on cloud service124A. Similarly, enterprise116may purchase a license to deploy twenty containers on cloud service124B. Orchestration engine106may register the licenses enterprise116has to deploy the selected numbers of containers in each cloud service, and may perform hot swaps or hot scaling in the context of deploying, creating, and managing up to the selected numbers of containers in each of the cloud services124.

Thus it may be seen that a system in accordance with example techniques of this disclosure may enable a cloud exchange to hot swap and hot scale containers within a private or public network or across different private or public cloud services or networks. Such a system in accordance with example techniques of this disclosure may direct workflows from a first container in a first CSP to one or more additional containers in a second CSP, either instead of or in addition to the first container, for hot swaps and hot scaling, respectively. Such a system in accordance with example techniques of this disclosure, e.g., a hot swap manager of an orchestration engine of a cloud exchange, may also in some cases store a unique container identifier for each container, and in some cases store a unique registration handle for each container that combines the network address and the unique container identifier for each container.

A system in accordance with example techniques of this disclosure may copy all of the state (for a hot swap) or a portion of the state (for a hot scaling) from the first container to the one or more additional containers, where the copied state may include any current instruction pointers, application data, application stack configuration data, microservice state, memory data, commands, process information, current data store pointers, and/or any other code, data, instruction pointers, or other state for one or more applications, a runtime, and any other resources executing in the first container, to the one or more additional containers. A system of this disclosure, e.g., an orchestration engine, may then cause application traffic bound for the original, primary, first container to be directed to the secondary swapped container or the scaled containers, such that the functions of the first container are performed by the swapped or scaled containers. Systems of this disclosure may thus enable cloud services to maintain more effective service to their customers by minimizing or quickly remedying interruptions to microservices or other applications provided by a particular container. Further, systems of this disclosure may further allow an enterprise using a cloud exchange to more effectively perform load balancing of the network, so as to avoid strain on one particular system, which may otherwise cause adverse performance and negatively impact the performance parameters or experience of the customer.

As one illustration of the techniques of the disclosure, an example Application Programming Interface (API) definition is provided for facilitating inter-container communications, via a cloud exchange, for containers executing at logically isolated networks. The following API is an example POST operation that, when executed by orchestration engine106, provisions the virtual network for containers.

Header AttributeDescriptionAuthorizationRequired. Specifies the Oauth Bearer token

In the above example API, the request is an HTTP POST command to a uniform resource identifier (URI) that is an API105interface for provisioning virtual networks for containers. The body of the message contains one or more request parameters that specify the configuration options for the virtual network for containers. In one example, an administrator of enterprise116accesses customer portal104to access APIs105which transmit the request to orchestration engine106to request provisioning of a virtual network for containers. In another example, the administrator of enterprise116accesses APIs105directly to transmit the request to orchestration engine106to request provisioning of a virtual network for containers. In response to receiving the request URI, the orchestration engine106provisions a virtual network for containers. Further, the orchestration engine106transmits a response message, as depicted above, to enterprise116that indicates the successful provisioning of the virtual network as well as the specific configuration details for the provisioned virtual network. The body of the example Response provided above may be similar to the body of an example request, as provided above.

In another example, an administrator of enterprise116accesses APIs105, either through customer portal104or directly, to establish configuration settings, such as detection and performance criteria, for triggering and performing hot swaps and/or hot scaling of containers. In another example in which container126A in cloud service124A has been hot swapped with container126E in cloud service124B, orchestration engine106may configure an API gateway to redirect application requests or other cloud service traffic from enterprise network118for resources in container126A to container126E, either across virtual circuit127B from cloud service124A or via VLAN129B from cloud exchange102.

In the above example API, the “name services” parameter specifies the connection name. This parameter is provided as a string. In the above example response, the “name services” parameter has set the name of the virtual network to be “Docker Virtual Network.”

In the above example API, the “id” parameter specifies an identifier for the virtual network. In an example where enterprise116or orchestration engine106access multiple virtual networks, enterprise116and orchestration engine106may use the identification tag parameter to distinguish the origin of network traffic received from each virtual network.

In the example above API, the “driver” parameter indicates the type of connection being requested, here, a “ECX_Docker_Network” to indicate a virtual network for containers, in accordance with techniques described herein.

In the above example API, the “data center port” parameter in the options substructure specifies a data port through which enterprise116communicates with the virtual network. This parameter may be an integer specifying the actual port of the cloud exchange (e.g., “9001”), where the port represents an interface port of a switch or panel for accessing the cloud exchange networking platform108.

In the above example API, the “subnet” parameter specifies a subnet of containers on a CSP. For example, and with reference toFIG. 1, the “subnet” parameter may specific a subnet128A on CSP122A that includes containers126A-126B. Each subnet is specific to a particular CSP122, and each subnet128may contain one or more containers126executing on hosts within the CSP122. However, a virtual network as described herein multiple subnets belonging to different CSPs. For example, a single virtual network may include both subnet128A of CSP122A and subnet128B of CSP122B.

In the above example API, the “gateway” parameter specifies an address of a gateway or edge router of enterprise116that exists between the enterprise network118and the cloud exchange102. Orchestration engine106routes traffic destined to enterprise116from the virtual network to this gateway address.

The following parameters may be included in descriptive data for containers, as a structured container object in a list of “Containers.” Description data for containers may represent container registration data.

In the above example API, the “provider” parameter specifies a CSP122for hosting a container requested to be provisioned by enterprise116. In some examples, the provider is specified to be one of Azure Express Route, AWS Direct Connect, Cloud Sigma, and the like.

In the above example API, the “speed” parameter specifies a connection speed for the virtual network. In some examples, the “speed” parameter sets a maximum connection speed for the network.

In the above example API, the “code” parameter specifies a region for the virtual network. In the above example, the “code” parameter “SG” specifies that the virtual network is to be provisioned in the Singapore region. In other examples, the “code” parameter specifies a city, zip code, county, state, province, country, or continent.

In the above example API, the “macAddress” parameter describes a MAC address for a host of a container. For example, enterprise116may use this parameter to request the MAC address for a host of a container. One of orchestration engine106or CSP122responds by providing the requested MAC address.

In the above example API, the “port” parameter describes a port for a container. In some examples, each container126executes on a host. For example, with reference toFIG. 3, each container306executing on host304may have a unique host address+port combination or a unique network prefix/subnet+port combination that identifies the container in the cloud service provider network. Enterprise116may use this parameter to specify the port for a specific container. Alternatively, enterprise116may use this parameter to request the port for a specific container. One of orchestration engine106or CSP122responds by providing the requested port of the container.

The parameters specified in the above example API are for illustrative purposes only. The techniques of the disclosure may be implemented using the example API provided above, or with different parameters not expressly disclosed herein. For example, the techniques of the disclosure may be implemented using only a subset of the parameters described above, or may provision the virtual network for containers or perform hot swaps or hot scaling without using any of the parameters described above. Nothing in this disclosure should be construed so as to limit the techniques of this disclosure to the example API illustrated above. Specific techniques for the design and implementation of a virtual network for containers are described in U.S. Provisional Application No. 62/286,259 and U.S. patent application Ser. No. 15/228,471, the entire contents of both of which are incorporated by reference herein.

FIG. 3is a block diagram illustrating an example router within a cloud exchange in accordance with one or more techniques of the disclosure. In general, router200may operate substantially similarly to routers110A-110N inFIG. 1. In this example, router200includes interface cards214A-214N (“IFCs214”) that may receive packets via incoming links216A-216N (“incoming links216”) and send packets via outbound links218A-218N (“outbound links218”). IFCs214are typically coupled to links216,218via a number of interface ports. Router200also includes a control unit202that determines routes of received packets and forwards the packets accordingly via IFCs214.

Control unit202may comprise a routing engine204and a packet forwarding engine210. Routing engine204operates as the control plane for router200and includes an operating system that provides a multi-tasking operating environment for execution of a number of concurrent processes. Routing engine204, for example, may execute software instructions to implement one or more network protocols208. For example, network protocols208may include one or more routing and switching protocols, such as Border Gateway Protocol (BGP), Multi-protocol Label Switching (MPLS), Virtual Private LAN Services (VPLS), Ethernet Virtual Private Networking (EVPN), or Provider Backbone Bridging EVPN (PBB-EVPN) for exchanging routing information with other routing devices and for updating routing information206. Routing information206may describe a topology of the cloud exchange in which router200resides, and may also include routes through the shared trees in the computer network. Routing information206describes various routes within the computer network, and the appropriate next hops for each route, i.e., the neighboring routing devices along each of the routes. Routing engine204analyzes stored routing information206and generates forwarding information212for forwarding engine210. Forwarding information212may associate, for example, network destinations for certain multicast groups with specific next hops and corresponding IFCs214and physical output ports for output links218. Forwarding information212may be a radix tree programmed into dedicated forwarding chips, a series of tables, a complex database, a link list, a radix tree, a database, a flat file, or any of various other data structures.

Forwarding information212may include lookup structures. Lookup structures may, given a key, such as an address, provide one or more values. In some examples, the one or more values may be one or more next hops. A next hop may be implemented as microcode, which, when executed, performs one or more operations. One or more next hops may be “chained,” such that a set of chained next hops performs a set of operations for respective different next hops when executed. Examples of such operations may include applying one or more services to a packet, dropping a packet, and/or forwarding a packet using an interface identified by the one or more next hops. Router200may be configured, at least in part, by interconnection platform103as shown inFIGS. 1 and 2, including by container hot swap manager140.

In accordance with techniques of this disclosure, router200may operate as one of routers110in the example ofFIGS. 1 and 2. In one example, routing engine204may use routing protocols208to exchange routing information with each of a plurality of cloud services (e.g., cloud services124) and store learned routes through cloud services124in routing information206. Forwarding engine210may associate various subnets, such as subnets128A and128B, with various cloud services, such as cloud services124A and124B, respectively, and store this information in forwarding information212. Router200may receive an L2/L3 data communication, which may, for example, originate from container126A and be addressed for container126D, along incoming links216. Control unit202may parse the data communication for a network address (e.g., IP address) within subnet128B and, based on forwarding information212, forward the data communication toward subnet128B, wherein container126D may receive the forwarded communication. The network address may be associated with a first container that hot swap manager140has hot swapped or hot scaled, such that the network address is now associated with one or more additional containers, instead of or in addition to the original container. Hot swap manager140may also configure control unit202to address data communications to unique container identifications associated with a network address, such as in cases where alternative or additional containers (for hot swaps and hot scalings, respectively) have been assigned to the same network address as a first container. Forwarding engine210may transmit the data communication along outbound links218to subnet128B within cloud service124B, wherein container126D may receive the data communication.

Accordingly, it may be seen that a router within a cloud exchange implemented according to techniques of this disclosure may receive a data communication from a first container within a first private network and transmit that data communication to one or more second containers which may be within the same first private network, within a second private network, or in a public cloud services network. Such a router may allow a container to exchange data between microservices or other applications executing on containers on the same or different private or public networks. Further, such a router may allow a private network to maintain more effective service to their customers by minimizing or remedying interruptions to a microservice or other application provided by a particular container. Further, such a router may allow a private network to more effectively perform load balancing of the network, so as to avoid strain on one particular system, which may otherwise cause adverse performance and negatively impact the performance parameters or experience of the customer.

The architecture of router200illustrated inFIG. 3is shown for example purposes only. Techniques as set forth in this disclosure may be implemented in the example router ofFIG. 3as well as other types of routers not described specifically herein. In other examples, routers enabled to function in accordance with this disclosure may be configured in a variety of ways. In some examples, some of the functionality of control unit202may be distributed within IFCs214. In some examples, control unit202may comprise a plurality of packet forwarding engines. Nothing in this disclosure should be construed so as to limit techniques of this disclosure to the example architecture illustrated byFIG. 3.

FIG. 4is a block diagram illustrating an example private network configured in accordance with example techniques of this disclosure. In the example ofFIG. 4, operator302may operate a private network300possessing computing resources by which one or more customers may execute a plurality of applications and microservices. In some examples, operator302may be an enterprise, such as enterprise116ofFIGS. 1 and 2. In some examples, operator302may be a CSP, such as an operator for any of CSP122A or CSP122B ofFIGS. 1 and 2. In some examples, private network300may be an enterprise network, such as enterprise network118ofFIGS. 1 and 2. In some examples, private network300may be a cloud service, such as cloud service124A or124B ofFIGS. 1 and 2. Private network300may comprise a plurality of hosts304A,304B, and304C (collectively, “hosts304”). In some examples, a host may be a server running on private network300. In other examples, one or more hosts may be one or more virtual machines executed on one or more servers running on private network300. Each of hosts304may have an IP address such that the host may be identified on private network300. In some examples, a plurality of hosts may possess a plurality of IP addresses falling within an IP subnet, such as IP subnets316A,316B. Hosts304may communicate with network edge device318, which may represent a router or L3 switch. Network edge device318may connect along virtual circuit127A to a cloud exchange, such as cloud exchange102ofFIGS. 1 and 2. In some examples, network edge router318may operate to forward messages between hosts304and cloud exchange102.

Each host may execute one or more containers. In the example ofFIG. 4, host304A is configured to execute containers306A and306B, host306B is configured to execute containers306C and306D, and host304C is configured to execute containers306E and306F (collectively, “containers306”). Containers306may operate in a similar fashion as and may represent any of containers125and126ofFIGS. 1 and 2. Each host304may implement a specific kernel instance310, common libraries312, and kernel specific libraries314. Each of the containers executed within a particular host share a kernel310and common libraries312(e.g., containers306A and306B of host304A share kernel310A and common libraries312A). In one example, any of hosts304may execute the Docker container application for the Linux operating system, which in such examples are represented by containers306and kernel310, respectively.

In some examples, each of the containers within the host may share the IP address of the host. In some examples, each container may be uniquely identified by a container ID or port ID. In some examples, the port ID of a container identifies a Transmission Control Protocol (TCP) port or a User Datagram Protocol (UDP) port. In the example ofFIG. 4, containers306A and306B may share IP address 192.168.1.125 with host304A. In this example, container306A may be associated with port ID5001for the host304A while container306B may be associated with port ID5002. In some examples, host304A may forward traffic destined for TCP port5001to container306A and forward traffic destined for TCP port5002to container306B. According to example techniques of this disclosure, each of containers306may possess a network module308, as described herein, to allow the container to communicate with cloud exchange102. Orchestration engine106may communicate data for the network modules308to containers306to enable such responsive interaction of containers306with cloud exchange102, and with container hot swap manager140in particular.

In some examples, an enterprise, such as enterprise116ofFIGS. 1 and 2, may purchase or otherwise contract for a number of containers to be deployed within a cloud service, such as cloud service124A. In some examples, enterprise116may create at least one application, such as a microservice. Each of containers306may provide an execution environment for the applications. In some examples, each of containers306may provide an execution environment for at least one unique application or microservice, while in other examples, each of containers306may provide redundant access to at least one application or microservice. In some examples, each customer of private network300may access a single container (e.g., container306A). In some examples, a customer may have access to a plurality of containers (e.g., containers306A,306B, and306C). In some examples, each container within a subnet may provide a particular suite of applications or microservices. In some examples, each container within a subnet may provide access to private network300to a particular customer or group of customers.

According to example techniques of this disclosure, containers306include respective network modules308extended to obtain and send, to a cloud exchange, container registration data including, e.g., network data and container identification data for the container. For example, container306A includes network module308A that obtains a network address for host304A in subnet316A and further obtains a container identifier for container306A, the container identifier usable by the kernel310A to identify container306A from other containers executing on host307A, such as container306B. In some cases, the container identifier is a unique container identifier that distinguishes container306A from all other containers in private network300. In some cases, the container identifier is a networking port, such as a TCP or UDP port, that distinguishes container306A from other containers executing on the host. In some cases, the container identification data includes both a unique container identifier and a networking port. In any of these cases, a unique container identifier and/or a networking port assigned to a particular container may be referred to generally as a container identifier.

Network modules308self-register the container registration data by invoking APIs105of cloud exchange102to send the container registration data. In this way, interconnection platform103of cloud exchange102receives container registration data by which interconnection platform103may, via a virtual circuit, send data communications to the corresponding container306. For example with respect to container306A, network module308A may invoke APIs105, via a virtual circuit127A with cloud exchange102, to send the container registration data for container306A to interconnection platform103.

Interconnection platform103may store container registration data for containers306. Interconnection platform103may associate multiple containers in an association and send each container in the association container registration data for other containers in the association. As a result, a container in an association may use the container registration data to send data communications via a cloud exchange to another container in the association that is located in a different private network coupled to the cloud exchange.

According to example techniques of this disclosure, container306A within private network300may communicate with a container within another private network connected to cloud exchange102, such as container126E within cloud service124B. In this example, based on container registration data received from interconnection platform103, container306A may generate a data communication having a container identifier (e.g., a port) indicating the destination container (e.g., container126E) and a network address (e.g., an IP address within a subnet128B of CSP122B) for a host that executes the destination container. Container306A may output this data communication for transmission outside private network300via virtual circuit127B to routers110of cloud exchange102. As described above, orchestration engine106may operate networking platform108to forward the communication to the destination subnet of the appropriate cloud service (e.g., to subnet128B of cloud service124B). Cloud service124B may direct the data communication to container126E within subnet128B. If container126E responds with a second data communication, cloud service124B may pass the second data communication to routers110of cloud exchange102. Cloud exchange102may include networking platform108to redirect the second data communication to private network300along a communication link such as virtual circuit127B.

Network edge device318may receive the second data communication from virtual circuit127A/127B and forward the data communication to the host having the IP address identified by the data communication (e.g., host304A). In some examples, the destination IP address of second data communication may specify a TCP/UDP port of host304A. Host304A may pass the second data communication to the container having a port ID matching the TCP/UDP port of the destination IP address. Thus, it may be seen that a private network implemented according to example techniques of this disclosure may enable communication between a first container within a first private network connected to a cloud exchange and a second container within a second private network connected to the cloud exchange.

In some examples, container306A may generate and send data representing a state of the container306A to a cloud exchange for hot swapping or hot scaling using network module308A.

The architecture of private network300illustrated inFIG. 4is shown for example purposes only. Example techniques of this disclosure may be implemented in the example cloud service ofFIG. 4, as well as other types of cloud services not described specifically herein. In other examples, private network300may be configured in a variety of ways. In some examples, private network300may implement various APIs, operating systems, hardware, or software that share a common communication protocol with the cloud exchange. In some examples, each cloud service of the cloud exchange may use a different communication protocol to exchange data with the cloud exchange, and the cloud exchange may act to facilitate or translate communications between cloud services using different communication protocols. Nothing in this disclosure should be construed so as to limit techniques of this disclosure to the example architecture illustrated byFIG. 4.

FIG. 5is a block diagram illustrating an example container according to example techniques of this disclosure. Container400may be a virtualized container such as those provided by the Docker container technology for the Linux operating system. In some examples, container400may share an operating system and common libraries with other containers and the host kernel. In some examples, container400may send and receive data communications, control signals, and various other transmissions to and from the system kernel through kernel interface404.

In some examples, container400may use network module402in conjunction with kernel interface404to compose, send, and receive data to and from a network. For example, network module402may enable container400to communicate according to various networking protocols, such as Virtual Extensible LAN (VXLAN), IPVLAN, MACVLAN, VPLS, EVPN, or PBB-EVPN. According to example techniques of this disclosure, network module402may operate to self-register the corresponding container of a plurality of containers, operating within a plurality of networks coupled to a cloud exchange, with the cloud exchange to facilitate communications among the containers via the cloud exchange. Network module402includes several identifiers so that container400may be identified on a private network, such as a cloud service or enterprise network. Container identifier414is a data field that uniquely identifies container400against other containers. In some examples, container identifier414is a port ID that corresponds to a TCP/UDP port of the host computer executing container400. Host network address416is a data field that identifies the network address of the host on which container400executes. In some examples, host network address416may be an IP address. In various examples, host network address416may generally be a Uniform Resource Identifier (URI).

In some examples, container400is configured to execute at least one microservice410and associated microservice-specific libraries412. In some examples, container400is configured to execute at least one application and associated application-specific libraries, such as application406A and406B and application-specific libraries408A and408B, respectively. Container400may provide the at least one microservices and applications to a customer for access through a cloud service. Because container400is virtualized and isolated from the system kernel and other containers, container400may provide a customer with safe and secure access to the at least one microservices and applications. In some examples, container400may be a container within a Microsoft Azure cloud service. In these examples, container400may provide a customer with an environment to execute a suite of applications. In some examples, container400may be a container within an Amazon Web Services cloud service. In these examples, container400may provide a customer with an environment to execute one or more microservices.

The architecture of container400illustrated inFIG. 5is shown for example purposes only. Example techniques as set forth in this disclosure may be implemented in the example container ofFIG. 5, as well as other types of containers not described specifically herein. In various examples, container400may be configured in a variety of ways. In some examples, container400may implement various APIs, one or more applications, or one or more microservices. In some examples, container400may implement a single application or a single microservice. Nothing in this disclosure should be construed so as to limit techniques of this disclosure to the example architecture illustrated byFIG. 5.

FIG. 6is a block diagram illustrating an orchestration engine for a cloud exchange according to techniques described in this disclosure. Orchestration engine550may represent an example instance of orchestration engine106ofFIGS. 1 and 2. WhileFIG. 6is described with reference toFIGS. 1 and 2,FIG. 6may apply generally to various techniques of this disclosure.

Orchestration engine550receives, via APIs105, container registration data from containers executing in private networks (e.g., enterprise and CSP networks) coupled to a cloud exchange (e.g., cloud exchange102ofFIGS. 1 and 2) managed at least in part by an interconnection platform that includes the orchestration engine550. Orchestration engine550stores, to a database or other data store552, container records554having entries for respective containers and including corresponding container registration data for containers. The container registration data may include a respective container registration handle for each available container, where each container registration handle includes both a network address and a unique container identifier (potentially a port number) for the respective container. Orchestration engine550may use container registration data to extend network connectivity through the private network that includes a container and address the container directly via a virtual circuit by which the private network communicate with the cloud exchange and, in some cases, other private networks. Container hot swap manager540, which may be an implementation corresponding to container hot swap manager140ofFIGS. 1 and 2, may modify the container registration handles in container data store552to assign the network address of a first container to one or more second, alternative containers, in the case of performing a hot swap. Container hot swap manager540may modify the container registration handles in container data store552to assign the network address of a first container to one or more second, additional containers, in the case of performing a hot scaling.

In some examples, container hot swap manager540may also copy state from a first container in a first CSP, and store the container's state in data store552before or in parallel with sending the state to one or more containers in a second CSP. Hot swap manager540may store the state more or less temporarily in some examples to ensure that the state is preserved before sending the state to the new one or more containers in the new CSP and confirming with the second CSP that the state has been successfully written to the new one or more containers and is being used for execution by the one or more new containers without any loss of state from the original container in the first CSP after the hot swap or hot scaling process.

Orchestration engine550may create an association between containers owned by, licensed to, and/or accessible to an enterprise but operating in different private networks (e.g., an enterprise network and one or more cloud service networks). Based on a network address for a container and an IP subnet identified by a service key, orchestration engine550may correlate a service key to a container executing at a cloud service network to associate the container to an enterprise that provided the service key. In this way, the container is registered to the enterprise in orchestration engine550.

Orchestration engine550may establish a virtual circuit between an enterprise network and the cloud service network. Containers may provide their corresponding container registration data to orchestration engine550via the virtual circuit (e.g., one or more VLANs). Orchestration engine550may in some cases provide the container registration data to the enterprise such that containers executing at the enterprise network may address containers in the cloud service network using a container host network address and container port/identifier, via the virtual circuit.

Container hot swap manager540may be vendor-neutral in that the cloud exchange provider may implement container hot swap manager540in conjunction with any of a plurality of cloud service providers selectable by the enterprise. In some cases, orchestration engine550may independently deploy containers to cloud services in order to facilitate the back-end setup for container hot swap manager540.

For container hot swap manager540, the enterprise operator may create an association between containers. The enterprise operator may access a list of containers for the enterprise and a list of containers for various cloud services, create associations between containers from the different lists, and configure settings or schedules for hot swaps and hot scalings between containers in different cloud services. For instance, the enterprise operator may specify container126E in a second cloud service is a replica of container126A in a first cloud service. In some cases, containers accessible via a particular virtual circuit may be automatically associated by orchestration engine550. Having been associated, orchestration engine550then provides the container registration data for a container to associated containers to enable the associated containers to address data communications to the container for hot swaps or hot scalings of the containers.

In various examples, container hot swap manager540may store hot swap and hot scaling configuration settings for particular containers. When container hot swap manager540detects that specific criteria have been met or triggered for a hot swap of a first container in a first CSP, container hot swap manager540may copy all of the state from the first container, stand up a new container in a second CSP if needed, send the state from the first container in the first CSP to the second container in the second CSP, and confirm that the second container in the second CSP is executing with the state from the first container. In some examples, container hot swap manager540may store the state in an internal data store552of orchestration engine550during at least part of the hot swap process. When container hot swap manager540detects that specific criteria have been met or triggered for a hot scaling of a first container in a first CSP, container hot swap manager540may copy all of the state from the first container, stand up one or multiple new containers in a second CSP if needed, send at least some of the state from the first container in the first CSP to the one or multiple containers in the second CSP, and confirm that the one or multiple containers in the second CSP are executing with the at least part of the state from the first container.

FIG. 7is a flowchart illustrating an example method according to techniques of this disclosure.FIG. 7is described with reference toFIGS. 1 and 2; however,FIG. 7may apply generally to any of various techniques of this disclosure. In some examples, a cloud exchange (e.g., cloud exchange102, and in some particular examples, container hot swap manager140of orchestration engine103of cloud exchange102) may store data indicating an association of a first container of a first private network with a second container of a second private network (e.g., container126A of CSP122A, container126E of CSP122B), wherein the first private network and the second private network are coupled to the cloud exchange to send and receive data packets via the cloud exchange (602). The cloud exchange may, based on the association indicated by the stored data, send state of the first container of the first private network to the second container of the second private network (604), such as in a hot swap or hot scaling process. This may apply to multiple second containers in a hot scaling process, and the second container may take over all or part of the processing or executing of the first container.

FIG. 8is a block diagram illustrating one example of a computing device that operates in accordance with one or more techniques of the present disclosure.FIG. 8may illustrate a particular example of a server, a host304as shown inFIG. 4, or another computing device900that implements cloud exchange102or any portion thereof, or that includes one or more processor(s)902for executing at least a portion of interconnection platform application924, or any other computing device described herein. Other examples of computing device900may be used in other instances. Although shown inFIG. 8as a stand-alone computing device900for purposes of example, a computing device may be any component or system that includes one or more processors or other suitable computing environment for executing software instructions and, for example, need not necessarily include one or more elements shown inFIG. 8(e.g., communication units906; and in some examples components such as storage device(s)908may not be colocated or in the same chassis as other components). Computing device900may be located and execute, for example, at another interconnection facility, or at a branch office or cloud computing environment employed or used by a colocation facility or cloud exchange provider.

As shown in the specific example ofFIG. 8, computing device900includes one or more processors902, one or more input devices904, one or more communication units906, one or more output devices912, one or more storage devices908, and one or more user interface (UI) devices910. Computing device900, in one example, further includes one or more applications922, interconnection platform application924, and operating system916that are stored on one or more storage devices908and executable by computing device900. Each of components902,904,906,908,910, and912are coupled (physically, communicatively, and/or operatively) for inter-component communications. In some examples, communication channels914may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data between the various other components of computing device900. As one example, components902,904,906,908,910, and912may be coupled by one or more communication channels914.

Processors902, in one example, are configured to implement functionality and/or process instructions for execution within computing device900. For example, processors902may be capable of processing instructions stored in storage device908. Examples of processors902may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

One or more storage devices908may be configured to store information within computing device900during operation. Storage device908, in some examples, is described as a computer-readable storage medium. In some examples, storage device908is a temporary memory device, meaning that a primary purpose of storage device908is not long-term storage. Storage device908, in some examples, is described as a volatile memory device, meaning that storage device908does not maintain stored contents when the computer is turned off. Examples of volatile memory devices include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memory devices known in the art. In some examples, storage device908is used to store program instructions for execution by processors902. Storage device908, in one example, is used by software or applications running on computing device900to temporarily store information during program execution.

Storage devices908, in some examples, also include one or more computer-readable storage media. Storage devices908may be configured to store larger amounts of information than volatile memory. Storage devices908may further be configured for long-term storage of information. In some examples, storage devices908include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Computing device900, in some examples, also includes one or more communication units906. Computing device900, in one example, utilizes communication units906to communicate with external devices via one or more networks, such as one or more wired/wireless/mobile networks. Communication units906may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include 3G, 4G and WiFi radios. In some examples, computing device900uses communication unit906to communicate with an external device.

Computing device900, in one example, also includes one or more user interface devices910. User interface devices910, in some examples, are configured to receive input from a user through tactile, audio, or video feedback. Examples of user interface devices(s)910include a presence-sensitive display, a mouse, a keyboard, a voice responsive system, a video camera, a microphone, or any other type of device for detecting a command from a user. In some examples, a presence-sensitive display includes a touch-sensitive screen.

One or more output devices912may also be included in computing device900. An output device912, in some examples, is configured to provide output to a user using tactile, audio, or video stimuli. Output device912, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines. Additional examples of output device912include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.

Computing device900may include operating system916. Operating system916, in some examples, controls the operation of components of computing device900. For example, operating system916, in one example, facilitates the communication of one or more applications922and interconnection platform application924with processors902, communication unit906, storage device908, input device904, user interface device910, and output device912. Application922and interconnection platform application924may also include program instructions and/or data that are executable by computing device900. Interconnection platform application924may be configured to, when executed by computing device900, provide functionality attributed to interconnection platforms described herein, including interconnection platform103, and components or features thereof such as hot swap manager140and orchestration engine106, as shown inFIGS. 1 and 2.

For example, interconnection platform application924may include a hot swap manager926. Hot swap manager926may be implemented as application modules, libraries, features, or other portions of executable instruction code as part of interconnection platform application924. Hot swap manager926may be implemented as a separate application or any other form of executable instruction code in other examples. Hot swap manager926may include instructions for causing computing device900to perform any of the techniques described in the present disclosure such as with respect to hot swap manager140and/or hot swap manager510as described above. As one example, hot swap manager926may include instructions that cause computing device900to store data (on any one or more of computing device900, orchestration engine106, networking platform108, and/or one or more routers110/200as shown inFIGS. 1-3, and/or any other computing or networking resource) indicating an association of a first container of a first private network with a second container of a second private network, wherein the first private network and the second private network are coupled to cloud exchange106to send and receive data packets via cloud exchange106. Hot swap manager926may also include instructions that cause computing device900, orchestration engine106, networking platform108, and/or one or more routers110/200as shown inFIGS. 1-3, and/or any other computing or networking resource, to send, based on the association, state of the first container to the second container. Hot swap manager926may also include instructions that cause computing device900to perform any other functions of a hot swap and/or hot scaling process in accordance with the techniques of this disclosure.