Mike is a senior analyst on the Business Technology and Software team covering the Enterprise Networking and Data Center Technology markets. He has extensive experience reviewing and writing about enterprise remote access, security, and network infrastructure products.
•SD-WAN products are well suited to address the complexity and scale of IoTAs diversity in IoT grows.
• SD-WAN vendors will be challenged to address the specific needs of new and increasingly specialized IoT products.
Commercial IoT networking in the short term is more about connecting and protecting IoT devices and gateways that are already deployed, or will be soon, rather than having to support a raft of new, IP addressable devices. The IoT name has been equally applied to what otherwise are called sensor networks, command networks, industrial Ethernet, and other network-attached devices. SCADA devices certainly fall into this realm. The difference being that these devices are being connected—on purpose or inadvertently—to public networks and exposing them to the potential for additional attacks. Continue reading “SD-WAN and IoT: A Long Road Ahead”→
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”→
With over 19 Internet of Things (IoT) radio protocols in use today, the need for consolidation is clear.
Short of consolidation, integration of IoT devices will occur at the application layer with robust APIs.
Many of the ‘things’ in the IoT like lights, sensors, switches, HVAC controls, and other actuators will be connected via wireless gateways because rewiring a building is expensive. I counted over 19 wireless protocols between standards-based protocols, proprietary protocols, and protocols that have a basis in both standards and proprietary protocols. Continue reading “Over 19 IoT Radio Protocols Drive the Need for Integration APIs”→
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”→
• The temptation to modify open source software outside of a project is often well intentioned but brings a number of significant drawbacks.
• If you’re in enterprise IT, don’t buy products based on open source projects like OpenDaylight without a guarantee that the vendor won’t fork the code in the future.
In a strong rope, lots of underlying threads share a heavy load in the very same way that strong ideas form a great movement. Over the last few weeks, I’ve picked up on a couple of threads that I believe need to be at the core of the Open Source SDN implementations to insure the strength it really needs. At the OpenDaylight Summit, I had a chance to speak with a number of vendors about the future of OpenDaylight (ODL) and my desire to see every vendor making a controller based on ODL commit to not make any changes to the distribution that doesn’t come from the project. In other words, don’t fork the code because doing so presents a number of deleterious issues such as:
• Changes from outside the project make it more difficult for vendors because those changes may conflict or introduce new bugs with the updated ODL code
• Increasing the time it takes import changes from ODL into the forked code due to increased testing and validation
• Impacting integration from other products due to unexpected changes to the controller behavior
• No improvements to the overall health or functionality of the OpenDaylight code if changes aren’t up-streamed.
Colin Dixon, Chair of OpenDaylight’s Technical Steering Committee and a Principal Engineer at Brocade; and Devlin Avery, also from Brocade, spoke at length in Best Practices and Pitfalls for Building Products Out of OpenDaylight about the discipline needed to not clone and fork the code base. Brocade is demonstrating leadership in SDN by making a public commitment to not fork the Open Daylight code at all. It’s tempting for vendors to make changes that they think can be reverted later, but in reality, doing so instills bad habits and complicates their software development lifecycle. Perhaps more importantly it will create problems as the project matures and software vendors try to maintain consistent code bases that diverge more and more. There is also no guarantee that products that integrate with ODL will work properly against a forked version.
So you’re thinking, “Well, that’s great Mike, but what can I do to change this?” The answer is to speak with your wallet. At F5’s Agility 2015 conference, General Colin Powell (Ret.) gave the keynote. He’s an entertaining speaker and draws on his experience in the military and government work. Midway through his keynote, he expressed his frustration with the gridlock in Congress and made a pointed statement that while Congress is dysfunctional, it is we, the voting public, who put our representatives there, and we can vote them out as well. Changing Congress is hard, but this principle is actually easier to implement for enterprise IT.
When it comes to support for standards and open source software, you “vote” with your wallet. I don’t think there are many networking professionals evaluating ODL today that really want to be locked into a particular vendor’s product line, but once you buy into a fork of an open source software project that’s exactly what you’ve done and you will may well have signed on to have fewer timely updates and far less seamless integration in the future. Trust me, you don’t want that. The solution is to tell your networking vendors that are shipping software based on open source software that you don’t want forked code; and if they can’t deliver project-consistent code, you’ll be shopping elsewhere.
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”→
Dell is leading the competitive market in disaggregated switching with four switches and three (soon to be four) OSs supported.
Any networking vendor could equal Dell’s early lead in a few months, but catching up with Dell’s integration strategies will take longer.
While Cisco and VMware are squabbling over ACI and NSX and other networking vendors are trying to gain mind and market share with enterprise IT, Dell has taken a turn away from all of its competitors by committing its future data center switch lines to its ‘open networking’ (ON) strategy that may very well be a significant differentiator in the future. Continue reading “Networking Came to a Fork in the Road”→
The debate over custom and merchant silicon is an old one, but it’s gaining steam driven by developments in software.
What matters to IT buyers is that the product provides adequate performance, and vendors using custom silicon need to make their case.
There is something of an intellectual debate occurring in networking over the need of custom versus merchant silicon. It’s not a particularly new debate, but the rise of white box switching, an ever increasing number of switching products coming to market using merchant silicon and the increased focus of software for both advanced features as well as tight integration with the rest of the environment is making the debate far more relevant. Continue reading “What Matters Most in Networking with Custom or Merchant Silicon”→
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”→
HP’s planned acquisition of Aruba highlights the perils of relying on a single partner to fill a gap in a product line.
IT vendors should leverage the software-defined movement to foster diversity and robustness in their partnering plans.
Last week, HP pulled the rug out from under Alcatel-Lucent Enterprise, Brocade, Dell, Juniper, and apparently Arista (considering Jayshree Ullal was keynoting Aruba’s Atmosphere Event) by announcing its intent to acquire Aruba Networks. I won’t say I anticipated the acquisition, but I’m not surprised by it either. Aruba is a very strong WLAN competitor with both APs and location analytics, mobility, and security software. Continue reading “The Days of Exclusive Partnerships Should Come to an End”→