A few weeks ago I created a presentation in which the goal was to summarize “the what” and “the why” of SDN. After talking about the why (exaggerated by saying networks suck), I talked about “the what.” I broke down “the what” into four quadrants. These quadrants were Programmability, Controller Based Networking, Network Functions Virtualization (NFV), and Overlays. The bottom half, NFV + Overlays, was really meant to capture the complete view of network virtualization. One can then accomplish network virtualization by using technology from the top 2 quadrants, i.e. leveraging a controller (that hopefully creates abstractions) with programmatic interfaces (north and southbound) that automates provisioning of L2-L7 network resources. Technology from each quadrant can be deployed individually or altogether.
Point 1: NFV or open APIs by themselves may not be “true” SDN. However, I’m starting to see that those who always make it a point to say that are doing it as a means of FUD or lack of understanding. If it is lack of understanding, that’s okay. Always clarify. But remember, software enabling a network service or using an API on a device are both stepping stones to an agile network.
What’s the goal again --- to debate a definition or improve the agility and flexibility of a complete DATA CENTER(S)? --- It’s not just about the network.
Over the past few weeks, I’ve also heard some interesting comments, some from customers and some from vendors. Some of these include: “SDN is still a few years away. SDN is still research project. If you want a solid solution, you should be deploying hardware. Running a router on VM is SDN. Network automation is a day 2 project. Server automation is the priority.”
Point 2: Some components of SDN are here TODAY (data center, maybe?). It is not a research project. Those are facts.
When the conversation in a meeting gets steered to general programmability, the conversation often goes, “well you can program whatever you want” using open APIs. I even often find myself saying that --- because it is true. Since I’ve been focused on JAVA, I really do want to program the network now and can’t wait to get my hands on onePK. However ---- I’ll go out on a limb and say 90% of traditional network guys do not want to program the network or even automate the network in any way. They can’t fathom the idea of automating network tasks, forget about integrating 3rd party applications. I used to be there --- you would push a config change using your favorite SNMP manager, but you still had to login after to verify the change or using that same SNMP manager, it would display the CLI for you to verify it to make you sleep better at night. Sound familiar? It’ll take time, but we’ll get there.
Before you know it, the meeting is over and you haven’t discussed anything that is shipping today. So the perception is SDN is years away and then comes in another vendor that is presenting on products shipping today. That is the biggest dilemma of them all. I digress.
Point 3: Focus and differentiate on what is real and here today vs. what is still coming or on the roadmap.
What about “the how?”
I didn’t cover “the how” in my presentation. That should come second. Do you really care if it’s a VLAN, VRF, or VXLAN? Or should I ask, does the application or business care? Please remember why the network exists. It is extremely hard to do, but we need to try and take a top down approach. As a network guy, I’m surprised I can even say that, but if you are focused on what’s right for the business, that’s the way it should be. Operational models will need to change, but don’t let that stop you from passing up on the opportunity to truly build an agile data center system.
When trying to design a CLOUD, private or public, from the bottom up, it is very difficult. You end up talking about products both physical and virtual and can go off on a tangent on what SDN is. It helps, but just delays the process.
It is so important to define the business requirements, goals, drivers, and applications upfront. Then only after that…we can talk about how. I’m not saying I have all the answers or can even do this in an efficient manner, but that is just my 2 cents.
Point 4: This one is hard, but let’s try and focus on the problem and the business first.
Regards,
Jason
Follow me on Twitter: @jedelman8
What’s the goal again --- to debate a definition or improve the agility and flexibility of a complete DATA CENTER(S)? --- It’s not just about the network.
Over the past few weeks, I’ve also heard some interesting comments, some from customers and some from vendors. Some of these include: “SDN is still a few years away. SDN is still research project. If you want a solid solution, you should be deploying hardware. Running a router on VM is SDN. Network automation is a day 2 project. Server automation is the priority.”
Point 2: Some components of SDN are here TODAY (data center, maybe?). It is not a research project. Those are facts.
When the conversation in a meeting gets steered to general programmability, the conversation often goes, “well you can program whatever you want” using open APIs. I even often find myself saying that --- because it is true. Since I’ve been focused on JAVA, I really do want to program the network now and can’t wait to get my hands on onePK. However ---- I’ll go out on a limb and say 90% of traditional network guys do not want to program the network or even automate the network in any way. They can’t fathom the idea of automating network tasks, forget about integrating 3rd party applications. I used to be there --- you would push a config change using your favorite SNMP manager, but you still had to login after to verify the change or using that same SNMP manager, it would display the CLI for you to verify it to make you sleep better at night. Sound familiar? It’ll take time, but we’ll get there.
Before you know it, the meeting is over and you haven’t discussed anything that is shipping today. So the perception is SDN is years away and then comes in another vendor that is presenting on products shipping today. That is the biggest dilemma of them all. I digress.
Point 3: Focus and differentiate on what is real and here today vs. what is still coming or on the roadmap.
What about “the how?”
I didn’t cover “the how” in my presentation. That should come second. Do you really care if it’s a VLAN, VRF, or VXLAN? Or should I ask, does the application or business care? Please remember why the network exists. It is extremely hard to do, but we need to try and take a top down approach. As a network guy, I’m surprised I can even say that, but if you are focused on what’s right for the business, that’s the way it should be. Operational models will need to change, but don’t let that stop you from passing up on the opportunity to truly build an agile data center system.
When trying to design a CLOUD, private or public, from the bottom up, it is very difficult. You end up talking about products both physical and virtual and can go off on a tangent on what SDN is. It helps, but just delays the process.
It is so important to define the business requirements, goals, drivers, and applications upfront. Then only after that…we can talk about how. I’m not saying I have all the answers or can even do this in an efficient manner, but that is just my 2 cents.
Point 4: This one is hard, but let’s try and focus on the problem and the business first.
Regards,
Jason
Follow me on Twitter: @jedelman8
RSS Feed
