IN THE MIDDLE / BRUCE ROBERTSON
Object Service: The New File System
Most network operating systems (NOSes) have been built on file services. Their competitive position depended on file service speed and efficiency. It's no secret that NetWare's file service performance has been key in its domination over the NOS marketplace. Now, other NOSes -- Windows NT, LAN Server, VINES -- are getting faster and edging in on NetWare's performance.
That's not, however, why NetWare's competition is getting the best of Novell lately.
No, the real reason is this: File service doesn't matter anymore.
Downfall of File Services
An increasingly large proportion of mission-critical applications no longer store their multiuser data in shared files on a file server. Client/server-architected products now have a more efficient means of handling shared data than file services.
The first migration of shared data off the file server was to relational databases like SQL Server and Oracle. These products manage their own data access. They offer proprietary client software for networked access to their services. For many organizations, this database client connectivity is more important than their connection to a file server. The database server also holds its data more securely.
The next migration away from the file server is under way with single-user data files. Sharing documents and spreadsheets used to be accomplished by putting them in some shared network directory on the file server. But like many users in distributed organizations, I usually share documents with coworkers via e-mail, since we don't have any single shared file server available to a
ll our sites. E-mail not only lets me provide other people with access to my documents, but it lets me direct that document to the intended recipients with some control and an audit trail. E-mail certainly isn't a true work flow environment, but that's how I often use it. It's better than file services for sharing individual data. Besides, file service has never been as user-friendly as I've wanted.
Of course, file services are still useful. We still need some centralized storage facility from which applications can be staged. Users can store their personal data files on the file server where they can be backed up. Still, if any of those client disk backup programs ever really worked, users wouldn't need centralized storage for that either.
File service just doesn't fit the way organizations use and share data well enough anymore. It's the old way to share. The new way to share data is becoming increasingly apparent. I believe that conferencing systems, as they extend to full-blown document stores for individual documents will take over the position of file services for most users and uses.
After seeing Notes and the beta of Microsoft Exchange, I believe I've seen the future: an object system, not a file system. In Exchange's shared folders, we're glimpsing the promise of Cairo's advanced "object" file system. The things we need to store are no longer just files; they include messages, forms, files, records, conversations, document versions and so on. Any old thing. So, like everyone else, let's call them "objects."
Objects are more complex and need a store capable of handling all their interactions and uses. Users not only want to open and save them but find them based on a conversation thread, a document version sequence, a form field's contents and so on. Not just by the file name. Moreover, they want all related forms, messages, documents and so on, in one storage system. In one folder. Together.
Let's hope they are high performance. If object stores are fast enough to handle saving word processing
documents by individuals, most users will use them. Particularly if the extra steps of mapping drives to a file server and getting an administrator to set up shared directory permissions aren't needed. Object stores will be easier to manage and work with for end users sharing data with others.
Moreover, existing conferencing systems already offer solutions beyond regular file services. We get replication of the store. Notes, OpenMind and all the rest view this as a requirement, not only between servers, but to the desktop in a personal, filtered way. Not so for the traditional file server. About all they talk about is mirroring disks and servers. Of the network operating system bunch, only Banyan has talked publicly about replicating file systems, but only between servers. File servers should offer this, but don't. Object services must offer replication support to survive.
File Service Disk Requirements
Our January issue reports the results of our poll on future file server capacity requirements. Basically, everyone wants more. Specifically, at least half said over 50 percent more space would be required in 1995. These figures miss a significant point. The big increase for most people in storage capacity in 1995 and beyond will not be in generic file servers. Instead, the increase will come in storage systems maintained by specific application services. This assumes that the application server isn't using a file server drive as its disk (which may or may not be indicated by our poll results).
We already store more data in SQL RDBMSes, which definitely don't use regular file server disks for data storage. In the future, we'll store more in Notes and other groupware applications (which often store data locally on the server's disk, rather than on a remote file server drive), e-mail servers (all the major e-mail systems will soon migrate to client/server versions that will need larger amounts of complex document storage and will have their own storage options), and special backup devices. The slowest i
ncrease in disk space requirements will be for file services.
As applications go to client/server architectures, their server component will increasingly be a single process accessing a large storage bin. This is fundamentally different from the typical file service goal of serving up files to a very large number of individual users and processes. The server to disk processing should be optimized to that task, rather than use a file system that is optimized to handle large numbers of different tasks.
Therefore, as the large RDBMS vendors have found out, you don't use network file services (or even some local file systems such as those on Unix or NetWare for NLMs). You manage your own access to raw disk in a proprietary format unavailable for other uses. Alternatively, you at least avoid using the network file system's built-in caching system and instead use one optimized for the server application's specific usage.
File service is dying an increasingly quick death at the hands of client/server. Client/server systems are taking over the handling of data everywhere. File-only systems just won't do anymore. NetWare, the old reliable, must compete with the other NOSes now as an application server rather than as a network operating system. Customers will decide, but it is clear that NetWare is not as strong here as NT and Unix. And, Unix isn't as simple as NT. No wonder NT is getting lots of print lately. Perhaps multiprocessor NetWare will help it scale, as will the processor-independent versions Novell has mentioned. In any case, this new object store world is offering opportunity for many.
The challenge for NetWare or any of the NOSes is to compete with the RDBMS products, the client/server e-mail systems and the groupware systems for network service share. Their file service is reduced to just one of many network-available services. Less important than the others. No longer the prima donna. Perhaps only another voice in the chorus.
Bruce Robertson can be reached at brobertson@nwc.com.
|