While working with many enterprises, one requirement I often get during the engagement is Prosimo’s ability to seamlessly integrate with their existing cloud infrastructure and ease of deployment in a brownfield environment. In this blog, we will not dive deep into the platform architecture but focus on deploying and integrating Prosimo with an existing cloud networking environment with zero to minimal downtime.
Brownfield Cloud Networking Challenges from Customers
Let me try to summarize some challenges that customers have brought up
- We already have our production network built out in the cloud. What steps would be involved in bringing and integrating a new solution into our existing production network?
- How well does Prosimo integrate with native networking constructs like AWS Transit Gateway, Azure VWAN, Private Links, Peerings, etc? We were considering another solution a few months back, but they wanted us to rip apart our existing Production network and build their overlay tunnels everywhere.
- We have multiple production networks (VPCs/VNets, VCNs, etc.) that cannot be migrated all at once due to certain workflow constraints. Can we phase out our deployment to cause minimal disruption to our production, staging, and shared services environment using Prosimo? How will the connectivity be maintained between newly migrated and non-migrated assets during this transition, and will overlay tunnels need to be established to maintain this connectivity?
- Who will update and propagate route tables in VPC/TGW/VWAN Route tables across our production environment?
- Will migrating to Prosimo impact our existing hybrid connectivity between the cloud and on-premises? Would we have to re-establish it?
Key requirements to deploy in brownfield setups
These questions are important and valid, given Prosimo’s focus as a connectivity platform. Additionally, not just Prosimo but, when deploying any cloud connectivity solution, it’s crucial that it excels in the following key areas:
- Integrates seamlessly with existing enterprise networking environment. It should not be disruptive to integrate it
- Integrates with cloud-native networking constructs without causing any disruption
- Has the ability to orchestrate cloud-native networking constructs and build automated connectivity
- Handles automated route propagation across the environment and handles route table upgrades
- Has the built-in ability to do network and application segmentation. Ability to apply the policy in a centralized way
- Gives end-to-end visibility and network and application layer
- Should have the ability to do all the things mentioned above consistently across multi-cloud and hybrid-cloud environments
Why Prosimo Fullstack Transit does not disrupt environments
Prosimo offers a full-stack Transit platform that enables the communication between different types of endpoints. These endpoints could be VPCs/VNets, IPs, FQDNs, APIs, or PaaS services. Prosimo establishes service-to-service communication between these endpoints with the right context and authorization policies at various layers (5-Tuple network policy or X.509 certificates, mTLS, etc), and provides application layer visibility for every HTTP/s transactions (GET/POST methods) or TCP/UDP layer insights (port, protocol).
Prosmo’s full stack platform has two main architectural components. 1.) A SaaS based control plane. 2.) A datapath component called Prosimo Edge that is deployed in customers’ own cloud (AWS/Azure/GCP/Private) account, thus giving customers complete control of their network datapath.
If you first want to dive deep into the platform architecture, please visit https://www.prosimo.io for more information.
Seamless Layer 3 Networking that's different
Let us take a simple architecture to discuss and understand Prosimo’s approach. In this example, we will only focus on one Network Transit functionality of Prosimo’s Fullstack Transit platform. However, this approach is equally applicable while building Service to Service connectivity using Prosimo.
Diagram 1 (Existing Architecture)
In the architecture shown above in Diagram 1, we have an existing network deployment with 2 regions in AWS. The VPCs across these 2 regions are connected to each other using Transit Gateway Peering. Both regions are connected to the on-premises environment using AWS Direct Connect.
The below diagram shows the existing connectivity between the 2 cloud regions.
3 Steps is all it takes with Prosimo
- Deploy Prosimo Edges in both the AWS regions shown in Diagram 1: us-west-2 and eu-central-1.
- Onboard one network each in the us-west-2 region to Prosimo Dashboard. While onboarding the network, you can choose from one of the several cloud-native networking constructs (AWS VPC Peering, Transit Gateway, Azure VWAN, VNet Peering, Private Link) to connect your VPC/VNet to Prosimo Edge VPC/VNet. In this example, we will choose AWS Transit Gateway to connect the VPCs to Prosimo Edge. Prosimo automatically discovers the existing Transit Gateways in the given Cloud Account
- Apply the appropriate security policy and onboard the network
During the network onboarding, whats happening under the hood?
- Prosimo orchestrates a VPC attachment to attach Prosimo Edge VPC to the same Transit Gateway chosen in the previous step. This allows Prosimo to integrate seamlessly with existing networking constructs
- While onboarding the network, Prosimo creates two new Transit Gateway Route Tables: Edge Route Table and App Route Table. Edge Transit Gateway Route Table is used to associate the Prosimo Edge VPC attachment with the Transit Gateway. The App Route Table is used to associate the New VPC that we are trying to onboard as a part of network onboarding. At this step, Prosimo will disassociate the VPC attachment from the current Transit Gateway Route Table and associate it with the new App Route Table. Please note that during onboarding, Prosimo does not delete and recreate the Transit Gateway attachment (which is a more disruptive process). Rather Prosimo keeps the existing Transit Gateway attachment and just reassociates the attachment to Prosimo created App Transit Gateway Route Table. This ensures minimal downtime
- Prosimo also updates the VPC and Transit Gateway Route Tables with appropriate route entries to enable communication between the onboarded Networks. As we keep onboarding networks, Prosimo will keep updating all the Route Tables to ensure Network Correctness. Prosimo also removes the routes once the networks are offboarded.
Diagram 4 (VPC Route Table before the Onboarding)
Diagram 5 (Transit Gateway Route Table before the Onboarding)
Diagram 6 (VPC Route Table after the onboarding. Prosimo updated the VPC Route Table with the appropriate routes)
Diagram 7 (Transit Gateway Route Table after the Onboarding. Prosimo updated the TGW Route Table with the appropriate routes)
The end result
It is essential to mention that with this approach, the newly onboarded assets can still communicate with other non-onboarded assets (either in the cloud or on-premises) without making any changes to underlying connectivity. This gives enterprises the flexibility to do phased migration based on their business and technical constraints.
Diagram 8 (End State Architecture with Prosimo)
For example, the screenshot below shows that the onboarded network (192.168.2.0/24) from our architecture diagram can still talk to one of the non-onboarded networks (192.168.3.0/24) without making any changes to the underlying network connectivity.
In Summary, with Prosimo’s seamless integration into existing production systems, compatibility with cloud networking constructs, and support for phased deployment, enterprises can effortlessly implement Prosimo in their existing infrastructure. It is straightforward and takes 30 mins to spin up a quick trial and explore the capabilities of Prosimo and how it helps provide a consistent layer of connectivity, and segmentation across multi-cloud with visibility and insights.
