Connecting Cloud Providers
If your organization is using cloud hosted services today, there’s a good chance that you’re using more than one provider. Sometimes this is because a single cloud provider is missing important products or services so some mixing and matching is required. In other cases, the motivation is cost driven because some providers have more competitive pricing. Other organizations may bring another cloud provider into the fold to reduce their dependence on a single provider.
No matter the reason that necessitates a multi-cloud or hybrid setup, the networking challenges that are associated with it are almost always the same. Instances in each cloud provider are typically in their own private network and can’t see each other (let alone communicate) without significant routing or firewall configurations. Each instance essentially lives in a silo without any interconnection. If the instances do get bridged, it’s an entirely different challenge to make sure that communication is secure and safe from attacks such as eavesdropping or man in the middle.
Multi-Cloud setups are increasingly popular, though, so people have certainly tried to tackle some of these issues. If there are sufficient resources, some teams spin up NAT’s or VPNs to try and bridge each network, but that means there’s one more service to configure and maintain and yet another point of failure. VPNs, created for the age of static data centers, rather than the elastic topologies that cloud hosting enables, don’t always scale well depending on how many different sites are being bridged. Additionally, if your VPN setup funnels all traffic through a single corporate headquarters as many do today, then there could also be extra latency involved as traffic is forced through an extra hop. All of these solutions typically require additional hardware or complex configuration changes. Some cloud providers like AWS offer their own solutions like DirectConnect, but these all come at an additional cost.
A more recent trend to abstract away the underlying cloud architecture that an app or service runs on is the rise of containers. Kubernetes, for example, is a popular solution, but it still suffers from networking challenges. Istio is a service mesh for Kubernetes to streamline inter-service communication, but it was developed at higher layers of the networking stack and is only now adding support for low-level traffic.
Even with these challenges, multi-cloud deployments are only going to become more popular so there needs to be a better solution for connecting instances across cloud providers. The Marconi Protocol offers a simple software based solution for bridging cloud providers into a flat network where each node can securely peer with every other node in the network, regardless of geographic location, cloud provider, or even whether it’s a shared/dedicated/container instance. It’s now possible to create and manage an overlay network that is completely agnostic of the underlying network architecture. Additionally, each Marconi Network has a built in DHCP service which creates a private IP address for each node in the network to peer as if they are sitting right next to each other in the same data center. Marconi’s support for mesh networking enables peer to peer connections to minimize latency and all communication is secured end to end which eliminates the need for a separate VPN.
Stay tuned as our Developer Test Net will launch soon.
