Thursday, July 3, 2008

Scalability Principles

One of the most important aspects which should be considered about during you design the architecture of system is scalability. In the future, the requirement will be changed, the system will overload, the amount of user will be increased. If you don’t consider about the scalability of software system, you system is becoming rubbish.

Several days ago, InfoQ posted the useful article wrote by Simon, it was Scalability Principles. This article presented some principles and guidelines for building scalable software systems.

To build scalable software systems, you should try your best to decrease processing time. Thus the system can handle more user requests in the same amount of time. The article gave some strategies to achieve this goal.
* Collocation: reduce any overheads associated with fetching data required for a piece of work, by collocating the data and the code.
* Caching: if the data and the code can’t be collocated, cache the data to reduce the overhead of fetching it over and over again.
* Pooling: reduce the overhead associated with using expensive resources by pooling them.
* Parallelization: decrease the time taken to complete a unit of work by decomposing the problem and parallelizing the individual steps.
* Partitioning: concentrate related processing as close together as possible, by partitioning the code and collocating related partitions.
* Remoting: reduce the amount of time spent accessing remote services by, for example, making the interfaces more coarse-grained. Please consider the first law of distributed computing - don’t distribute your objects.

Scalability is inherently about concurrency. As Martin Fowler said in Patterns of Enterprise Application Architecture, concurrency is one of the most tricky aspects of software development. Whenever you have multiple processes or threads manipulating the same data, you run into concurrency problems. To handle the concurrency issue is very difficult, you have to consider many aspects, e.g. lock, resource contention, deadlock, concurrent transaction, etc. This article presented some simple principles that can help when building scalable systems.
* If you do need to hold locks (e.g. local objects, database objects, etc), try to hold them for as little time as possible.
* Try to minimize contention of shared resources and try to take any contention off of the critical processing path (e.g. by scheduling work asynchronously).
* Any design for concurrency needs to be done up-front, so that it’s well understood which resources can be shared safely and where potential scalability bottleneck will be.

In order to build a successful software system, you need to know what your goals and what you’re aiming for. Your design must meet not only the functional requirements, but also non-functional ones. Non-functional requirements include performance, security, scalability, interoperability etc. Before you build the software system, you need to know related information about non-functional requirements as early as possible.

You must keep test continuously in order to satisfy the non-functional qualities of a system.

Probably the most important principle for building scalable system is that, if you need your system to exhibit this characteristic, you have to design it in up front. Even you fulfill RUP or Agile methodologies, it is necessary still. At least, you should outline the overall view of the system architecture.

No comments: