As the public cloud has expanded, the piece that arguably has scaled the least is us humans. Each new service addresses a need either to accelerate programming or to simplify configuration and deployment. AWS Transit Gateway has been successful in reducing the complexity of cloud networking by acting as a central shared hub for VPCs, but the service only works within AWS.
F5 Volterra provides a solution that extends and enhances the hub-and-spoke model within other clouds as well as globally between clouds, including simplifying the configuration and deployment of AWS Transit Gateway itself.
Connections between cloud virtual network VPCs have traditionally been ad hoc, creating connections wherever there is a perceived need. For a greenfield deployment, those connections can be useful in reflecting the relationships between microservices and in enforcing access controls. There may also exist a need to reflect constraints in physical environments, such as allowing connections between nodes in the same location which would otherwise follow an inefficient path such as the classic “trombone” or “boomerang.” However, infrastructure designed specifically for a single implementation historically places constraints on any future changes, which leads to the perceived need for a complete re-architecture as the initial design organically evolves.
As ad hoc connections increase, the architecture trends towards a mesh topology, in which each node is connected to multiple others. While mesh topologies allow ultimate flexibility in the data path—every possible destination is directly connected—meshes can be notoriously tedious to create and maintain without substantial automation.
In contrast to ad hoc, hub-and-spoke architecture is a disciplined way to organize connections. In a group of things, one thing acts as a central hub to connect to all the other things, but none of the others connect to each other. Visually this is usually drawn like a bicycle wheel, but is also often represented as a tree structure, with the hub on the top and the spokes on the bottom, like a family tree. The greatest advantage of hub-and-spoke or a tree is simplicity. It’s easy to draw, and easy to understand, because the only path between the spokes is through the hub. That also means it’s easier to maintain; not only does it take less time to identify the problem domain during an incident, but the basic structure is unaffected by any moves, adds, or changes of nodes.
The disadvantages are usually seen as a lack of flexibility and lower performance. However, a well-implemented hub keeps traffic moving quickly, and the ongoing maintenance advantages of simplicity outweigh any temporary benefit of flexibility during setup. Hub-and-spoke also provides a guaranteed data path between any two nodes, approaching the flexibility of a full mesh and reducing the need for ad hoc connections.
Cloud networking initially required ad hoc connections between compute instances until the arrival of VPC virtual networks. VPCs provide direct connectivity in each subnet, greatly simplifying configuration and application of policy. It’s useful to think of each VPC as hub-and-spoke.
AWS Transit Gateway interconnects VPCs in the same way that VPCs interconnect compute instances. It essentially acts as a tiered hub-and-spoke, a hub of hubs, or a VPC of VPCs. Nodes in different VPCs can connect to each other if those VPCs are both connected to the same Transit Gateway. Transit Gateways can also allow sharing of dedicated resources, such as combining VPNs using multiple VPCs for additional bandwidth or simplified remote user access.
F5 Volterra provides a uniform UI to create connections between clouds, to configure VPCs in those clouds using their native infrastructure-as-code APIs, and to manage the traffic and service delivery. On AWS, it provides full configuration and lifecycle control of Transit Gateways. If AWS Transit Gateway or other cloud provider native services are not used, the Volterra Console provides a uniform way to establish and control connections between virtual networks, converting the administrator’s intent into the cloud-specific configuration. In scenarios where there is a need for arbitrary connections between virtual network subnets, Volterra will even automate creating a full mesh if the administrator desires. The quick configuration greatly reduces tedium, and the automation nearly eliminates chances of errors.
Volterra extends the concept of multi-tiered hub-and-spoke networking to the global level, effectively functioning as a multi-cloud transit gateway to connect public and private clouds. The SaaS-based Volterra console provides unified global control across all regions of all major public clouds, as well as any of the customer’s private clouds they want to connect. The global architecture is completely configurable, whether it requires ad hoc connections, a full multi-cloud mesh, or a hub-and-spoke using the F5 global network as a dedicated private high-speed backbone.
Applying automation and multi-tiered architecture simplifies the task for an administrator to manage scaling out clouds, but the real benefits come from scaling out administrators. The Volterra console is natively multitenant and supports subdividing the organization into different namespaces. Each namespace is completely invisible to all others, even at the IP layer. Within each namespace, administrators can set intent-based policies, then delegate control to developers for self-service lifecycle management of their project-specific secure connections and services, without risk of disturbing any other projects or exceeding pre-set networking and security parameters. That’s human scalability across the organization, giving rank-and-file engineers control and visibility of multi-cloud networking within their own silos, with full global oversight for the cloud network administrators.