Cisco isn’t the largest networking company, but they’re likely the most famous. They’re associated with the IP revolution, the Internet, and the way that a little company can suddenly become a giant and make a lot of people rich along the way. “Be the next Cisco” entered the lexicon of startup success, in fact. So when they make an acquisition that’s reportedly in the new hot space of “orchestration” people take notice.
Cisco certainly needs to have an orchestration strategy. I’ve blogged before that Cisco’s success likely depends in large part on riding the cloud effectively to IT success for UCS. They can do that without orchestration only if someone else provides it, and that’s because without MANO you can’t improve service agility and operations efficiency in NFV applications or effectively deploy highly agile and componentized applications in cloud computing. Of course, if somebody else is providing MANO then 1) Cisco has to put its aspirations on hold until it arrives because cloud/NFV spending won’t peak without it, or 2) Cisco has to bet that capex control alone will promote the cloud. It can’t wait for the former and the latter would put it into a commodity market.
The problem is that Tail-f, who has from the first been promoting Yang and Netconf, isn’t IMHO much related to orchestration at all. Yang and Netconf are parameterization/control languages that first model a network and then exchange parameter data between a management system and a device. They’ve promoted it for SDN, for NFV, for the cloud, and Cisco has bought into it largely I think because Cisco has always tended to do M&A based on sales recommendations and not on strategic value.
Networks are made up of abstract functions that are realized by committing sets of cooperating resources. More modern concepts of cloud orchestration (TOSCA for example) reflect this model and can be applied to both cloud-hosted functional elements and devices. The principle here is to develop a hierarchy that will envelop current management and provisioning tools, and emerging stuff like SDN’s “northbound APIs” in a common abstraction set so that you can ask for a VPN without caring how it’s set up.
In three successive projects and two formal standards activities, I’ve worked on abstraction-based encapsulation of current and emerging software and hardware, and I think the results have proved out in every case. ExperiaSphere will prove shortly that you can use the correct standards and open source tools to orchestrate at the functional level and accommodate both legacy devices and emerging technologies. CloudNFV, with similar functional capabilities but without the open-source requirement, just won a TMF award for innovation, and innovation is what we need to face the future, not a new way of reorganizing stuff we can already do.
That Tail-f has been involved in a lot of trials is a testament to their engagement with telcos and the fact that the telcos are wrong-headed in the main on the topics of SDN and NFV. You don’t think about software abstractions if you’re a switch/router guy, and so you’re easy prey for a story that converging on a single control mechanism at the bottom will somehow make SDN or NFV happen faster. Any software guy will tell you that nothing good comes from bottom-up design. It’s possible that Cisco is seeing Tail-f as a way of harmonizing other equipment into Cisco’s own evolution-not-revolution SDN and NFV approach.
If you want the services of the future SDN or NFV world to somehow be delivered by the same switches and routers as always, then it’s possible that having some mechanism to coerce the behavior you need from the other vendors you’d likely find in a buyer network would be valuable. If Cisco is really as committed to policy control of networks, then the networks would be divided into little administrative zones subordinate to a policy controller that would then induce the necessary behavior from the devices below. That could be useful to Cisco, but it’s not orchestration, and even policy hierarchies are hierarchies, and Cisco is introducing features to a market, validating them by Cisco’s demonstrated interest, and then not nailing them firmly down as issues Cisco can own.
That would be a major risk for Cisco, because their move here is almost certain to create a lot of competitive counterpunching, and in the media where having a good story is more important than some lab trial wins. We’ve seen competitive strategies in orchestration that are going about this the right way, based on a software-centric hierarchical model. Any of these could be used to generate some real market interest, and thus create a threat to Cisco. Of particular concern is HP, who has on paper a super strategy but still has to fill it out. Might they now, given Cisco’s move, take a bit of time and money and get their whole offering together? If so they could present a pretty exciting alternative to what’s been totally pedestrian Tail-f positioning and totally self-serving Cisco MANO stories.
HP is also dangerous at the technical level, because as an IT company they don’t particularly want to change the world down at the network device level. At least, not any faster than buyers can see the value to doing so. Every salesperson knows that you don’t propose a project that costs your buyer a ton of money when you’re not even going to get that money. Every IT company who looks at SDN or NFV will naturally want to add servers and software to current network configurations as an overlay, to organize and optimize and agile-ize what’s already there. The benefits then flow from the very first. They don’t want to diddle with parameter flows in the basement, which Cisco now seems to have committed to doing.
Tom’s First Rule of Positioning: Don’t validate a market with a step that doesn’t seize ownership of that market. You’re pointing everyone in the right direction and then heading out down a different path. Cisco may have started the orchestration land rush with a move that ties them to a tree, to watch as others race off to the finish line.