Plexxi is gearing up for the 13th Cloud Expo on November 4-7 in Santa Clara, CA. We’re looking forward to discussing the two major IT trends that will be the conference focus: cloud computing and big data. Plexxi’s Mike Bushong recently wrote a post for InfoWorld about the inevitable intersection of Big Data and SDN, and how Plexxi SDN is already being deployed to the cloud. We can’t wait to explore these topics and more at the Cloud Expo and look forward to seeing you all there. In the meantime, watch Plexxi’s Dan Backman and Nils Swart describe the relationship between Plexxi control and OpenDaylight. Here is the video of the week and a few of my reads in the Plexxi Pulse – enjoy!
Paula Bernier, contributor for SDN Zone, wrote about how incumbent network operators are struggling to meet increasing demands and compete with innovative new services. Paula says the network is looking toward SDN and NFV as solutions for these challenges. I would caution people about thinking that the large providers are going to solve disintermediation issues by driving costs down. Yes, costs must come down, but at some point, your ability to continually extract more cost from the system asymptotically approaches a very small number. What then? The path forward will need to be new revenue streams. Monetizing connectivity will become a price war, and there is no cost effort in the world that will keep pace with that. The real value of SDN for providers is the idea that bidirectional communication with applications makes possible a new class of capabilities. New capabilities can drive new revenue. Focusing only on the cost side will be long-term disappointing for the entire segment.
TechTarget’s Rivka Gewirtz Little previews a meeting of the Open Networking Users Group (ONUG), an organization that provides a forum for networking “superusers,” like Bank of America, to brainstorm how to use SDN and programmable networks. I believe that ONUG co-founder Nick Lippis is right that we need to be able to orchestrate workloads across multiple IT silos. The question becomes one of state management (where configuration is just one aspect). What is the common data model to use to describe application workloads? How is that description translated into device-specific behavior? Who acts as the source of truth? The role of the controller will be important here. But if workloads are truly orchestrated, which controller are we talking about? Most of the SDN controllers have a uniquely networking slant. How does a network controller talk to a storage controller in this world? It's great to see users raising the right sets of questions. It will be interesting to see how this plays out over the next few years.
Julie Knudson provides some insight on what to expect from SDN and how it will fundamentally change IT for Enterprise Networking Planet this week. This is a great article that covers many of the relevant trends succinctly. I think Kelly Herrell, VP and general manager at Brocade, nails it with the comment on thin provisioning and an emphasis on utilization. Additionally, the requirement on abstractions is exactly right. I look forward to reading more from Julie regarding trends in networking.
LightReading’s Carol Wilson says that based on a recent poll of more than 900 readers, SDN is facing multiple barriers to deployment, not one single problem. I suspect that operational tooling and security ought to be a bit higher in the list of concerns presented here, but those things don't get exposed until people get past the evaluation stages of solutions. This means we are likely still a ways away from broad deployments – not surprisingly. I am anxious to see what kinds of troubleshooting tools emerge. We have already seen the monitoring applications enter the SDN arena. Extending those types of things to cover more operational aspects of running a network seems logical. There will also need to be SDN equivalents for things like ping and traceroute. State collection and correlation will also matter. These will be best handled as an explicit part of design rather than an afterthought. I suspect vendors planning these up front will ultimately fare better. This does mean customers need to be asking more in depth questions about some of these operational aspects though. Choosing the right architecture without the right tools might be a disappointing experience.
Matt Oswalt at Keeping it Classless wrote a follow-up article to his piece on OpenDaylight projects making consumable policies for non-network people. Matt focuses on how Jeremy Schulman at Juniper is one of the leading pioneers of bringing DevOps into the networking world and presented this at Network Field Day. I also love what Jeremy is doing at Juniper. Extending DevOps into networking seems like a natural fit. Networking folks will need to be educated before this really takes off, but I think there is a ton of promise. One of the things I think we need to be aware of, though, is that DevOps in the network should not be exactly the same as DevOps on the server side. The goal is not to treat routers and switches like servers, but rather to treat them as subordinate to applications. Ideally, routers and switches would be provisioned based on application needs (turn up a new server, the network comes with it). This is a fundamentally different problem than dealing with just automated configuration.
In InformationWeek, Shailesh Kumar Davey explains that many anticipate SDN to mark the beginning of a new networking era similar to how virtualization transformed the server and storage industry. I'd be a little careful equating SDN to commoditization here. While competition in the networking space will bring pricing down, the commoditization (white box) trends are actually separate. If you look at most white box efforts, they are offering networking as we know it today but at lower prices (basic network functionality on white box hardware). SDN is much more about workflow automation. In that regard, it is less about dropping this year's budget and more about lowering long-term operating expense. Operating expense dominates CapEx over the life of a piece of equipment, so companies who want to reduce their long-term IT footprint need to be looking at SDN – even without a hard marketing sell. I think what will help is more concrete use cases. Evaluating SDN as a technology to purchase is the wrong way to think about it. IT departments would be better off thinking about it from a solution perspective, and then including SDN solutions alongside more mainstream ones in the selection process.
ComputerWeekly’s Jennifer Scott spoke with Patrick Zhang, president of marketing solutions for Huawei's enterprise business group on the future for networking and SDN. They particularly focused on how Zhang believes SDN can make an impact on enterprise environments now, even if standards have not been completed. Standardization is tough for emerging technologies. The reality is that none of us knows with enough precision what exactly needs to be part of the SDN future. So we tend to get sparks of precision around specific hot technologies. As an industry, we need to be able to innovate, which means trial and error. Constraining that too early with standards unnecessarily slows things down. That being said, customers need to pay attention so they know when iteration becomes lock-in. It can all be fairly challenging to navigate. Generally, though, I would say that people should look closely at their control and integration points. The things you use to manage other things will be disproportionately subject to lock-in. This likely favors some of the open source alternatives out there, which is part of the reason I like what OpenDaylight is doing and what Juniper is doing with OpenContrail.