Isn’t It Time We Had Truly Open Networks? For Real?
There’s been an explosion of innovation in data center networking in recent years including SDN software controllers: White-box switches, tools for melding corporate-owned networks with public cloud services from Amazon and others. Yet according to Gartner Inc., only a few hundred companies have begun to actually change the way they build and run their networks.
At SnapRoute, we think a major reason is the lack of a fundamental missing ingredient: a truly open software standard for basic switches and routers (a layer 2 and 3 protocol stack, for you wonks out there). Despite various efforts over the years, engineers still have to rely on software provided by OEMs to operate and troubleshoot their products. If you want to monitor network traffic patterns in a way those tools don’t support, you can request a new feature, and then wait for months, years or forever. When bugs appear—as they always will—you can make the necessary angry phone calls and pray the fix arrives quickly. Hopefully, it does before you are fired for a revenue-sucking, brand-killing network outage.
There’s a better way, and we all know what it is: open-source. For nearly twenty years, corporate IT shops have used Linux to build, monitor and troubleshoot their servers. Many of them use open-source databases such as MySQL and MongoDB instead of Oracle. Big Data has become a buzzword because companies had their choice of tools built on the open-source Hadoop technology. More recently, many a company has replaced proprietary storage gear with systems based on open standards.
Of course, these companies do their best to hold off their day of reckoning. All argue that their products do jobs that are far too important and complex to trust to open source communities. Somehow, networking companies have been able to maintain their grip. And who can blame them? So long as they control your ability to run your network, they can command higher prices. No wonder the top tier companies still make 60 percent margins on their networking gear, more than twice those of Linux servers.
We didn’t create SnapRoute to take a bite out of anyone’s profits. Rather, our goal is to free talented network engineers to do their job to the best of their ability, unconstrained by vendor lock-in. We think—no, we know—that this could accelerate innovation and reduce costs for thousands of companies.
Our founding team has a combined 30 years of experience building and running some of the most complex enterprise networks in the world. including more than a decade at IBM, helping Fortune 20 companies build their networks.
As SnapRoute’s founder, I’m not ashamed to admit a dirty little secret, which won’t come as a surprise to many network operations executives. My rise up the ladder had less to do with my own technical accomplishments and more to do with my ability to get vendors’ to tend to my needs, pronto. I built a rep as a hired gun that can get things done when really my greatest skill was knowing who to call and what to say to get support from Cisco or another vendor. It was a great gig while it lasted. I didn’t even have to write a business case. Sure, vendors had their faults, but at the end of the day, they had my back.
But it didn’t last. Internet services and traffic proliferated, creating once unimaginable layers of complexity. Rather than an outage or two every year, companies began getting hit every quarter, and then, every month. I started getting called to the principal’s office by higher-ups and chastised for network problems I lacked the tools to resolve. The bugs, upgrades, and other issues were coming too fast, and the stakes of delays too great. After a while, my personal reputation began being called into question.
Then I landed a job at Apple, where I had a ringside seat on one of the challenging network expansions in history. When I arrived in 2011, Apple had two data centers, mostly handling internal traffic and doling out songs and apps from the iTunes music store. By the time we left, Apple had several more centers stuffed with an incredible amount of network devices to handle billions of Siri and Map queries, iMessages and cloud services.
It was thrilling—and terrifying. When even one percent of Apple’s traffic gets stalled, it’s front-page news. And all too often, we were dealing with problems our vendors had never contemplated, much less figured out. We began exploring radically new approaches, including a handful of supposedly open-sourced solutions so we could dive into the guts of our network ourselves—say, to look directly at the data coming off network processors. As much as we wanted these technologies to work, they didn’t. So we developed some of our own, including a provisioning tool for upgrading the software on thousands of switches without taking the network offline. If you haven’t heard, Apple likes to keep such internal accomplishments to itself, so I can’t share the results. Let’s just say we were able to accomplish in minutes what would have taken hours, days or even weeks.
Slowly, our desire to share our ideas with the world began to overshadow the thrill and pride of working for Apple. My team and I left in 2015. Truth be told, I spent a few days crying on the couch. My mood only improved when we began to test our ideas with potential customers. Quickly, we knew we were onto something, assuming we could execute. Large cloud providers and companies in retail, financial services, and other sectors said they were struggling with many of the operational obstacles we had begun to address.
There’s a broader context behind this pent-up interest. After years of understandable excitement about the public cloud, many large companies are realizing they need to continue to build some of their own infrastructure if they are to remain innovation leaders. After all, even incredible companies like Amazon, Google and Microsoft can’t put every customer’s specific requirements on top of their to-do lists. Nor should they, if they want to maximize profits. Our belief is that as public cloud infrastructure becomes commonplace, companies will realize they need to develop their own secret sauce if they are to have an IT advantage over their competitors. Otherwise, they’ll be as constrained by their cloud provider as they have been by their proprietary equipment suppliers. As Roger Daltrey might say, “Meet the new boss. Same as the old boss.”
Fortunately or unfortunately—I choose to believe the former—we are not the only company to recognize this need. Last year, Dell announced an open network operating system initiative and partnerships with startups such as Cumulus Networks that provide some of what we aim to do. In the last few months, HP and Microsoft have made similar announcements.
We believe our approach will stand out for a few reasons. For starters, many current efforts have attempted to build the networking stack into Linux. We do not believe this will work for the sophisticated infrastructure big companies need. Network switches and routers are simply not servers. Network operators need purpose-built networking software. When we say open source, we mean it. At Apple, we ran into a number of vendors that were masquerading as open-source companies. But while they may have used (and contributed) open source code, the products themselves were proprietary and closed.
The biggest near-term challenge is to begin building an ecosystem of partners, customers, and distributors for FlexSwitch. We’re off to a good start. The OPS Project recently announced that it will offer FlexSwitch as an option for the OpenSwitch network operating system, created last year. Stay tuned for more announcements with suppliers of network chips and other components, cloud providers and early customers. We also plan to contribute our code to Facebook’s Open Compute Program, so that customers can use it in white box hardware built to these specs.
We do not have any illusions that we will take the market by storm, nor do we profess to be the next “Cisco killer.” In fact, we believe that most companies—certainly ones without much in-house technical staff, or relatively static network needs—are better off staying with established suppliers with battle-tested proprietary technology. Rather, we plan to proceed with humility and an operational-minded pragmatism to build an ecosystem to help companies who want to use Internet infrastructure as a competitive advantage.