Erik,
>>While all of the attention has shifted up stream from pc's and nc's to expanding the pipes (bandwidth), improving the storage systems to cope with the rapid runup of internet useage will be close behind.<<
Excellent points that would be difficult to overstate. And we needn't even look as far as the Internet.
In the past two weeks I have been exposed to some serious near term contemplations of storage requirements in the tens, hundreds of TeraBytes of storage for applications that heretofore didn't even exist in the real world. I might add, however, that these new apps are in large part derived by the recent availability of cheaper bulk bandwidth and large-scale traffic handling technologies in the WAN.
Bank check imaging file items, especially, have a voracious appetite for both memory and bandwidth. They are about 60KB in size, on average, compressed. Medical and engineering files are much larger, sometimes by a a multiple measured in the thousands.
As an example of what I am referring to, it's interesting to consider how many bank checks there are being processed every day across the country, the world. Up until recently they have been processed manually, using technologies that are thirty years old. But recent capabilities have enabled automated image-processing in mainframes and workstations that reduce paper handling and mishaps by an appreciable multiple. Only recently have the price points on b/w and silicon to achieve this made sense, economically. Despite the increases in storage and b/w volumes.
The reasons behind this are not readily apparent unless you explore the other marketing and product development potentials that exist when you put an image in accessible storage.
Do these images need to be backed up? And where are those backup sites? In fact, where are the actual processing and check handling sites? Local? Not hardly, they are cross-country, for geographical proximity and diversity's sake. And let's not forget the implications that this has for ATM in the WAN, and Fiber Channel and other SAN technologies closer to the hosts.
The trick now seems to be how to deliver these services over IP backbones, without burning out the clutches in the mechanical check sorters and paper scanners due to the restarts inherent in TCP/IP (clutches can only withstand several restarts per unit time, lest the repeated friction, trauma and heat causes them to burn up).
Therefore, QoS and its CBR-derived isochronicity are a must, and Packet over Sonet is just not there yet. But it will be, in due time. Comments on this issue are welcome.
Just another example of bandwidth and storage feeding off one another. FWIW, and Regards,
Frank Coluccio |
