TL:DR
Multi-cloud tunneling with spoke gateways in every VPC is NOT cloud-native - It is value destruction. A multi-cloud networking solution should be both app & network-centric, follow a cloud-native approach and deliver the agility enterprises seek.
Disruption is the name of the game. In the hybrid multicloud world that we live in today, cloud practitioners, networking professionals, and executives are confronted with the challenging task of balancing multiple objectives such as agility, cost, and operational efficiency.
Customers, yes enterprise ones, have long been asked to make unnatural tradeoffs [a tradeoff tax, if you will] in achieving these outcomes.
- You want a networking solution that works across clouds, BUT you’ll get operational redundancy and complexity. Your staff will manage the lifecycle of virtual appliances installed in each VPC in the cloud instead of the data center.
- You want cost agility, BUT the new spend will mostly exceed with the shift from using cloud-native constructs to virtual appliances.
- You want cloud agnostic, BUT you’ll NOT get a cloud-native operating model
You want multicloud, BUT you must deal with costly, complex overlays that do not scale.
Hub and Spoke overlays - Making Trade-Offs
A good idea often bides its time. Hub and Spoke overlays ( where IPSEC tunnels were built from gateways or virtual routers from each VPC to a transit VPC ) were relevant until the CSPs caught up with their cloud-native versions. The “ disruptive idea “ became the norm. As an enterprise customer, you should question these tradeoffs you have been asked to make thus far.
- I want cloud agility AND operational simplicity. I want to leverage CSP native tools for connectivity as much as possible and not have to reinvent the wheel or manage appliances for this purpose.
- I want cloud agnostic AND cloud native. An ISV that takes a “good cloud-native” idea and makes it multi-cloud-native is much more “enterprise-ready” and future-proof than the one asking customers to pay this “tradeoff tax.”
- I want an elastic multicloud infrastructure that provides app-centric and network-centric connectivity models. My organization has the full complement of network- and app-centric endpoints, and my connectivity options should reflect the same.
- I want cost agility AND operational agility based on deep visibility. Deep visibility allows me to build and enforce robust policies quickly and consistently across multiple regions and cloud environments and understand the traffic patterns/flows flowing to my various cloud accounts.
Understanding True Costs of a Spoke Gateway Approach...
Given the laser focus on cloud cost control, many organizations have begun seeking ISVs that offer cost-effective solutions with innovative services. With their wide range of connectivity, networking, performance, and security requirements, enterprises are familiar with the limitations of the native networking services provided by cloud providers. These are building blocks by design. Any ISV or self-designed and automated solution must not significantly increase its ballooning cloud costs.
Imagine having to upgrade several thousand appliances, patch them every time there is a bug, and worry about those half-alive tunnels / BGP sessions in an HA pair. Even if there is a management portal for this task, didn’t “enterprises” move to the cloud to avoid these challenges?
Unrealistic claims and scale challenges…
The picture shows a single region architecture for the ISV that leads with a spoke gateway model in every VPC. Multiply this by the number of regions and clouds an enterprise will have. This model substitutes or superimposes the CSP’s inherent connectivity framework with tunneled overlays that span multiple cloud environments. The claim is that the approach enables connectivity and security across multiple clouds and multicloud visibility.
However, it deviates from the cloud-native paradigm, necessitating L3 tunnels to attach to vendor transit and subsequent security measures across clouds. If you are wondering how this will even scale, the ISV answers in their configuration guide:
Any AWS/Azure Spoke gateways that you want to use in gateway scaling cannot have HPE, BGP, NAT, DNAT, SNAT, FQDN gateways, or Site2Cloud enabled
The recent claim of becoming NGFW by adding a network-based IDS engine worsens all of these further – first off, what use does a signature match provide when 99% of cloud traffic is encrypted? We will leave the genuine NGFW vendors or the security experts inside enterprises to debunk these security claims, now returning to the architecture topic. If an enterprise has to decrypt all VPC traffic on these VM appliances, the vendor has already provided the answer on the scale above. Essentially if an enterprise needs to run the features that the ISV layer promised to bring on top of cloud-native, they ask the enterprise not to expect any scale.
Debunking Costs Claims
Claiming to help eliminate high-cost services such as NAT gateway and eliminating data processing fees is not offset by the requirement to deploy a pair of spoke gateways in every VPC which contains application resources. This is a cost-prohibitive approach in almost all cases. Additionally, spoke gateways encrypt traffic from each VPC to their hub, which is a redundant service, mainly as most applications communicate using TLS. Instead, a cloud-native private link or AWS transit gateway(Transit Gateway (TGW)) can be leveraged for ingress networking to the hub.
Why should I pay an ISV for connectivity overlay when I already paid the CSP?
This architecture touts visibility and security to that particular overlay while other aspects are treated as add-ons. It represents a minimalistic approach that forces customers into a realm of compromises.
Common sinkhole...
| If you want to spin up a new workload and connect | There’s a VPC and spoke appliance for that. |
| Want to scale throughput up? | There’s a spoke appliance for that. |
| Overlapping CIDRs? | There’s a spoke appliance for that. |
| Want L3 security? | Yes, there is a spoke appliance for that (now branded as a pseudo firewall) |
| Want to reach PaaS services? | Wait |
| Want application-level segmentation and performance? | Wait |
| Want full-stack visibility(Not just layer 3) and insights? | Wait |
| Want to use a new cloud connectivity model from the CSP ? | Wait |
| Want to reduce (not shift) cost or reduce complexity? | Wait |
Cloud Native Approach
Doing it the right way
For the reasons above, most customers have realized that building on top of cloud primitives is the right bet when considering future-proofing their architectures.
A cloud-native architecture does not just connect “cloud-natively” ( there are no appliances or spoke tunnels needed in each VPC ); it is architected with cloud-native principles ( think elastic and fault-tolerant), connects all types of “cloud-native” endpoints ( applications, networks, PaaS services, serverless) and secures them at the appropriate layers (L3-L7). An ISV that delivers “all of the above” without penalizing the customer with a performance or an operational tax can be considered cloud-native.
Enterprises with the internal wherewithal might undertake a “do-it-yourself” approach to cloud adoption, but they soon cross multiple “chasms” in their cloud journey. Automation is presented as a panacea to navigating this multicloud complexity. While deployment speed is great initially, as the code base grows, the ability to introspect about your infrastructure and, therefore, to make changes and understand their impact reduces over time.
Full Stack from Prosimo
This is where Prosimo comes in. You can operate your infrastructure as IaC, with full-stack visibility, AI/ML-based insights into your infrastructure, and the ability to orchestrate your multicloud infrastructure using cloud-native constructs. All without the tradeoff tax or the additional overhead of maintaining spoke appliances. Prosimo reduces NAT gateway usage (over 50%), lowers egress costs, and eliminates spending on cloud-native services – Without paying this tax because it uses and intelligently orchestrates cloud-native alternatives from a regional point-of-view and extends them to the multicloud. You get operational agility, deployment agility, and cost agility.
What true cloud-native MCN delivers
| If you want to spin up a new workload, application, VPC, subnet, or Paas Endpoint- | Prosimo's got you covered |
| Want to scale throughput up? | Cloud-native scaling (up and down) with Prosimo. |
| Overlapping CIDRs? | Yes |
| Want full stack security and access policy (L3-L7) | Yes (Natively and with adaptive service insertion. Keep using your current firewall) |
| Want to reach PaaS services? | Yes, with Prosimo! |
| Want application-level segmentation and performance? | Yes, with Prosimo! |
| Want segmentation inside a VPC? | Yes, with Prosimo! |
| Want full-stack visibility(Not just layer 3) and insights? | Yes, with Prosimo! |
| Want to use a new cloud connectivity model such as CloudWAN? | Yes, and we’ll make it multicloud - that’s the Prosimo value-add |
| Want to reduce (not shift) cost or reduce complexity? | Actual cost reduction with Prosimo |
| No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services | |
| No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services | |
| No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services |
The Redefined MCN
No Trade-offs
Being cloud-native allows customers to free themselves from the world of unnecessary trade-offs. If your ISV claims to be cloud-native, you should be able to demand that all your business and architectural objectives are met. Deployment, operational, and cost agility are outcomes when Prosimo is the foundational bedrock of your cloud-native infrastructure.
