Software Defined Networking requires a big change, so think carefully before jumping in
Making the leap to SDN? Don't jump in blind. It helps to know what software-defined networking is, first off, and then what it can do for you.
Then it's smart to know all the inner workings of an SDN controller, the differences between products offered by established vendors and start-ups, and whether open source and bare metal switching might be an option. Lastly, learn your own network -- will it even support SDN or require a wholesale rip-and-replace? -- and then learn from your peers about their experiences. Here's an 11-tip guide on how to prep for SDNs:
1) Educate yourself on it: Many organisations still do not know what software-defined networking is, what it's comprised of, and how they might benefit from it. It's obvious, but familiarity is the first step to understanding how SDN can help or hinder your enterprise network. Google, Facebook, Yahoo and Amazon Web Services regularly tout the benefits and steer the standards work, but those organisation are not the mainstream; they are on the bleeding edge of everything in compute and networking. Read up on the various flavors and iterations of SDN, what's new, what's old, etc. You may even come up with your own definition.
2) Know what you want to do: Goldman Sachs wants open standards, commodity scale architectures, independent and programmatic data and control planes, virtualised Layer 4-7 services, merchant this, open source that... Pretty much the whole ball of wax across all of its networks. SDN was targeted initially at the data center but now the enterprise WAN is a prime focus for the automation and orchestration benefits of SDN. Do you want a centralised or distributed control plane? Why or why not? Some of the more compelling SDN applications are analytics and packet monitoring -- TAP -- due to SDN's ability to rapidly steer traffic with just a few mouse clicks. Orchestrating and automating the network through software can save on capital and operational expenses as well, proponents say. Determine what your goal or objective is with SDN and implement accordingly, yet prudently, gradually.
3) Consider security implications: Centralising all control of the SDN may make life easier for the network operator; but it may also offer a single point of catastrophic failure or attack for a hacker or malicious content. How would a controller deal with outages that require re-routing of traffic? If a hacker gains control of your controller, could that intruder bring your network to its knees?
4) Think about where to start: As mentioned above, SDN was initially and still is targeted at the data center where much of the automation and orchestration, capital and operational cost reduction benefits are obvious. But the enterprise WAN is now being mentioned more frequently as a prime focus for SDN. WANs can equally benefit from the automation and simplified management SDNs bring, proponents say. Major IT trends such as SaaS, private clouds, BYOD, mobility and voice/data convergence are stressing the quality of links in an enterprise WAN. And WAN links now require improved security, lower latency, higher reliability and support for any device in any location to accommodate these trends. SDNs can help enterprise IT accomplish this without the expense of upgrading individual WAN links, advocates say, and can allow for application and traffic prioritisation, ease of provisioning and enhanced security.
5) Weigh how to start: Start small, those with experience say. Carve out a small slice of a test and development network for SDN experimentation instead of going for the whole shebang. That way, if anything goes wrong, you're not affecting the whole production network. Once things are humming along nicely, you can gradually meld the SDN pilot back into the production network and carve out another little piece to transition over. And when things are running smoothly, SDN can facilitate the combination of the development and operations networks into a single DevOps environment where new capabilities can be quickly turned up into production mode once they are developed and tested.
6) Evaluate different vendor offerings: Know the ins and outs of the major, established vendors and their SDN/programmable network offerings: Cisco's Application Centric Infrastructure, VMware's NSX, HP's Virtual Application Networks, Juniper's Contrail, etc. Know how they differ -- physical/virtual underlays, network virtualisation overlays, OpenFlow-based forwarding and flow management -- and how they are similar. Take into account the implementation with what you're trying to accomplish. Peruse their application ecosystems for solutions to your problems.
7) Peruse open source and whitebox offerings: Hey, if it works for Google... There are perhaps no more sophisticated or complicated data centers than those of the Webscale companies. They find a lot of their solutions in off-the-shelf hardware and software, like merchant silicon-based switches from Original Design Manufacturers and open source software. And the OpenDaylight Project has developed an open source SDN framework from the code of multiple established vendors in case any enterprises are worried about downloading SDN from the "community." But the Googles of the world add a lot of their own secret sauce and cobble all this stuff together by themselves. Open source and whitebox switches may be up to the SDN task, but you'll have to design, install, operate, manage, maintain, service and support the infrastructure by yourself. Unless you opt to purchase from a partnership like Dell and Cumulus...
8) Check out start-up offerings: Speaking of Cumulus, they're a start-up with an intriguing open source/whitebox proposition that involves a Linux operating system specifically for networking that can run on bare metal switches. That promises to drastically cut down the expense of data center networking, and with the Dell partnership, customers can now get service and support from a data center giant. Start-ups are all over the SDN map: Vello Systems has OpenFlow 1.4 software for optical enterprise SDNs; Pluribus and Adara combine servers with switching to tightly integrate virtual services with the physical infrastructure; Big Switch Networks focuses on orchestration of physical and virtual networking resources; Anuta Networks' NCX system is a software VM or x86 appliance-based controller and agents that interact via an array of protocols and APIs -- including OpenFlow -- to automate the provisioning and orchestration of Layer 2-7 networking services across existing infrastructures; and the list goes on. Enterprises would be wise to consider cutting-edge technologies from start-ups for their SDNs.
9) Determine the functionality you need from an SDN controller: Ethan Banks has written a treatise for us on what to look for in an SDN controller. Such considerations include performance, capacity, topology, capability and functionality, openness vs. vendor uniqueness (lock-in), and others. But Banks concludes that enterprises must conduct due diligence on their networks and what they want SDN to do on it, in addition to thoroughly educating themselves on the controller itself.
10) Learn from experiences and best practices of your peers:Goldman Sachs is all in. It's been doing SDNs before the technology was called that. Now the financial firm wants a little more consistency, uniformity and openness. The University of Pittsburgh Medical Center is all in -- it's looking to SDN and a private cloud to bring the network up to where the school's virtualisation is. Marist College is all in -- the school is bullish on OpenFlow as a way to interconnect data centers over optical fiber. It's using open source controllers as well as server monitors. It's moving workloads between data centers, experimenting with scalability, researching SDNs with IBM, and can share a wealth of experience. Bloomberg has a purpose-built SDN for traffic monitoring and tapping of financial application development, and is also looking at how an SDN overlay scales for onboarding and off-boarding inter-cloud users. All users agree on one thing: go slow with SDN.
11) Consider the impact on your existing network: University of Pittsburgh Medical Center found its existing network was not up to the task when moving virtual machines around, so it went with an SDN private cloud. Most SDNs are likely to require wholesale upgrades to networks that are more than five years old. Cisco is ushering in a whole new switching line for its Application Centric Network programmability play. Juniper's new SDN core switch, the EX9200, will require a forklift upgrade of the EX8200 base. Indeed, SDN is leaving many older switches behind. Before making the leap to SDNs, it might be helpful to know how much of a leap is required. And if it ain't broke without SDN, is it worth fixing?
No comments:
Post a Comment