Tackling Architectural Complexity with Modeling
Kevin Montagne, ACM Queue
"The ever-increasing might of modern computers has made it possible to
solve problems once thought too difficult to tackle. Far too often,
however, the systems for these functionally complex problem spaces have
overly complicated architectures. In this article I use the term
architecture to refer to the overall macro design of a system rather
than the details of how the individual parts are implemented. The system
architecture is what is behind the scenes of usable functionality,
including internal and external communication mechanisms, component
boundaries and coupling, and how the system will make use of any
underlying infrastructure (databases, networks, etc.).
It should be standard practice to research the architectural options for
new systems -- or when making substantial overhauls to existing ones. The
experiments should be with lightweight models rather than a full system,
but it is vital that these models accurately capture the evolving
behavior of the system. Otherwise the value of the modeling process is
diminished and may lead to erroneous conclusions. I typically start
by trying to understand the functional problem space in an abstract
fashion...
There are numerous technical modalities to consider when designing or
evaluating architecture: performance, availability, scalability, security,
testability, maintainability, ease of development, and operability. The
priority ordering of these modalities may differ across systems, but
each must be considered. How these modalities are addressed and their
corresponding technical considerations may vary by system component. For
example, with request/reply and streaming updates, latency is a critical
performance factor, whereas throughput may be a better performance
factor for flow-through message processing or bulk-request functionality.
Modeling is an iterative process. It should not be thought of as just
some type of performance test. Here is a list of items that could be
added to further the evaluation process. [Good design will]: (a) Use the
model to evaluate various infrastructure choices; these could include
messaging middleware, operating system and database-tuning parameters,
network topology, and storage system options; (b) Use the model to
create a performance profile for a set of hardware, and use that profile
to extrapolate performance on other hardware platforms; any extrapolation
will be more accurate if the model is profiled on more than one hardware
platform; (3) Use the performance profiles to determine if multiple
instances of the publisher (horizontal scaling) are likely to be required
as the system grows..."
http://queue.acm.org/detail.cfm?id=1862187