This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.


MIND

Flux
flux@microsoft.com
Douglas Boling
Just What is an NC Anyway?
W
hat would you do if you held a debate and only one side showed up? Well, it was not quite that bad when Microsoft Systems Journal, MIND's sister publication, sponsored a PC versus network computer (NC) debate at the Software Development conference in Washington, DC last fall. The other side did appear, just not in the guise expected.
      Actually, the discussion, moderated by Matt Pietrek, started off with both sides agreeing on more things than disagreeing. We both accepted that PCs were not going to be eliminated by the NC. Both sides also agreed that there is a place for NCs in the embedded marketplace. Lets face it, employing a PC as a cash register is not the best use of a PC's power and flexibility. In fact, it's a lousy place for a PC.
      Just when the panel looked like it was becoming a lovefest, the conversation took a stunning turn. We realized that the two sides of the panel had totally different ideas about what an NC really was. I approached the panel with the assumption that
an NC was the Ellisonian NC: a generic box, powered by a generic CPU with no local storage that runs machine-independent programs, assumed to be written in Java for a Java virtual machine. Given my recent columns on this subject, you can understand why Matt asked me to sit on the PC side of this discussion.
      The other side had an entirely different concept of an NC. They assigned the term to any device on a network that provides a "workstation," a screen, and a keyboard to the user. In fact, none of the NC advocates on the panel were using or promoting Java—they were pushing X Windows! X Windows terminals are NCs? Why not call a 3270 terminal an NC and be done with it!
      While I have never been one to sing the praises of NC, this was really too much. X Windows has its place, as does CP/M. Well, maybe not CP/M, but 3270s do. It's the glass-walled, raised-floor, mainframe-think that we all grew up with in the 1970s. But to call X Windows terminals NCs simply because they use Ethernet to communicate with the mainframe is to do a great disservice to the concept of the NC as it is more generally known.
      The beauty of the NC idea (if not the implementation) is twofold: maintainability and scalability. We have all heard the arguments for maintainability, centralized maintenance, lower cost of ownership, and all that. Here the X Windows guys do have the same arguments as the NC people. Centralizing things with thin clients, however defined, may provide a lower cost of maintenance. This point is debatable.
      The problem with the X Windows concept is that it does not provide what the NC does: scalability. The scalability of a constellation of NCs can bridge the gap between 3270 terminals and PCs and provide the NC its opportunity for marketplace success. In a mainframe environment or any network where the processing requests are centrally served, the capacity of the system can only be expanded by adding computing power to the central server. Using NCs, each workstation comes with its own processor. So for every NC added to the network, one "user's worth" of CPU power is added to the system automatically.
      The NC concept attempts to expand on the gains of the PC revolution. Intel and Motorola brought computers to the masses by dramatically lowering the cost per MIP of computing power. The microprocessor revolution literally put last year's mainframe power into this year's PC. The NC leverages the incredible power of the individual microprocessor by distributing computing power to each desktop.
      This lets the server act more like a PC network server—a place for centralized and maintained storage. Increasing storage on the server is as big an effort as increasing its processing power. Of course, the increase of storage requires some increase in server processing power just to maintain that storage, but it is nowhere near the power that would be required if the server ran the user applications centrally.
      This is the NC concept as I see it: distributed processing power combined with centralized storage. This is a great solution for some situations. In fact, I see NCs as a much larger threat to mainframes than to personal computers. NCs are tailor-made for replacing dumb and not-so-dumb terminals attached to mainframes.
      What NCs lack is what PCs provide: flexibility. Since mainframes never provided flexibility, this is not a factor in the NC encroachment into the mainframe space. However, centrally managed systems that require authorization from a single source to modify someone's desktop system will never be as flexible as PCs. (Some might argue that this is an advantage.)
      There are advantages in being able to isolate a desktop system from the network when someone needs to use software that hasn't been certified by the IS department. This is the inherent power and productivity multiplier of the PC. From the days when that first worker brought an Apple II loaded with VisiCalc into the office, the PC has been about enabling the individual. And isn't the individual the key to productivity?


From the January 1998 issue of Microsoft Interactive Developer.