Multi cloud and hybrid cloud computing is a popular topic of late. Good advances have been made in portability of workloads and managing rented computing resources. One important aspect that remains elusive is how to interconnect all of the components distributed across various cloud locations.
This article will introduce Virtual Application Networks (VANs) as a general solution to multi and hybrid cloud interconnect.
A Virtual Application Network must meet the following requirements:
- Flexible topology for interconnected cloud locations
- No requirement for a star or full-mesh topology
- Allow redundant paths for resiliency
- Location-independence for addresses of software components
- Cross-network multicast
- Cross-network anycast for load balancing
- Support for large numbers of private/edge locations having overlapping IP sub-networks
- Can be set up by a developer without special privileges
The Internet Protocol is not well suited for Hybrid Cloud Interconnect
First, it will help to understand the real difficulty with hybrid cloud networking. Everything is connected to the Internet, right? So what’s the big problem?
The problem is that the Internet Protocol (IP)-based network is built for a client/server world. In the earlier days of the Internet, as it was exploding in popularity and size, it became apparent that the address space was too small for the demand. IPv6 was introduced with a much larger address space, but the cost of conversion was too high and the new standard was not universally adopted. A number of innovations were made to address the problem: Classless Inter-Domain Routing (CIDR) helped make more efficient use of the available addresses but the real solution came with Network Address Translation (NAT). By introducing the idea of private IP networks connected via NAT routers, major swaths of the address space were relocated behind one or a small handful of public addresses. Now, millions of small and large private networks can share the same IP subnets. This is the state of the Internet today and the network still comfortably fits in the 32-bit IPv4 address space.
The NAT solution is effective because the predominant architecture for distributed software is client/server. The network is oriented north/south with clients in private networks connecting to big, dedicated, and expensive servers in public data centers.
Modern software development is moving away from client/server toward more flexible architectures with services located everywhere. The desired communication patterns are north/south, east/west, and every other direction on the compass. Developers and operators want to deploy only as much computing capacity as is needed at the moment. And they want to be able to flexibly deploy that capacity when and where it is needed to support their users.
The hard fact is that the current global network does not provide the addressing needed to meet the needs of modern distributed software.
What is a Virtual Application Network?
A VAN lets IP do what it is good at (fast and reliable north/south connection of everything) and introduces a new layer of addressing for fine grained application components with no constraints on who can talk to whom.
Whereas TCP/IP addressing uses a host:port pair to refer to an endpoint, VAN addressing uses arbitrary strings to refer to endpoints directly. In the modern world of virtualization, containers, and serverless computing, the notion of a host for a port is unnecessary and overly constraining.
Also, whereas IP addressing is primarily unicast, with each address referring to a single host, VAN addressing is either anycast or multicast. It builds in the idea that multiple software components can attach to the network with the same address for multicast delivery or for load balancing. IP does have a notion of multicast addressing, but it is not used in practice beyond the scope of a local area network. VAN multicast and anycast is not constrained by component location and therefore provides network-wide multicast delivery and anycast load balancing.
Another important aspect of a VAN is that it is deployed at the application layer for the purpose of serving a single distributed application. It does not need to be part of the network infrastructure and a VAN can be created by a developer or operator quickly and easily without access to administrative privileges or special networking infrastructure like VPNs, IPSec, SDN, Firewall mapping rules, etc.
How does a Virtual Application Network work?
How does a VAN work then? First, a VAN router is deployed in every site participating in the distributed application. Connectivity between the routers is established using TCP/IP in whatever topology works for full connectivity. It need not be a full mesh. There needs to be at least one path from every site to every other site, even if that path transits through other sites. Redundant paths are encouraged because they provide resilience against failure of a site or a connection. Note that it is OK for multiple private networks to participate even if they have overlapping CIDR subnetworks. Note also that there is no central controller or single point of failure.
The network of routers uses a routing protocol and algorithm to learn the topology and compute least-cost paths between each pair of sites. The routing protocol quickly and automatically reacts to changes in the topology. This serves to provide resilience against failure and also makes it easy to add locations to, and remove locations from the network as expansion or changes are needed.
At the next layer up, the VAN maps endpoint addresses to the sites in which the addressed components reside. Routing traffic to an address is then a two-step process of finding the location (or locations) where the desired destination lives and then using the router’s forwarding tables to route the traffic toward those locations.
The topmost layer maps protocol endpoints (DNS names, Kubernetes service names, messaging destinations, etc.) to VAN addresses. This is done for any application protocol, be it HTTP, gRPC, TCP, UDP, AMQP, MQTT, etc.
Where can one find a VAN?
There is an open-source implementation of a Virtual Application Network available from the Skupper project. The Skupper implementation is initially focused on providing multi-cluster interconnect for Kubernetes. Please visit the site to learn more, to see demonstrations on video, and to access example code and configurations that you can try on your own.
Skupper uses the Apache Qpid Dispatch Router as its VAN router. The router is based on the AMQP protocol and is lightweight and stateless. In addition to the base router, Skupper provides tools to facilitate network setup and to provide mappings from commonly used protocols like HTTP, gRPC, and TCP onto the VAN network.
Apache Qpid Dispatch Router uses a Link-State routing protocol, similar to OSPF or IS-IS, to detect topology and compute least-cost paths across the network.
netprototalk 