Outlier or Leader? Learning from Google’s Andromeda SDN

A bit like how physics breaks down when you start talking about the supermassive black holes, all the conventional wisdom about best practices regarding SDN deployment goes out the window when you start talking about the outliers of the biggest companies.

There’s a very good reason that “Google” was named after a really big number.

Google, and companies like them (Amazon, Microsoft, etc.) who have super-large, complex network infrastructures, face challenges that 99.99% of enterprises will never have. It makes financial sense for them to invest in custom technologies to address their unique challenges and give them competitive advantages. Not surprisingly then, their SDN deployments are full of unique, in-house solutions to unique, in-house problems.

Google’s SDN is codenamed Andromeda, and not only is it used with Google’s own servers but also in two zones of Google’s IaaS, Compute Engine.

As Google’s Cloud Platform Blog states, its virtual network has to compete with the physical network when it comes to performance, availability, and security. This has to be done “across virtual machines, hypervisors, operating systems, network interface cards, top of rack switches, fabric switches, border routers, and even our network peering edge.”

A daunting task, yes, but one advantage Google has because Andromeda is home-grown, is complete programmable control over the entire network stack. Most SDN deployments do not, allowing for programmable interoperability only at certain insertion points in the stack and thereby limiting control.

Stepping away from IaaS for a moment, across the board, Google is leveraging virtual networks for greater flexibility and scale. A DDoS attack, for example, targets fixed weak points in network infrastructure. With virtualized networks, there are no “fixed targets,” and, in short, the network can interpret a DDoS attack as damage and attempt to route around it.

Solutions like Google’s will see earlier adoption by service providers than enterprises. Software defined networking is all about smart bandwidth allocation, meaning more flexibility, easier scalability, and infrastructure cost leverage. When clients/applications have unexpected moments of massive demands, SDN will help maintain higher uptimes and efficiencies.

Companies will have to leverage their expertise to make it work – and moving to an SDN will require lots of pre- and post-install work to iron out the kinks in incorporating it to legacy networks. That’s where having real-time visibility into network routing and traffic behavior comes in. However, though it may be big and an early adopter, Google has shown that it can be done. The question for everyone else is: When?