High-volume e-Business transactions are putting new pressures on the corporate computing environment. Functionality and stability are no longer sufficient to provide a competitive advantage. Businesses must be able to deploy and adapt applications quickly to address rising workloads and changing business requirements. Data and applications must be integrated across the enterprise to improve efficiency, and the highest levels of performance and availability must be maintained to support business-critical processes.
The Challenge of e-Business Computing
Leading companies are accelerating their business cycles by establishing e-Business connections across their entire chain of customers and suppliers. The advantages are compelling. Information sharing, collaboration and transaction processing are more efficient. Costs are reduced, and each connected business can respond more quickly to new opportunities and market shifts. The growing maturity of applications for e-Commerce, supply-chain management and customer resource management is fueling this evolution by simplifying deployment and providing a faster and more substantial return on investment.
With these advantages come new IT challenges. Workloads escalate when customers and suppliers access applications that are linked to core business systems. Security must be tightened, and 24x7 availability is essential. At the same time, the performance of e-Business applications often has a direct and immediate impact on revenue and corporate credibility. Up-to-date application functionality is important, but business value is equally dependent on the flexibility, scalability and availability of e-Business services (Figure 1).
Meeting the Challenge with an N-tier Architecture
When business computing began to move from the mainframe to more affordable commodity machines, one would pick a given computer and “promote” it to server status by installing a database engine, some sort of code interpreter plus compiler, and develop software code that would then create the needed software tool. This meant that the user interface software (UI), the program itself, and the database would be running on the same platform (operating system and computer).
It was not long until the IT industry started realizing that things like distinct patching time frames from operating system and database engine manufacturers, recurrent common incidents, or even the need to update/upgrade components required urgent mitigation by having the processing and database tiers physically and logically split. Thus, Tier 2 architecture solutions started to be utilized.
As the internet became popular in the 1990s, it brought with it a revolution in terms of a user interface which was more performant and capable, but necessitated a specific web server. This widely empowered the proliferation of Tier 3 architecture in which the UI component was separated from the core computing and the database.
Definition of N-Tier Architecture
N-tier (or multi-tier) architecture refers to software that has its several layers rendered by distinct IT environments (tiers) under a client-server logic. The user interface (Presentation Tier) runs in a separate environment than the “computation” (Business Logic Tier) which in turn also runs in a distinct environment from the database engine and instances (Data Tier).
An N-tier design partitions application functionality into three independent layers, enabling easier integration with core business systems and other e-Business applications:
Layer 1: Presentation Logic—Typically hosted on front-end Web servers Layer 2: Business Logic—Hosted on mid-tier application or general-purpose servers Layer 3: Database Management—Hosted on back-end database servers
In effect, an independent application layer is added to the traditional 2-tier architecture. This additional layer has the effect of decoupling business logic from presentation and database functions, both physically and in the software architecture. The ramifications for software development and maintenance are particularly compelling. Customized code can be replaced with standardized APIs to interface business logic with presentation code and database access protocols. When properly implemented, the hardware and software for each of the three layers can be scaled and upgraded independently.
This partitioning also makes it easier to integrate new applications into the environment. Application code no longer has to be re-created when a new user interface is added, or when a transaction is linked with another application in the e-Business matrix
Shared services simplify development
Businesses can extend the benefits of the N-tier architecture even further by establishing standardized hardware and software designs at each tier. If properly implemented, this process leads toward the creation of a menu of shared services that IT can use in planning, designing and deploying new applications. The reuse of core components accelerates application development and integration, and reduces maintenance and support costs by simplifying the computing environment.
Businesses don’t have to create these standards from the ground up. The selection and deployment of an appropriate middleware stack can provide a robust platform for both off-the-shelf and customized e-Business applications, and contribute significantly toward a more standardized and agile infrastructure.
Best Practice Recommendation:
Become proficient at designing and deploying N-tier architecture. Partitioning presentation logic, business logic, and data management functionality will simplify upgrades and integration. During application development, push session management back to the database layer, to improve scalability at the front-end and middle tier
Deploy High-Quality Application Server Software (middleware). Proper implementation will reduce application development costs and help to standardize your e-Business environment
Scale Out at the Front-end. Redundant arrays of inexpensive servers (RAIS) can be scaled incrementally and affordably, and provide virtually unlimited levels of performance and availability.
Scale Out at the Middle Tier. With appropriate middleware, the advantages of scaling out can also be realized at the application layer. For best results, use middleware tools rather than the operating system to configure failover and clustering solutions.
Scale Up in the Back-end. Intel Pentium III Xeon processor-based servers configured with 8, 16, and 32 processors lead the industry in absolute performance, price/performance and compatibility for back-end applications. Larger configurations are available from specialized vendors. Servers based on the new 64-bit Intel® Itanium™ processor will soon extend Intel architecture solutions even further, to accommodate the most demanding of back-end applications—and to meet the extraordinary demands of next-generation e-Business.
Advantages of N-Tier Architecture
Scalability – having several separated components in the architecture allows easy scalability by upgrading one or more of those individual components. As an example, if the number of public clients grows that may require splitting the Webservice by adding new capacity to deal with the client demand which means more Web Servers on the Presentation Tier; another example would be an online shot that grows its product portfolio, in this case, the need to grow will most likely be in the Data Tier.
Enhanced Security – An architecture that is distributed by several tiers allows placing those in distinct security zones (both logic as well as geographic) in order to assure that each component is protected according to its core business criticality level. In the presented example, the web servers, although in a firewall-protected DMZ, have less need for security coverage than the application servers or database servers where all critical core business data is being processed or resides.
Resilience and Redundancy – Critical components can easily be split in tiers that are clustered and geographically split to ensure failover, hence a more resilient system.
Maintenance flexibility – As with the case of scalability, having distinct tiers allows pin pointed maintenance actions that do not produce collateral unwanted effects. This means that maintenance scheduling has fewer dependencies from 3rd party components.
Disaster Recovery – An N-Tier Architecture allows individual components to restore in case of partial service disruption being it severe or not, hence allowing shorter service recovery times. In the case of robust, redundant well-distributed systems (the likes of ones supporting Google, Amazon, PayPal, other) the restore activities are not even noted by end users’ due to the redundancy in place.
Developer Friendly Environment – Having the several coding layers split by distinct tiers allows developers to focus on their individual task without having to share resources or bear in mind collateral potential impacts in each other’s tasks/ domains. This is the type of architecture that also empowers frameworks and programming cultures like DevOps and Agile/Lean.
Disadvantages of N-Tier Architecture
Performance – It seems a paradox that having the several components split to allow better efficiency and performance may result in the risk of lower performance. This risk basically pertains to 3rd party components/services. Having the architecture distributed by distinct geographies and tiers means that the entire system becomes highly dependent on the I/O flow. If within a closed network (a LAN/ WAN) the critical element is the entire cabling, switching and routing infrastructure, whereas in the case of using cloud-based infrastructure the topic additionally consists of several ISPs, who’s individual communication infrastructure may not be synchronous in terms of performance.
Higher CAPEX and OPEX – adding components to the architecture means the need for additional initial investment, running maintenance expenses budget as well as support services. This is particularly of concern when not relying on cloud-based services.
[N-tier Architectures-Intel.pdf (iscte-iul.pt)](http://cadeiras.iscte-iul.pt/CDSI/fich/N-tier Architectures-Intel.pdf)