Datacenter Topics (CMUG February 25, 2014)

I presented a Cisco Mid-Atlantic Users Group session on “Datacenter Topics” today. It covered NSX, DFA, ACI, among other things. I even said “SDN” a couple of times. And thanks to the 80 or so people that braved snow (flurries) to attend! And those who drove 2-3 hours!

20140226-fig01 The intent of the presentation was to present a variety of recent technologies, with an eye towards what the design and strategic implications are, and how things may change in the future. The topics included: FabricPath, OTV, 1000v and Virtual Appliances, VXLAN (VXLAN networks and tunnels), VMware NSX, DFA (Dynamic Fabric Automation), ACI (Application Centric Infrastructure), Automation and SDN, and some summary thoughts. I tried to present all this as some ideas, perhaps some provocative ideas, with a lot of audience interaction. (Thanks!) To make the discussion actionable, we talked about the positioning of the products, and likely pros and cons.

The presentation can be found here.

Here are some after-thoughts that come to mind… maybe they’ll make this short blog a bit more provocative… polite comments welcomed.

For those looking for SDN, it’s not there in the CMUG presentation (at least, not much). I downplayed SDN, focusing more on concrete products (or soon-to-be products). There’s a lot of exciting potential in the SDN efforts, and in the open source efforts underway. However, many (most?) sites are looking for vendor-supported solutions. They’re not early adapters. Such organizations can’t afford the human or dollar costs, nor risks, around software integration, coding, etc. to leverage the new technologies. So I think it useful to focus more on what one can do today, while keeping an eye on what one might want to pilot or monitor as SDN and automation tools evolve. A practical, pragmatic approach?

I see this situation as being like network management. It’s only worth so much money or effort in most organizations. Network management software gets installed, discovery gets done, and the tool works to some degree. Good tools work, mostly. Bad or mediocre tools are painful to use and eventually stop getting maintained or used. Being more productive is useful, to a point. In most shops, network management products don’t seem to get all that much use for actually managing the network. We’ve managed to turn that around in a couple of places.

Such sites can’t afford to spend say $2M or even $200,000 on a whiz bang network management tool that really makes them more productive, no matter how good it is. Nor can they spend another wad of money for experts to come in and tweak the software so it works better. Especially as some of the costly products aren’t all that great anyway (i.e. there is risk!).

Such organizations are not equipped to undertake programming or systems integration, that’s just not the business they’re in. In the future, maybe they’ll buy a packaged solution, or do without. Such a solution might come from a company that has built packaged solutions that are deliverable at an affordable cost. I expect those vendors, and some large organizations, will be those who hire those networking people that learned to program and work with open source SDN tools and/or Puppet, Chef, CfgEngine, etc. (I’m thinking @colinmcnamara, NexusIS here — and others.) What do you think — will most networking people learn how to program in Python or some other language? And use tools like Puppet, Chef, etc. without a GUI front end?

Think I’m wrong? Gary Kinghorn of Cisco says something similar just now in Is ACI Really SDN? One Point of View to Clarify the Conversation. “What’s caused the biggest evolution in SDN is the realization that very few organizations really have the desire, skills and incentives to write a new class of applications to a published API to program the network.” Hey, I now feel trendy, for getting to that point before the pundits! (For those who think I’m occasionally negative, it’s my anti-hype filter. It sometimes triggers on strong enthusiasm too.)