Cisco Blogs

Designing Unified Fabric Products Before Unified Fabric Existed

- March 16, 2009 - 0 Comments

Designing a (successful) product is always tricky; first of all, you need to properly define and wisely select your product requirements. But whatever market segment you are in, your product requirements will change over time. No matter how good you are at predicting market dynamics. Typically, it’s “simpler” to address this variability if your product has relatively short development cycles and if the switching cost for your customers is low. In such conditions, you might lose a cycle but you can get back in your market, with the right product, within few months. Consumer space could fit this description for example. The problem with networking products in particular is that development cycles are instead certainly long: 12, 18, sometimes 24 months from product definition to availability. More importantly, from a customer perspective, the investment involved in networking gears is significant and the product life is expected to span over multiple years to maximize the Return On Investment (ROI).Therefore your product must be designed, from an architectural perspective, in such a way you can still innovate to address new, originally unforeseen, customer requirements, without necessarily disrupt your customer initial investment (and your original product). To do that, you need to design a product architecture which is as flexible, scalable and agnostic as possible, and not necessarily tight to any specific technology or, in networking, to a protocol. At that point, you design a platform, not just a product. A platform will always allow you to innovate through evolution and protect your customer investment.Back in 2000, the MDS 9000 Family was in its early designing phase. At that time, with established players, the competitive product requirements were pretty simple: you just needed a product able to speak Fibre Channel and go as fast as 2 Gbps, maybe with some sort of redundancy to be called “Director” vs. “Fabric” switch. But the MDS team rather decided to wake up every morning with the idea of finding new ways to redefine storage networking. To achieve that, we firstly needed innovative advanced technologies; and we did provide technologies that our competitors don’t even have today or that they have been able to mimic only 2 to 5 years later. More importantly, we had a very specific goal in mind: to design a future-proof platform, not just a switch. A platform that could evolve, without changing, with the dynamic business requirements of our customers. Virtualization wasn’t back then an hot buzzword as today, but we delivered since day zero fabric virtualization through Virtual SANs (VSANs) and the first examples of network-based storage virtualization, as we did foresee the benefits of the virtual Data Center everyone is talking about today. Disaster-recovery and compliance requirements suddenly spiked after September 11 and we then seamlessly provided integrated secure SAN extension solutions. New regulations are recently imposing to encrypt sensitive data stored on tapes: using the same Multiservice Module enabling amongst other features the just mentioned SAN extension, we offered Storage Media Encryption that can now be transparently inserted into any existing infrastructure.Back in 2000, we didn’t even have a Fibre Channel product, so for sure we had no idea about porting Fibre Channel over Ethernet (FCoE) nor delivering a Unified Fabric: nonetheless the first customer that bought MDS in 2002 will be able, in that same chassis, to enable Unified Fabric through seamless integration of FCoE capabilities. This will allow that customer to integrate even more tightly the MDS platform with the wider Data Center product offering from Cisco: Nexus and MDS Families will play together to deliver the Data Center of the future, sharing by the way the same operating system, NX-OS, that initially powered the MDS 9000 Family under the SAN-OS brand.This is the big difference between designing platforms vs. “boxes”.image

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.