Click on our Sponsors to help Support SunWorld
Unix Enterprise by Harris Kern & Randy Johnson

Supporting the glass closet

Use the same processes and procedures on every distributed, business system server, regardless of its location.

July  1995
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

Experienced IT professionals suggest if users insist on client/server applications, they should expect less Reliability, Availability, and Servicability. The authors disagree, and say an organization's central IT group should extend the methods and procedures used in the "glass house" to include "glass closets" for distributed, mission-critical applications.

Mail this
article to
a friend

"The network is the data center?!" Skeptics jumped all over our little twist on Sun's trademark phrase, "The Network is the Computer," when we wrote our column extolling this theme in April 1995's Advanced Systems magazine. But keep in mind that in the 1980's one of Sun's competitors printed T-shirts that proclaimed, "The network is the network and the computer is the computer." Today that firm is, of course, dead. We think those who downplay the importance of the enterprise network face similar peril.

Why? The network is the key component in distributed, client/server computing. Starting with a sturdy enterprise network makes deployment of distributed systems a business, and not a technical issue.

Sun CEO Scott McNealy said recently, "You can ride your bicycle down a dirt road trying to traverse bumps and potholes, or you can implement an information highway and drive your automobile down it." If McNealy had a gospel at the recent SunWorld `95 it was one we've preached before: "Invest in your net."

RAS and networks
As we've written in earlier columns, it's up to the shepherds tending an enterprise's data center and supporting mission-critical applications to provide high Reliability, Availability, and Serviceability (RAS) regardless of the operating system and hardware used.

A few old-hands in the MIS game have suggested to us the notion that if users insist on client/server applications, they should expect less RAS. After all, the reasoning goes, since business needs change faster and applications are deployed quicker, the whole structure will be more fragile. If the levels of service are less than they were, guess what the end-user blames? You got it! The new technology!

At Sun, as we transition from mainframes to client/server computing, our top priority is to provide the same RAS we did as a mainframe shop. Users expect this, and since their apps and data are just as important as before, they deserve top-notch treatment.

We sell our department's disciplines to the business units constantly: "We can help. We know technology and know how to apply it to a business solution. We know support and the importance of RAS." We point out that it took the information technology industry 30 years to get data center processes right, so why ignore something that works?

The network is the what?
What does "The network is the data center" mean? We use the same processes and procedures on every distributed, production business system server, regardless of its location, as if it were located in our data center. These processes must be automated and standardized so the same staff can support the new distributed system.

We developed these processes and tools for use on every production server. (We've identified these tools and processes in our columns before). You can't just add more work to your staff's agenda, you must automate the way you do things. And, by the way, the end-user doesn't know these processes are running. They feel they have control of their environment but we have processes in place "behind the scenes" to support our RAS goals.

You might think of this as extending the glass house around the wide-area network. Our past articles have downplayed the fallacy that the data center will go away in this new distributed environment. By agreeing with this assumption then we can now define how to make distributed data centers work. We have the glass house (central data center) for central, mission-critical applications, and now we add the glass closet (remote server rooms) for distributed, mission-critical applications.

The glass closet
A glass closet is simply a server room, attached to the wide-area network, that can house mission-critical applications. At Sun, we don't put production servers in open offices, but instead tuck them away. Each building has at least one. Our server rooms may not enjoy conditioned power, special air handling, ping-pong tables, wet-bars, or raised floors, but each is secure and "owned" by a system administrator who reports to central IT.

We discussed the need for centralized control of the infrastructure before. At Sun, system administrators report to central IT. Why? That allows us to implement standards from the network down to the desktop. Controlling system administration is key to implementing standards.

Business units then chose which server room the distributed application servers are placed. We do not dictate where a server is located. If a server room has production, mission-critical application servers inside, then it can be designated a glass closet.

Central data center staff support each glass closet. Conversely, the central staff may contract with local system administrators when we'd like to run one of our production jobs in one of their glass closets. We'll work out an agreement for the local staff to provide backups and hardware support, for example.


Supporting remote glass closets
How in the world do we support remote glass closets with our central staff? Remember, we recommend the separation of desktop tool support from mission critical application support. System administration support desktop tools (i.e., spreadsheets, desktop publishing, and licensed, third-party tools), and the data center supports mission-critical applications.

Why? The data center staff knows what disciplines are required and how to provide high RAS, that's what they are paid to do! The process (or methodology) for supporting mission-critical applications in both the glass house and closet is the Client/Sever Production Acceptance (CSPA) process. This is the essential methodology we developed for successful transition from centralized mainframe to fully distributed without adding data center head count. (See ourAdvanced Systems column for June 1994, titled "Our No. 1 priority," which discusses the CSPA process). At Sun we refer to it as the UPA (Unix Production Acceptance).

The glass closet design offers business units a measure of control over their servers. Managers can observe, feel, and even smell their equipment if they desire. They can upgrade their system to meet their ever changing business needs. Last and least (from their perspective) they view our central staff as a help and not a hindrance.

And in the end...
To be successful in the 90's we in IT need to expect and support change (see our February 1995 Advanced Systems column "The IT/Unix revolution"). Re-engineering business process requires re-engineering IT. Just as we're installing ever more flexible computing systems, we need to improve customer service and satisfaction at lower cost.

This started happening as we moved from a central mainframe environment (where we were perceived as cranky, lethargic, and domineering) to a fully distributed model (where we are perceived as helpful and flexible) while still maintaining the disciplines we learned over the last three decades. We made it happen by implementing automated software tools and the new Production Acceptance methodology, which also helped us to re-engineer ourselves.

Click on our Sponsors to help Support SunWorld


What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: