Tiers for a scalable architecture

Enterprise architectures need tiers so that a scalable integrated enterprise system can be built, says Sanjay Agrawal

As business grows and transaction loads on IT systems rise, it becomes difficult for solution architects to design or scale up existing infrastructure.

To accomplish this task successfully, a clear understanding of system architecture and its tiers is required. Business applications are normally deployed in one of the two types of architectures—II-tier and III-tier.

The initial architecture and its roadmap depend on factors such as ISV validation, customer requirement, and load characteristics. There are various layers that fit in these architectures; these are database, application, Web, and presentation. Most ISV solutions are deployed across these layers.

II-Tier Architecture

This consists of two tiers, one with database, application, and Web clubbed together in a single server. The second is a presentation layer, an end-user interface with a client side application piece that is deployed on a PC or workstation.

Many applications start with this architecture and move to a III-tier system as the system load increases to a higher level, or due to the requirement of varied levels of scalability at the database, application, and Web layers. Client-server ISV solutions also use a II-tier architecture. The Web layer may not always be present. ISV solutions with a Web layer may use a Web browser at the PC level. But applications without a Web layer may have some client-side user software.

III-Tier Architecture

The first or top tier has only a database layer residing on a single server. The middle layer has an application along with the Web layer on another server.

The third or bottom tier has the presentation layer, which is the same as a II-tier arrangement. There is another variant of this III-tier architecture where the Web layer is separated from the application layer and is deployed on an independent server. This results in database, application, and Web residing in completely independent servers.

III-tier is a highly scalable architecture and the most popular as it allows independent and efficient growth of all the three layers (database, application, and Web).

Scalability In III-Tier

Let’s look at the scalability of these layers in III-tier architecture in detail.

In enterprise architecture, there are two ways in which we can achieve scalability at each of the above mentioned layers—vertical and horizontal scalability.

Vertical Scalability

Vertical scalability means increasing computing resources within a server or replacing an existing fully-populated server with one that has a higher capacity. This approach may also be called a scale-up.

The most common processing architecture within a system is Symmetrical Multi-Processing (SMP), in which vertical scaling takes place. Here resources such as CPU, memory and I/O subsystems are added within a server to increase its power to accommodate greater loads and provide higher scalability.

Horizontal Scalability

In horizontal scalability, we add more servers in the corresponding layer, and these multiple servers work together to accommodate an increased load. These multiple servers are independent and have their own instance of an operating system as well as other software.

This approach is also known as scale-out. ISV software needs to be enabled to take advantage of independent or parallel servers. Each server in this horizontal approach can also be scaled vertically, if required, provided that expansion is possible within the server.

Let us look at possible scalability options at each of the layers—database, application, and Web.

Database-Level Scalability

Database-level scalability is possible vertically as well as horizontally depending on requirements. The majority of database implementations fall in the vertical scalability category.

Here a single server scales with additional system resources to the possible expansion limit of the server; for achieving high availability, another server is added in a fail-over cluster configuration where the second server is either passive or hosts a different database or some other software.

Some of the implementations have horizontal scalability with more than one server grouped together to form another type of cluster where every server in the cluster contributes to an operation (all the servers are active for the same database).

Here a high-speed interconnect links all the servers in the layer to ensure fast inter-server communication. Horizontal scalability requires ISV validation in most cases. As mentioned earlier, this can also involve vertical scalability within each server.

An example of such horizontal scalability is Oracle 9iRAC (Real Application Cluster), where the transaction load is distributed across multiple servers in cluster. Even a query can be divided across these servers if query parallelisation is possible. RAC will have supported features such as load balancing and fail-over across the nodes.

Application-Level Scalability

The application layer mostly avails of vertical scalability. Few applications support horizontal scalability. The ISV has to enable the application for parallel operation or horizontal scalability if required. This enablement is not a simple task as additional functionality may have to be built-in by the ISV to support the same in terms of load distribution, inter-server coordination, and fail-over. In case of horizontal scalability at the application layer, it is not mandatory to have the database layer also using parallel servers.

Applications running on a horizontal platform can still talk to a single database server. SAP R/3 is an example of horizontal application scalability where the application server can be scaled out to multiple servers. Users log in through the messaging server of Central Instance (CI), and in case of any of the application servers failing, users of that application server are logged out and re-log-in takes place through a surviving server. In such a solution, user load balancing is done by SAP’s CI.

Web-Level Scalability

The Web server layer is scaled horizontally in most installations. With thin server technology and blade servers, it is possible to add servers as and when required horizontally to accommodate more Web requests. There are software applications available to ensure load balancing and fail-over among horizontal servers. Most service providers follow this model. Vertical scalability is also used where a greater number of CPUs within a server allows more Web requests to be accommodated.

Do note that these layers can have absolute independent scalability with a combination of horizontal and vertical if desired.

The author is a Solution Architect with HP India