Windows: on the client or server?

As the Windows client environment has become richer and more powerful over the years, it has become more difficult to manage. Even on a stable and reliable version of Windows--meaning Windows 2000 or Windows XP--it can be difficult to keep track of all the stuff that accumulates on client systems.

There are two ways to deal with this problem. Network management software from vendors like Tivoli, Microsoft and NetIQ gives a network administrator tools to install applications, change system settings, manipulate files, and so on. These products are impressive, but extremely expensive and require a fair amount of expertise.

I think the more interesting approach is to move the applications from the clients onto servers. There are a number of names for this approach--from Web-based applications to server-based computing and thin-client computing--and many different ways to do it.

The main advantage of moving applications to the server is manageability. If the administrator wants to make changes to the application or users' settings, he or she need only make changes on the server where the information resides. Do this right and you should rarely, if ever, have to visit your client systems in order to support your users. And with so many fewer potential points of failure, there should be less support to perform.

The old, original way to move applications to the server was called client-server computing, a technique that's quite old as programming methods go. Client-server means that you have programs running on both the client system and the server, and they communicate. When you have a data entry program on a PC that stores its data in a database server--such as Microsoft SQL Server or IBM DB2--you're doing client-server computing. This was a big advance because there are performance and management advantages to centralizing functions in database and other application servers, but it did nothing to simplify the management of software complexity in client PCs. Quite the contrary--client PCs usually pick up some new protocol stacks in order to support such applications.

The rise of the Internet brought on Web-based applications. In this case, the application is turned into Web pages so that the client user interface becomes a web browser. In this case, with few exceptions, the application resides entirely on the Web server. In most cases Web-based applications are also client-server applications, but the client is the Web server, talking to a separate database server.

The advantages of this are huge, in that all the complexity is kept off the actual client system, which need only talk HTTP and HTML. Most of the performance burden is also kept off the client, and in most cases the communications, usually consisting of HTML and graphics, can be reasonably slim. The actual development languages are not HTML, but there are many mature options, such as Active Server Pages and Cold Fusion. The main disadvantage is that it usually requires a rewrite of non-web applications. Also, browser interfaces can be limiting. The ultimate server-based solution for Windows is a terminal server, either through Microsoft's Terminal Server or Citrix MetaFrame. With these products, normal Windows applications like MS Office run on the server, but appear to the user to be running on the client. In fact, the client system runs a relatively dumb terminal client program that displays screen image data sent from the server and sends back keystrokes and mouse events from the client to the server.

With a terminal server your users can run all the applications they are used to running and you get all the management advantages of server-based computing. Even the network load is very light. You can even run either product over a modem connection; it's not blazing fast, but it's perfectly usable. And the clients can be cheap, old, underpowered systems. With a Win95 Terminal Services client your clients can run Windows 2000 applications on the server. You will need gobs and gobs of CPU power and memory on the servers, but that's relatively cheap these days.

Many users will still want to run local applications, because some apps are inappropriate for Terminal Services. Graphics-intensive apps such as Photoshop or games (not a real issue for businesses) would be far too slow, having to move all their screen updates over the network. Both Citrix and Microsoft Windows Terminal Services let you do this, although Citrix's MetaFrame software makes it easier for administrators to set up an environment in which users can easily run applications both locally and on the server.

But if you have no such concerns, there's a way to make things even easier: Windows Terminals. Several companies, such as Wyse, sell devices that are dedicated clients for Windows Terminal Services or Citrix products. In a practical sense, they aren't computers at all. If something goes wrong with them, you can replace them with another unit and the user continues without missing a beat, because there is no state whatsoever on them.

On the other hand, cheap hardware is the one thing that makes me feel ambivalent about server-based computing. CPU power and memory are dirt-cheap these days, and using a server solution means you are ignoring all the power in your desktops.

But all things considered, the benefits of moving programs to the server are considerable. The whole Web services movement is the next generation of this, so you should expect to see more of it--and good for us.

Larry is the author of ADMIN911: Windows 2000 Terminal Services from Osborne/McGraw-Hill.

What's your opinion? E-mail Larry, or post your thoughts in our Talkback forum below.