SDN secrets of Amazon and Google

Those seriously considering SDN (software-defined networking) must continually adjust to the new definitions, technologies, and possibilities presented by this fundamental shift in networking technology. Everyone would like a clearer view of where SDN is heading — so why not examine what the early adopters are doing, many of them with the largest infrastructures around?

In this week’s New Tech Forum, Chloe Ma, director at Juniper Networks, takes us on a tour of how massive-scale service providers are using SDN, all the way from Amazon Web Services to Google’s software-defined WAN technologies. –Paul Venezia

What enterprises can learn about SDN from providers For the last year or so, SDN has been the buzz of the networking world, and for good reason: SDN is transforming the industry. As with any emerging technology, there’s room for debate. There have been lively disputes over SDN’s definition, emerging protocols, the viability of various vendor approaches, and so on.

One thing has remained constant: The need for enterprises to build an elastic infrastructure that empowers today’s dynamic business applications. Leading cloud providers, such as Google and Amazon, are on the forefront of this trend, using SDN to efficiently build private, public, and hybrid clouds to increase application-deployment agility and better respond to business needs.

These early adopters lead the movement toward dynamic applications in large-scale, multi-tenanted environments. Many started their SDN journeys either by assembling or developing in-house technologies that can orchestrate and automate not only compute and storage resources, but also networking resources to enable application control of infrastructure or ITaaS (IT as a service). Today’s enterprises can learn much from Web 2.0 companies’ early experiences with SDN and cloud environments, including three key technological advancements that will enable them to achieve business agility while maintaining security and regulatory compliance.

IT as a service Enterprises are under increasing pressure to develop and deploy dynamic applications to generate new revenue streams and respond to changing business climates. This need shows up in two distinct ways: The first is the scale of the application, which can expand and shrink significantly based on application workloads. The second occurs during the continued development of an application, wherein enterprises need to add new features quickly and push updates to meet a rapid pace of innovation and avoid falling behind.

The traditional operational model of filing a support ticket and waiting weeks to get the resources needed to run an application is a roadblock to business agility. To get around this problem, LOB (line of business) managers and others inside the enterprise turn to alternatives like AWS, where they can provision resources instantly with a swipe of a credit card.

Enterprise IT can learn from the model offered by AWS and others — and transform itself from a cost center to a business enabler by supporting ITaaS operational models. To do that effectively over the long haul, however, the infrastructure must include SDN capabilities.

One of the advantages of AWS is the ability to massively scale EC2 (Elastic Compute Cloud) with nearly hands-free automation. Although Amazon has always been very private about how it does this, popular belief is that the company’s substantially customized version of the Xen Project hypervisor likely has implemented a form of SDN for quite some time. Capabilities like AWS CloudFormation, security zones, Elastic Load Balancing, and others have clearly shown that much of what used to be implemented via network hardware is now implemented through a software stack. With its VPC (Virtual Private Cloud) offering, AWS has provided strong network isolation, including overlapping IP ranges, which are implemented with a software overlay on top of a networking hardware stack. There’s little argument that this has been a huge differentiator for AWS, enabling not only massive scale but also a steady stream of price cuts for customers.

The key lesson is there can’t be true ITaaS without SDN. All resources, including compute, storage, networking, and security services, must be abstracted and treated as a pool of resources. The different sets of virtualized resources and test-and-verified building blocks can be combined, deployed, programmed, and monitored by the applications that are using them. This allows enterprise users to quickly access the resources they need to run applications or perform other business tasks, with the security and isolation their companies demand.

SDN service chaining Once organizations adopt ITaaS or cloud models, they inevitably need to support dynamic creation, insertion, and scaling of network and security services. For example, in a private cloud environment, employees can spin up virtual machines to run their multi-tier applications — and they need load-balancing or firewall services between the different tiers. This approach makes sense only when the infrastructure can automate the orchestration of services along with other resources.

Again, take AWS as an example. Amazon makes various network and security services, such as firewalls, load balancing, and CDN (through CloudFront) services available on top of its infrastructure. These services can be spun up to run on EC2 virtual machines on a per-tenant basis to accommodate self-service, service selection, and insertion.

Borrowing from AWS, a private-enterprise cloud needs to be an elastic platform that allows dynamic service insertion, wherein services are extracted from special-purpose hardware appliances and run as virtual instances over a standard compute platform. These services, often security or L4-7 network services, can scale on demand and be dynamically inserted into traffic flows to function at a more granular level.

Intercloud federation For the increasing number of enterprises that adopt a hybrid cloud or operate multiple data centers across a wide geography, it’s extremely important to have smooth workload movement across multiple clouds for disaster recovery and high availability.

For example, companies like Google and Amazon operate multiple data centers across the world. Due to the increased use of mobile devices, a user request can potentially trigger compute or storage operations in any of the data centers. In addition, the adoption of big data analytics tools, such as BigTable and Hadoop, can dramatically increase advertisement relevancy but result in significant east-west traffic increase within and across data centers.

Google and Amazon have been building technologies like intercloud federation and software-defined WANs to support their global operations with flexibility and high availability. Intercloud federation handles the exchange of routing and control information across multiple cloud environments — along with the network connecting these environments — so an entity in one cloud can seamlessly communicate with another entity in a different cloud.

AWS has been supporting deployments of multiple VPCs (virtual private clouds) connected to customer sites. If enterprises are considering setting up a hybrid cloud and move workloads across public and private clouds securely, they can take a page from Amazon’s playbook: Design a well-thought-out approach to seamlessly translate virtual identifiers inside a data center — such as VXLAN ID to VRF (virtual routing and forwarding) instances, since VPNs are the preferred approach for intercloud connections.

Of course, WAN bandwidth is scarcer than bandwidth inside a data center, so enterprises must ensure they can differentiate among different types of traffic and maintain SLAs (service-level agreements). To that end, Google has pioneered a software-defined WAN in its B4 network to use logically centralized network control for more deterministic, efficient, and fault-tolerant connections across the WAN.

Google’s WAN has two backbones: One is called I-Scale for Internet user traffic that is usually smooth and diurnal, requiring high availability and loss sensitivity. The other backbone is called G-Scale for data center internal traffic that is bulky but can tolerate higher loss and has less stringent high-availability requirements. G-Scale handles most of the east-west traffic that is growing at a much higher speed than the north-south user traffic handled by I-Scale. Google implemented B4 to have a logically centralized traffic-engineering controller, which allows applications to manipulate bandwidth across data centers through WAN networks.

Although the early SDN products primarily focus on automation and orchestration within a data center, the more mature SDN solutions, such as those from Google and Amazon, are designed to take intercloud federation across WAN and software-defined WAN into consideration. Looking to the service-provider world, BGP, MPLS, and L3VPN/EVPN are the dominant and proven technologies that can scale, isolate, and guarantee SLA. This dictates that a translation scheme needs to be well thought out to map the tenant identifiers inside a data center to MPLS labels to go through the WAN.

Cloud providers have been on the forefront of the SDN movement and will continue to pioneer new and novel approaches with the emerging technology. Enterprises can borrow the lessons learned by these companies to build a more agile, dynamic, and elastic IT infrastructure — one that will provide an edge in an increasingly competitive world.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

This article, “SDN secrets of Amazon and Google,” was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.