Network Appliance—The Case for a Gorilla (Part II-Open Proprietary Architecture)
Part I of the Case for a Gorilla was an overview of NTAP's successful bowling pin strategy, which was executed in the 1993-1996 time frame.
I had promised the second part would discuss the NTAP value chains, but have decided, based on recent discussion, to focus on NTAP's Open Proprietary Architecture instead.
Network Appliance's Open, Proprietary Architecture.
From TRFM Page 52:
“That control [over a value chain], in turn, has its roots in what the high-tech community calls architecture…an architecture is proprietary when it is under the control of a single vendor, in this case the gorilla. It is open if its interfaces are published and other vendors are encouraged to integrate their products with the gorilla product to create a whole product for a target customer.”
NetApp filer architecture is very simple in concept. It is open from two perspectives. First, NetApp complies with the Unix and Windows file interface architectures, NFS and CIFS, respectively. So to a Unix server or Unix client accessing data on a filer, the filer “appears” as another Unix platform supporting the NFS file protocol. To a Windows client or server accessing data on a filer, the filer appears as a Windows NT server supporting the CIFS file protocol. So any application program written for Windows or Unix is able to access data stored on a “filer”. Any operating system function, including security, is able to access file structures and data stored on a “filer”.
The second perspective is that of third party software system integrators who wish to interface their file backup systems to “filers”. NetApp's proprietary SNAPSHOT/SNAPRESTORE features streamline and simplify the whole backup/recover/restore process, but NetApp has no intention of providing all of the specialty products for archiving/retrieving data to/from Network Attached Storage. To allow the backup industry to add value to NetApp's products, NetApp help found the Network Data Management Taskforce (NDMP), which defined an open protocol for network based backup.
ndmp.org
The NDMP organization has at least 13 backup software vendors, six (6) tape library vendors, 15 NAS/SAN, and several consulting and market research firms. For a complete list see ndmp.org
NDMP represents a significant set of links in its value chain. We will discuss that in the next installment of this discussion.
NetApp went one important step further and created a unique ability to support concurrent access of Unix and Windows “clients” accessing the SAME data at the same time, while enforcing a cross-mapped “multiprotocol” security system with no emulation software on the clients and servers accessing data on a “filer”. So NetApp is providing secure multiprotocol file access with full UNIX and Windows file security “natively”.
For a complete discussion of NetApp;s multiprotocol support see netapp.com
Here is an important excerpt:
“NetApp filers are not UNIX-based, nor are they Windows-based. The microkernel operating system and WAFL (Write Anywhere File Layout ) file system were designed specifically for extensible file service. Therefore NFS, CIFS, HTTP -- and in the future, additional protocols -- can be implemented natively. There is no functionality mismatch, as with the emulated approaches, and kernel-based security and file locking enforcement are inherently stronger than user-space application software methods (Figure 2).
"With multiprotocol filing, PCs can store and access data side-by-side with UNIX-based clients, without compromising their respective file attributes, security models, or performance. Users with PC desktops can work within the single instances of their home or project directories, with Windows-based applications executing locally, or UNIX-based applications running on a server. And whether written to the filer via NFS or CIFS, documents can be accessed directly by a wide variety of Web browsers via HTTP.
I will offer an example of how beneficial this multiprotocol feature is to NetApp customers. Imagine an ISP or Internet Data Center provider running a mix of Unix-based and Windowns-based servers. These may be web servers, application servers, mail servers, news servers, etc. With NetApp filers, the service provider can create a filer farm of storage capacity without regard to whether capacity is to be provided to Windows or to Unix –based applications. The applications, regardless of their OS platform, may access data on the filer farm with complete native (NFS, CIFS, HTTP) security. Also important is that a Windows-based app may be accessing the same file as a Unix-based app, and the security of the file is protected natively in both environments.
NetApp innovated several techniques for multiprotocol support (particularly interprotocol security mapping), which are patented by NetApp.
SNAPSHOT deserves some focus here, as it is a proprietary but open feature of the NetApp filer. The SNAPSHOT capability is an inherent feature of the Write Anywhere File Layout (WAFL) storage/retireval patented methodology of the filer. Here is a summary description:
“For more details about Snapshots please see Section 2 of NetApp Technical Report 3002 .
"A Snapshot is a "frozen" (read-only) view of the file system created by preserving all the pointers to all the disk blocks currently in use at the time of the Snapshot. After a Snapshot has been taken, changes to files are reflected in updates to the current set of pointers , no differently than if no Snapshots existed. There is no performance overhead associated with using Snapshots, and disk usage overhead is minimized by preserving individual 4-KB disk blocks instead of whole files. Snapshots can be scheduled to occur automatically on a recurring basis. There can be up to 20 Snapshots at any one time.
"Files in a Snapshot of the file system have the same access privileges as in the active file system. A user with permission to read a file in the active file system will still be able to read it in a Snapshot. Users without such permission will still be unable to read the file. Write access privileges simply do not apply — files within a Snapshot cannot be changed because Snapshots are read-only. Updates to files must be performed on the file's image in the current, active file system.
"Backups can be performed via Snapshots, allowing users to continue to write to the live, actual file system without endangering the restorability of the backup in progress. In fact, the NetApp dump command will automatically create a temporary Snapshot for its own use, unless directed otherwise by the system administrator. For an example of how to do this, please see section 5.2 of Technical Report 3052 .”
(One important objective of forming the NDMP standards is to create a value chain of third parties providing backup solutions which interoperate with the SNAPSHOT feature.)
The next installment of the NTAP Gorilla Case will discuss the company's value chain
But beneath
“Finally, an architecture has high switching costs if, once the value chain has formed, the work to swap it out is so costly as to make unthinkable.”
“The whole combo—a proprietary open architecture with high switching costs—is the formula for gorila power.” |
