Ciscos Ullal Describes Data Center Vision

When Cisco Systems CEO John Chambers mapped the next step in the vendors Data Center 3.0 initiative at VMworld Sept. 12, he and Cisco were reaching beyond their traditional stronghold in the NOC to data center managers they hope will embrace its provisioning automation message.

For its strategy to work, Cisco has to gain the confidence of that new audience and entice them to accept its vision of orchestrating and provisioning different resources to support the on-demand creation of virtual machines. The first product instantiation of that vision, the VFrame provisioning appliance, was launched at the end of July at Ciscos Networkers user conference.

To read more about Ciscos VMware integration news, click here.

eWeeks Senior Editor Paula Musich spoke with Jayshree Ullal, senior vice president of data center, switching and security technology at Cisco, about how Cisco expects this strategy to play out.

Its only been a short time since Cisco released its VFrame provisioning technology, but Im curious about how its been received by customers. Whats their reaction been?

Resource Library:

On the strategy and vision side, reaction has been very compelling. This is not something Cisco normally does well. Management, provisioning, orchestration has been an after thought. In general were getting lot more kudos for acknowledgement of the problem.

One of the single largest drivers of that was our own Ciscos IT (group). They were instrumental in defining and deploying VFrame Data Center. They would like to move to it as their preferred data center orchestration tool. Today they have a very proprietary Perl script tool they developed five years ago called eMan. They saw it was unable to scale and keep up with the move from physical to virtual and from different file servers, applications, network attached storage and so on. So VFrame was born from the real world, from a compelling need that we believe data centers have.

The network is the ideal place to connect heterogeneous equipment and it is the natural place to scale and manage all these different images—be they servers, apps or storage. To continue to add virtual capacity, configure downstream storage, add/drop/delete, and maintain configurations, it requires a constant state. The network is ideal for that. The radical approach to booting from the network and providing a heterogeneous set of automated discovery management tools was compelling.

Beyond Cisco IT we have a number of trials. We wont measure the success of VFrame by revenue, but more by customer deployment. Well have to walk before we run.

The other thing we realized was that the depth of VFrame comes also from the number of devices itll have to support. Today it is very Cisco centric. Well have to expand it with more third party devices and APIs to connect to existing management tools. Support of VMware is an example of support for a non-Cisco device. And support of APIs is natural follow-on. Were providing API integration with VMware using SOAP [Simple Object Access Protocol] XML APIs. We think (the APIs are a) natural for a number of applications well certify. On a scale of 1 to 10 Id say we have an 8 in tremendous interest, but is too early to call it a massive deployment.

This is an architectural statement about how data centers need to be retrofitted. This is a journey, not a sprint.

Beyond VLANs (virtual LANs), Cisco has zero credibility in the virtualization space. Besides Ciscos investments in Top Spin and VMware itself, how will Cisco work to gain data center customers confidence?

I object to that statement.

Ciscos credibility in there started five years ago. Weve been implementing that through VLANs, storage, our ACE products in our firewalls. For the last five years weve been making sure the networks been able to move to the virtual world—not just physical pipes. Its been a natural migration from physical to virtual networks. VFrame Data Center is our first chance to tie that together and make virtualization come alive in the network. Virtualization has been dormant in our networks, waiting to be exploited.

With the explosion of virtual machines, the single biggest issue for our customers is connecting them—orchestrating them—(with the various resources they require). VFrames role is to support and make that connection from physical to virtual servers.

Were showing vision and leading the industry in that direction. The next natural step is to scale not only the physical/virtual network, but embed network capabilities in Cisco platforms and others such as VMware as well. The ESX server doesnt have a lot of sophisticated network attributes. The architecture that customers are deploying is ESX servers with virtual machines going upstream to Cisco networks.

We can envision where they can go downstream as well. There are no security profiles, access control lists, quality of service in their connectivity between virtual machines.

Customers are looking for a Catalyst-class switch to connect virtual machines, where they can connect ESXs and go upstream to a Catalyst switch. And they need provisioning tools to orchestrate between virtual machines and Catalyst switches and the MDS switches. Thats one architecture. Another architecture is to go upstream—i.e. build a mini Catalyst for the VMware environment. Cisco and VMware do not preclude that vision.

If I remember correctly, the Data Center 3.0 vision calls for third party development support to be successful. But Cisco has no history to speak of in working with developers. How will Cisco gain the respect and support of developers who have had no experience or incentive to work with Cisco in the past?

Weve never developed the right APIs. You have to have the right mind-set. Were the unifier of the fabric. You have to connect upstream to applications and downstream to machines. We have to evolve to provide that technology. Our lack of credibility stems from a lack of product and technology in this area. As we have our conversations with partners, its becoming clear there is a mutual interest in solving problems. We wont be the sole provider of all management and orchestration in the data center. We have to work with legacy and new environments. That common vision to solve real world problems brings us and our partners to the table. The fact that there are now more well defined ways through standards—W3C, SOAP APIs—makes the problem less of an intellectual exercise. Such APIs didnt exist three years ago.

What has Cisco done so far to woo those third parties?

Weve been more focused on making sure we can get customers to deploy VFrame Data Center. Based on that experience we run into different use cases. As we do, we run into third parties that we woo—and they woo us as well. Weve gone at it saying lets build the right APIs, study the right use cases and then (look for) the ecosystem (partners) we need to work with. This is a more pragmatic approach rather than a formalized program. APIs are unique in each environment. You have to test, validate, certify and understand the use cases in terms of how much value you can extract out of the API.

Check out eWEEK.coms for the latest news, views and analysis on servers, switches and networking protocols for the enterprise and small businesses.