2015 was a big year for more operators making more SDN/NFV-enabled services available, reaching more places.
SDN and NFV promise efficiencies of virtualization and dynamic bandwidth, but the technologies provide many ancillary benefits as well.
For companies interested in dynamic networks and network virtualization, 2015 was a banner year. While network function virtualization (NFV)-powered services had already begun gaining ground (just two examples are NTT Com and CenturyLink), dynamic bandwidth provisioning was still limited. Verizon (with Dynamic Bandwidth for Private IP), Level 3 (with former tw telecom’s Adaptive Network Control) and Masergy (with Intelligent Service Control) were established competitors. AT&T had just begun introducing its SDN-powered Network on Demand service in its local service footprint. Telstra’s PEN remained an Asia-region network. Continue reading “Looking Back and Ahead, Commercial SDN/NFV Offers Hit Full Steam in 2015”→
Open source seems great on the surface, but vendors commit more than time and code to a project, and that can be risky.
Customers need to understand how vendors will address shortcomings in products based on open source.
At the SDN & OpenFlow World Congress in Dusseldorf, I chaired a debate called “Building the Ecosystem for NFV, Impact of Open Source” with Brian Aherne, Director of Intel’s Network Computing Division EMEA; Ari Banerjee, Senior Director of Strategy at NEC/NetCracker; Valérie Noto, Director of the CloudBand Ecosystem, Alcatel-Lucent; Recep Ozdag, Senior Director at Ciena; Prodip Sen, Director/CTO, Network Functions Virtualization at HP; and Walter Zielinski, Senior Director, Core Network at Huawei. It was a lively debate, with everyone in agreement (despite my poking and prodding) that open source is good, everyone collaborates, and lets all hug – until Recep Ozdag, and then Ari Banerjee, made a comment at the very end to the effect that open source development doesn’t automatically mean faster or better development. A colleague pointed out they may as well have kicked a puppy. Continue reading “SDN and OpenFlow World Congress: Let’s Kick Some Puppies, or Why Open Source Poses a Business Risk”→
VMware announced a number of new features for NSX which are necessary, but incremental.
VMware’s technology partners need to be wary when the company enters their market.
On the run up to VMworld 2015 VMware released NSX 6.2 which added a few new features such as inter vCenter NSX support, universal firewall rules, security groups, logical routers, and logical switches, and a new troubleshooting tool called Traceflow. Collectively, these are important but incremental updates to NSX. A bigger game changer coming at the end of September is the integration between the virtual and physical network when VMware and its hardware networking partners like HP complete the support of OVSDB in NSX to manage hardware virtual tunnel end-points (VTEPs). In the far distant future, VMware will also support virtual networking with cloud services like Amazon Web Services by creating a VM that runs a virtual switch which NSX can then manage. Continue reading “VMworld 2015: With NSX 6.2, VMware Encroaches on More Product Markets”→
SDN needs new applications to make it relevant to enterprises and spur adoption.
Enterprises need to think of how a SDN can unlock new business and improve existing processes.
Gaining big benefits often comes with big disruptions, and that is true with SDN as with any other technology. One observation that struck me at both the OpenDaylight Summit and Open Networking Summit is that the potential for SDN is just starting to grow in the application space; and when it starts to pick up steam, the SDN movement will suddenly become very interesting for enterprises. Today, the SDN drivers for the enterprise are still relatively vague, only offering improved network automation and virtual machine movement. Microsoft has also been very aggressive in integrating Lync with traditional and SDN network products, which is also useful. These applications are beneficial, to be sure, but not too exciting. If SDN use cases just stayed at server virtualization support or incrementally better unified communications support, adoption would be slow and accretive. What will make SDN truly exciting are applications that enable new businesses and new capabilities. Two come to mind. Continue reading “SDN Needs Just One Good Application”→
Enterprises have better things to do than do than perform the heavy lifting white box switching requires, even if there is a CapEx savings.
A well-heeled VAR or integrator could step out with their own branded white box product line and offer real competition to vendors.
Enterprises are slow to change to new technologies because, without a compelling benefit—and often the comfort of knowing what their peers are doing—they see no need. When companies do make technological changes, they often do so with the help of a VAR, integrator, or consultant to help them along. Even the big multi-nationals will get lots of on-site assistance directly from a vendor during the trial period and when moving to production. Few enterprises are going to go it alone on a project migration that involves new technologies. When the market does move, the technology has often matured and implementers have enough experience that deployments are often manageable. Continue reading “Getting Enterprises to Adopt White Box Switching Will Take a Sea Change”→
As SDN moves along the hype cycle it’s important to remember that the success of the technology is not a given. The market, and demand, could collapse.
Even if the SDN market did collapse, the benefits from the technology and product development will resonate for some time in the future. It’s not wasted effort.
If SDN as a technology is going to be successful—cross the chasm and go mainstream—then it must disappear from the minds of everyone except an ever shrinking networking talent pool. The SDN product cycle is following the same path of every other over-hyped product space but at any point it could implode like NAC and PKI. Success is not a given. Continue reading “SDN Needs a Pretty Big Leap to Cross the Chasm”→
VMware dismisses physical networking as a mere forwarding plane, ignoring the benefits of integration.
If that observation is inaccurate, then VMware needs to address its messaging on the importance of physical networking.
Fresh off VMworld 2014, I came away with the very distinct impression that the company – not any specific individuals – is quite dismissive of physical networking, to the point where it is detrimental to its own success. While I continue to be impressed at how well the company develops new products, maintains a practical engineering focus, and seems to handle partner co-opetition with aplomb, it is also making a rather big mistake with ignoring the importance of integration with the physical network. Continue reading “VMware Doesn’t Make Many Mistakes, but It Is with Respect to Physical Networking”→
Network administrators learning how to program is a benefit to employees and employer, but it shouldn’t be a requirement.
SDN promises many things including operational simplicity. Programming isn’t operationally simple and your network admins shouldn’t be doing it.
Even if SDN isn’t having an impact on data centers like my colleague Steve Hill thinks, the idea is certainly having a ripple effect within IT departments and among network professionals considering their career path. One common topic the keep recurring is whether network professionals need to become programmers to remain relevant.Kirk Byers thinks programming will be an essential skill for network engineers and points to the number of commercial and open source tools and controllers that have APIs and SDKs that can be used to stitch together various components into an automated and orchestrated network. In principle, I think the more network professionals know about how their systems work and integrate together, the better off they will be career-wise and the greater value they will be to their employers; but I generally disagree with the premise. Besides, if network professionals also have to be developers, then the entire networking industry will have failed to deliver one of the key benefits of SDN – easier operations. Continue reading “Mamas, Don’t Let Your Net Admins Grow Up to be Programmers”→
SDN will create varying degrees of product dependencies for enterprises.
Enterprises need to plan for and create processes that support multi-vendor SDN.
It’s no secret that I think SDN Will Lock Enterprises in Tighter Than Ever because of the dependencies that are built up with software integration and I don’t think many enterprises have quite grasped the amount of stickiness software integration has.
Naturally, there is a continuum of SDN implementations, ranging from very basic integration with just enough touch to automate networking provisioning for VMs to fully automated, application-level provisioning that includes service chaining and follow-me functions for traffic monitoring and packet capture, and seamless integration of physical networking without the intervention of a human operator. Depending on where an enterprise is on that continuum the amount of stickiness will vary from “not much” to “a great deal”. Continue reading “Process is Critical for a Multi-Vendor SDN”→
You can use automation without software-defined networking (SDN), but you cannot use SDN without automation.
Many enterprises will gain enough benefits from automation and may not need to migrate to SDN.
The answer, of course, is whatever option works for you is the one that’s best, but that is a little too facile, so let’s dig in a bit. Automating operations such as scripting configuration changes and responding to events has enormous value for any IT department. When I actually worked in a data center, my rule of thumb was: if I did something more than three times in a month, I’d automate it, including the little atomic actions such as changing the syslog entries on a switch which could take as many as five to seven command line entries. Automation saved me hours, perhaps days, per month executing configuration changes (and even more because I had far fewer errors). Continue reading “Which Is Better: Automation or SDN?”→