The cloud has changed my life. I think about all the old ways that I used to try and use applications and laugh now because they’re so outdated. Like only being able to use an application if I were VPNed into a server. Or worrying that an application isn’t going to be available because there was no place to put it to ensure that it would be up all the time. Or crying because a high traffic load meant that a service was offline because load sharing is hard.
The cloud has helped us overcome many challenges when it comes to providing stable, available applications. But it’s not always due to the underlying network. In fact, knowing as much as I do about networking makes me astonished some days because I know how hard it is for networking to overcome the challenges of modern applications. It’s not easy to leverage protocols to make Netflix work in all corners of the globe and available all the time to anyone that wants to use it. Add in the fact that it needs to be fast and you have a recipe for headaches.
Why is that? Why do applications have a stilted view of the network? Why is it so awkward to make them work the way we want them to? Is it because of the application developers? Is it because software is unable to cope with the way networks operate? Or is it because of the way that we’ve forced software to develop because of our network architecture?
We no longer live in a world of dial-up and ISDN. The idea of having devices that are not constantly connected to the Internet is quaint at best. Yet many of our traditional networking architectures are based around those ideas. Maybe not all the way back to the bygone days of serial WAN connections and ATM switches but we do have a lot of “old” thinking in networking. And that thinking is holding back a lot of the progress that could have been made over the years if only we’d have been willing to dump the old and get with the new.
If you’ve been reading my writing here, you know that I’ve talked to Arrcus quite a few times in the past. They’ve been making a lot of waves in the network operating system (NOS) market specifically because they aren’t thinking in the same way that everyone else has been. They’ve already gotten a Series B funding round and they’re just getting started.
Arrcus decided at the beginning to toss out all the stuff that doesn’t matter. It’s a bold move that has paid off quite a bit for them. Modern NOSes run the risk of becoming bloated over time. Code is continually added to the code base and left there in the hopes that someone one day might actually need to use it. As mentioned before, we don’t live in a world of remote access modems in BRI diaper profiles any longer. So why would that code need to exist in a device that doesn’t even have serial ports?
Arrcus instead has said that it’s time to build modern architectures with modern software needs. And by ditching the old protocols and commands, they’ve created the perfect solution to application development issues. Instead of creating workarounds for software developers to be able to keep a function working for another few months, Arrcus has presented developers with a solution that works the way things should be working. Now, when you call the networking stack you’re not going to get back a cockamamie solution that doesn’t actually fix your issue.
My favorite one of these problems is layer 2 data center interconnect. L2 DCI exists because virtual machine migration has to happen at layer 2 to preserve IP address space. Applications running the those VMs can’t fathom a way to request a new IP address. Traffic destined for that host needs to be sent to the correct location and if the IP address didn’t change then you have to have some kind of layer 2 connectivity to resolve the ARP request for the new device. It worked great fifteen years ago when routing was hard and expensive. But with the advent of technologies like Broadcom Jericho 2, why are we still switching?
Those are the kinds of questions that Arrcus has asked themselves. And their solution is to embrace Jericho 2 and write a networking stack that can route just as well as switch. And the focus on routing means that everything works in the cloud the way you would expect. They’ve even built in additional telemetry and analytics from their ArcIQ functionality, which is demonstrated to great effect in this video:
The idea that you can have the ability to make workload mobile and also track it across the network so you know where it’s living right now? That’s genius. And the idea that it’s so genius is sad because that’s something we should have had for a long time. It just took someone willing to restructure their OS to get rid of the cruft that we didn’t need to help them focus on what we should have had.
Bringing It All Together
Arrcus is on the right track when it comes to fixing network architecture. Anyone building a cloud-enabled network with an OS that thinks about frame relay and dialer maps is going to be in for a rude awakening. Rather than carrying forward this idea of operating system debt, you need to focus your next network refresh on a solution that thinks in modern times.
For more information about Arrcus and their ArcOS and ArcIQ solutions, make sure to check out their website at http://Arrcus.com.
- Predicting Data Patterns with Cradlepoint - January 16, 2020
- How Do RFC3161 Timestamps Work? - January 15, 2020
- Testing the Whole System with NetAlly EtherScope nXG - January 14, 2020
- Stupid Network Tricks - January 14, 2020
- There Is No Layer-2 in Public Cloud - January 8, 2020
- Assuring Your Service Level with Ixia IxProbe - January 8, 2020
- Wi-Fi and the Netflix Effect - December 27, 2019
- Figure Out What Problem You’re Trying to Solve - December 20, 2019
- Ensuring Unified Communications Success with NETSCOUT - December 19, 2019
- Network Stability Through Resilience Engineering - December 18, 2019