Cloud computing is nothing short of miraculous. It allows us to store, scale and send infinite amounts data with millisecond latency, do away with the costly “racking and stacking” of servers, and offers quick continuity in the face of disasters.
When it comes to moving high-bandwidth workloads from an on-premises network into the cloud, however, things start feeling a little less heaven-sent.
In this piece, we take you through the challenges that come with on-premises-to-cloud and cloud-to-cloud migration for critical infrastructure and high-throughput workflows, why those problems happen, and the solutions available for solving them.
Bringing on-premises performance capability to cloud networks has long been thought to be impossible. Not only is it possible, we’re here to help you learn how.
Bridging high-bandwidth workflows from ground to cloud
High-bandwidth workloads and critical infrastructure systems are found across markets. They include the sending and editing of real-time video by broadcasters for live global coverage of events like the World Cup, the management of sensors and automation systems by the industrial, manufacturing, and defense sectors, and IoT (Internet of Things) networks relied on by smart cities, hospitals and government facilities.
Because these vital workloads store and move vast amounts of data at high speeds, developers often use on-premises networks to handle them. In designing a physical network from off-the-shelf components, users can take advantage of high-performance network switches, routers and network interface controllers (NICs) to implement high-performance features that are compliant with industry standards.
Cloud networks, however, remain an attractive option for many reasons. They can be more cost-effective than using on-premises systems, have faster responsiveness, flexibility and scale, and make it possible for workers to remotely manage systems from anywhere in the world. Recent supply chain issues have also hindered developers ability to quickly expand data center capacity, making the cloud even more of a draw.
But bridging these high-bandwidth workloads from ground to cloud, while maintaining bare-metal on-premises performance, has historically been difficult. There is bridging software, or router hubs, available on the market for on-premises-to-cloud migrations, but the developers using them are at the mercy of whatever performance or specialty features that software provides. The systems they so thoroughly tailored on-premises to support performance become moot.
This obviously isn’t ideal, since, to nail moving data to the cloud, you’ll need sufficient performance.
Ground to cloud and cloud to cloud migration strategy
There’s still hope for developers looking for ground-to-cloud and cloud-to-cloud solutions. swXtch.io’s cloudSwXtch platform offers easy solutions for overcoming these limitations.
First, cloudSwXtch goes around the operating system kernels, moving the packets past the operating system directly into the applications and getting rid of the performance barrier.
Next, the platform directly connects to the network interface controllers on the cloud network using a technique called SR-IOV, or single root input/output virtualization. This provides the switch direct access to the network components that are part of the cloud network, allowing it to support performance through the entire bridge back to the on-premises network.
The platform does this by building a single common data plane between the on-premises network, across the link and into the cloud using the highest possible performance methods via the operating system bypass techniques and the direct connections to the network interface controllers. This gets data across the links much faster, creating performance that is analogous to what is possible in an on-prem network, and represents the highest possible performance that the cloud can provide.
Now that cloudSwXtch has solved for performance in terms of latency, bandwidth and packet loss, it next needs to get network data into the cloud to ensure the cloud is compatible and supports the packet types or protocols the developer is using.
Protocol fanout in the cloud with ground cloud services
Some applications used by financial services, media and other sectors require different network protocols than what clouds support natively, and one of the most common unsupported protocols is multicast.
Because cloudSwXtch implements a high-performance virtual overlay network, it makes these protocols, including multicast, available in the cloud network.
We do this by connecting the platform to the on-prem network so it understands the protocols the network is using. It then transports those protocols across the link into the cloud but hides the actual details of the protocol from the link and the cloud so they won't drop them as they normally would.
By tunneling this way, and obscuring the packet types, cloudSwXtch gives the cloud what it expects in terms of the packets that it knows how to transmit. When the packets get to the end point, it “unwraps” them and presents them to the application as quickly as possible in the format the application expects them to be in. This way, the application doesn't have to change, the cloud network doesn't have to change, the on-prem network doesn't have to change, and the link doesn't have to change.
Every component in this bridging process is accommodated by cloudSwXtch’s overlay architecture technique. In addition to multicast packets, we provide this same process for broadcast packets and a media protocol called SRT, or Secure Reliable Transport. The cloudSwXtch platform will also soon be available for other protocols like NDI, QUIC and TCP, among others.
Monitoring and bandwidth sizing
Providing troubleshooting capabilities are essential for nailing an on prem to cloud migration strategy. So after compatibility is addressed, we look at monitoring.
One of the biggest problems with trying to integrate on-prem and cloud networks is the loss of visibility each network is insulated in terms of how you can monitor the packet movement.
Protocol analyzers like Wireshark can help analyze the packet flows with on-premises networks, but developers are still limited by what feedback the cloud network will give them in terms of where packets are going and how they're getting there. But by putting the cloudSwXtch platform into the whole architecture, developers get a view of packet movements and losses analogously that allows complete packet capture and analysis.
Because link bandwidth is expensive, cloudSwXtch provides a unique capability to optimize bandwidth sizing, ensuring that only as much traffic is going across your link as possible.
To address this, we implement dynamic bridging.
A use case for dynamic cloud bridging
Smart cities use sensors, cameras or IoT devices to monitor traffic patterns or road conditions. Let’s say, for example, that thousands of traffic camera feeds get collected in an on-prem data center and developers want to move that video into the cloud so that they can monitor them remotely. Viewers will never need to monitor all of the thousands of feeds simultaneously but will still need flexible access to any of the feeds in real time. To enable that, developers won’t want to pull all of the camera feeds across the link at the same time, because the amount of network traffic would require provisioning a link that is far too large for the viewing requirement. It won’t work.
Our dynamic bridge only moves the actual video traffic across the link being requested at that moment by viewing applications. There might be 10 people analyzing a handful of those camera streams at any one time, representing a very small percentage of the live feeds available on the network.
cloudSwXtch dynamically changes that on the fly. If the viewer cuts off one stream to look at another, it won’t move that network traffic across the bridge, optimizing the bridge bandwidth.
Dynamic bridging can be used in any situation where you don't want to over-provision your link to account for a “worst case” scenario, like those hypothetical thousands of camera streams at once, that would be better addressed by dynamic filtering of the packets. This is a unique feature and can provide support to resources across sectors, like market data feeds used by financial services.
Any on-premises networks with enormous scale, performance requirements and extreme up-time requirements can benefit from using the platform.
Cloud-to-cloud migration strategy
cloudSwXtch also works for nailing cloud-to-cloud (or ground-to-multiple clouds) migration. If you’re looking for a variety of best-of-breed cloud solutions, this might mean working on AWS, Azure, Google Cloud, or Oracle Cloud which all offer their own specialized advantages. It’s also common for developers to use multiple clouds for disaster recovery or high availability, so they’re not dependent on a single service for mission-critical infrastructure.
Hybrid clouds are also becoming increasingly popular for offering similar benefits to multi-cloud, but, with either, developers will still have to to account for the compatibility differences between products like AWS, Azure and Google.
cloudSwXtch accounts for the networking differences between clouds that may affect how workloads are deployed. The platform does this by normalizing any performance differences to ensure the cloud networks behave the same fundamentally when the platform is sitting atop them so that developers don’t have to worry about how to provision their networks differently on the different clouds.
This is done using a high availability configuration, which is how parallel redundant network paths are constructed so that a source can create one stream of packets. Our platform’s architecture will split them into multiple streams, automatically move them down different configurable routes, including across different clouds, and then reconverge them at the end and de-duplicate them by the endpoint application. If one of the network paths is impaired, the endpoint application doesn't even know it. The cloudSwXtch network repairs the data stream on a packet-by-packet basis, using packets from any available path.
Even if there's not a need for redundancy and developers simply want to use different clouds for different reasons unrelated to high availability, cloudSwXtch can move packets across cloud networks such that they look like one giant network or data plane, so you can get all the metrics that you want about your entire network from one source.
Cloud migration services, simplified
cloudSwXtch offers a monitoring tool as well as an API, which allows customers who have their own monitoring systems to integrate our metrics into their monitoring systems or dashboards.
Single Metric View
We also provide metrics on how packets move across networks. By aggregating the packets above the virtualization layer to make them visible, users will know how they traversed the network. In the case where a developer has multiple clouds connected, cloudSwXtch would give them a single data plane view across the clouds and physical networks.
cloudSwXtch does all of this with ease, simplicity and no code changes. Typically, on-prem to cloud and cloud to cloud migrations can take weeks of learning, reading technical support blogs, and testing. The software and integrations across links are technical, difficult and require time and resources.
For years, developers have had to design their systems with compromise to account for the absence of the migration capabilities cloudSwXtch offers. As engineers ourselves, we believe developers should be able to design their systems as intelligently and uniquely as their workloads require, all via a simple deployment method and a simple provisioning method.
Let us handle the hard networking stuff for you, so you can do more with less and focus on nailing your migrations every time.
To request more information about how swXtch.io brings on-premises network feature parity to the cloud, please visit www.swxtch.io/contact.