By Trevor Patch, Principal Architect for Cloud Adoption
Third-Party Hub and Native Spoke
The most common third-party public cloud design is leveraging the OEM’s virtual appliance as a hub. The virtual appliance is commonly hosted on a CSP owned virtual machine, such as an EC2 instance. It can be a physical device, such as a firewall or router residing at the data center or anywhere else in the world accessible through the internet. The hub establishes traditional IPSEC B2B VPN with each CSP virtual network construct’s native virtual private network (VPN) gateway. Like native direct peering, the routing is often static/manually implemented, and not operationally scalable for cloud heavy organizations leveraging human-driven implementations/configurations. The native spoke routing table would typically contain a default or RFC1918 supernets route towards the OEM’s appliance. The OEM’s appliance would have the more specific route entries for traversal to the desired destination network.
The design brings advantages in operational consistency across private, public, and multi-public cloud architectures with keeping costs relatively low. The iteration is very capable of being automated through various infrastructure as code (IaC) techniques. With some OEM’s products, such as the Cisco cAPIC, the design iteration deployment comes automated right out of the box for multiple clouds. The downside to the design is the performance. Placing the OEM’s appliance physically close to the spokes would be ideal, and not backhaul across the internet. Given that nearly all CSP appliances operate off a x86-64-bit system architecture, that limits an IPSEC tunnel to 1.25Gbps. Additionally, high availability between hub and spoke appliances can be either non-rapid or manual efforts that result in high mean time to repair. These limitations often stop many organizations as they fork-lift more workloads into the cloud. The result often leads an organization into rebuilding their infrastructure and swallowing the technical debt within operations created as a result.
Third Party Hub and Spoke
Another design iteration is leveraging a traditional OEM’s virtual appliance running on the CSP’s virtual machine offering within the spoke virtual network. The OEM’s spoke gateway would establish a tunnel to the OEM’s gateway running in the hub. The design comes with vast complexity in provisioning and automating. If an organization has the talent to operate a mini-ISP with that OEM’s operating model; then the design has an advantage over cloud native spokes. The main similar capability between native spokes and third-party spokes is the operational consistency. However, the two advantages third-party spokes have are:
The design iterations were immensely popular between 2012-2014, and many technical sessions from trade show events, such as Cisco Live, can be found in the archives from the time. However, due to the complexity and the lack of automation, traditional OEMs outside of Arista moved away from the model, because most organizations do not have the expertise to run a mini-carrier grade network for just cloud.
Read the other sections of this article:
Part 1: Background on the Need for Multi-Cloud
Part 2: Networking: A Brief History
Part 3: The Move to Zero Trust
Part 4: Public Cloud Network Topologies
Pure is redefining the storage experience and empowering innovators by simplifying how people consume and interact with data. Pure is delivering a modern data experience—empowering agencies to run their operations as a true, automated, storage as-a-service model seamlessly across all clouds
Our team doesn’t disappear after delivery. Your federal workforce and systems will be supported with the right level of resourcing and thought leadership to take your systems into the future.
We leverage the knowledge and experience of our extensive partner ecosystem to create an environment of collaborative efficiency. The teaming process is agile, accountable and transparent. We work with clients to make sure that their entire chain of command is well-informed and educated. No surprises, only mission-driven delivery of innovation.
Our solutions leverage proven Knowledge Centers to repurpose relevant past experience for efficiency, but are then customized to match the moment and unique circumstances of an agency customer. We bring the right partners to the table to collaborate around architecture and design and then innovate beyond the challenge; often introducing next-level opportunities for automation, collaboration and commerce. Our solutions address those modernization challenges that require breadth, depth and a level of technical thought leadership that comes with a team that has worked both inside and outside government. We often work with agency customers as they are thinking through a problem and arm them with the tools and knowledge to articulate project scope, timing and budget.
We are wholly mission-focused, providing our government clients with broad and deep technical expertise and independent perspective on leading technology solutions. We take the time to deeply understand client challenges from the start – as well as their definitions of success. We guide them in harnessing advances in emerging technology while also looking ahead to anticipate future applications and opportunities that are entrepreneurial, ripe for automation.