Factors Influencing
Future Application Architectures
We examine some of the technical issues surrounding client /
server architectures and their future. The Granularity Wall is the smallest addition of
hardware or software to the system that will increase processing power. This ultimatly
limits the scalability of the system. The speed of light is the ultimate limit to the
client / server architecture. The shortest round trip distance between the east and west
coasts of the United States takes about 480 milliseconds. We eventually are faced with the
processing / communications conundrum. We can design the system properly to reduce
latency, increase processor or communications capacity or redesign the system using a new
architecture that reduces granularity without increasing network capacity.
As the client / server architectures matures, what is its future? Will it remain as the
application architecture of choice or will another architecture emerge? If we would have
known of the power of the PC in its early days 15 years ago and the client / server
architecture 10 years ago, we would have designed and implemented systems differently. In
this the first of a series of reports we examine some of the technical issues surrounding
client / server architectures.
The Granularity Wall
Granularity is all about hardware or software elements. They are the smallest isolated
hardware or software entity in an application. A computer is usually the smallest element
in the hardware space. For software, the definition becomes more complex. It is usually
the program running on either the client or server. It can also result from the division
of a larger program into two or more smaller programs. Another term used for granularity
is scalability.
Why is it important? The smaller the granularity of the element, the more effective is
the addition of a new processing element. . Or, to state it another way, the smaller the
element’s granularity, the smaller the investment required to improve system
performance or maintain the system.
Hardware granularity it is the smallest addition of hardware to the
system that will increase processing power. For example, consider a system designed to
process a transaction on the server with the workstation performing basic, or even
advanced processing. As the workload increases, additional performance usually requires a
new, larger server (see Figure 1). This is potentially a large investment.
Original System
Expanded System
Single Server / Client Server Architecture
Figure 1
This architecture is simply the terminal / mainframe architecture has been used since
the advent of the computer terminal in the mid 1960’s. All that has changed is the
use of a smaller server in place of the mainframe.
If the client accesses multiple servers to spread the load, (see Figure 2), then the
server that experiences the maximum increase in activity needs to be upgraded.
Original System
Expanded System
Multi-Server Client / Server Architecture
Figure 2
In this example, with smaller granularity, only one server must be upgraded. Because
only one part of the system need be upgrades, its cost will be less than a client / server
system with a single server. As more servers are used to handle different functions, the
need for a major upgrade becomes less necessary. Only the overloaded server needs to be
replaced or upgraded.
The transition from the single to multiple server architecture is an example of
software granularity. The monolithic program running on the single server was decomposed
into three programs, each running on different servers. If the single program in the
application were not designed to be divided into smaller entities, the transformation to
the three program system could, potentially, have required a complete rewrite.
Clearly, the smaller the granularity, the less it costs to upgrade the system.
Nevertheless, this model comes at a significant cost. The client becomes the limiting,
central, active node. As more servers with smaller program elements are used,
communications play an increasingly important role.
Going at the Speed of
Light
Would you buy a disk drive with a seek time of 16 milliseconds? With many of
today’s hard dives operate with a seek time less than 10 milliseconds, the answer
would be no! Yet, the time it takes a signal to travel 5000 miles at the speed of light is
26 milliseconds. This is the shortest round trip distance between the east and west coasts
of the United States. Furthermore, it assumes the signal will travel at the speed of
light. Even in a fiber environment, there is speed attenuation. Satellites are even worse.
It requires 480 milliseconds to send a signal between the two coasts, about the same speed
as a 2X CD ROM (they are currently above 26X). This propagation latency is solely a
function of the speed of light.
As we add in the time required for the operation of the hardware, the communications
delay becomes a significant bottleneck, one that can not be simply solved with greater
bandwidth. Bandwidth is a measurement of the volume of information that can be sent along
the network (the diameter of a pipe), not how long it will take (the length of the pipe).
All higher bandwidth does is to deliver more data to the receiving computer when it
arrives If we use the pipe metaphor, the information is a plug that flows through the
pipe. The volume of a plug of information remains the same. In a high bandwidth
environment, the plug is like a wafer, wide and thin. In a low bandwidth environment it is
like a pencil, long and narrow.
We can see that the client / server architecture has a built-in latency inherent within
its design. While the amount may seem small, consider that a transaction processing system
operating at 1000 transactions per second requires 1 millisecond per transaction.
Twenty-six transactions could be processed in the time a transaction is simply in transit.
The Conundrum
We have seen the client / server architecture is limited in terms of granularity
(scalability) and network performance. Increasing granularity increases the communications
load. To some extent, we have substituted network capacity planning for processor
capactity planning. Users can discern delays of less than a second, the total performance
of a single client / server system. Not only will the resulting delays impact the user
interface, but may lead to a breakdown of the system under high loads. We have seen
examples of this in electronic stock trading systems on high volume days.
To solve these problems, there are solutions.
- Design or reimplement the system properly in order to reduce latency
- Increase processor or communications capacity.
- Keep all communications links under 2 miles (single site clustering).
- Redesign the system using a new architecture that reduces granularity without increasing
network capacity.
Action Items
Users – Examine current and future systems in order to reduce communication
latencies by placing servers closer to users. Limit the use of single "choke
points" by examining the replication of servers. If a single element, such as a data
base, is required, try to locate it at the center of its processing region. Design
software systems such that they can be split-up in order to operate on separate computers.
Vendors – Design applications to run in a modular environment. Consider alternate
architectures such as the workflow model which will be discussed in another report.
Entire contents (C) 1999 by Integrated Business Information Systems Ltd..
(IBIS, www.ibisl.com) All rights reserved. Reproduction of this publication in any form
without prior written permission is forbidden. The information contained herein has been
obtained from sources believed to be reliable. IBIS disclaims all warranties as to the
accuracy, completeness or adequacy of such information. IBIS shall have no liability for
errors, omissions or inadequacies in the information contained herein or for
interpretations thereof. The reader assumes sole responsibility for the selection of these
materials to achieve its intended results. The opinions expressed herein are subject to
change without notice. |