The Three-Tier Design

The model of a three-tier architecture was introduced in the late 1990s. This model design was an evolution from a two-tier architecture (client or server), that was developed from a monolithic (mainframe-based) architecture. The main focus of the Three-Tier Design Model is Application architecture such that, each application has its own unique architecture, which exists independently of any other application.

Web Tier

Web Tier is defined as the front end to the application. The function of a web tier is to accept the request from the users and pass on the request to the Application Tier and then take the response back from the Application Tier and present it back to the user. Then the format of the response is controlled at this tier, whether it is an HTML document, a CSV file, a PDF file, or some other format. Such that this tier has no direct access to the Database Tier, and it should be decoupled from any processes happening in the Application Tier or the Database Tier.

Application Tier –Application Tier is a middleware tier where the internal business logic resides. The application tier responds to requests from the Web Tier and has a direct communication with the Database Tier. The Application Tier operates and scales independently of the other tiers.

Database Tier – Database Tier is a back-end tier where the databases manage the state of the application. Database tier must be accessed by the Application Tier only. It processes requests from the Application Tier and provides responses back to the Application Tier.

Challenges of Three-Tier Architecture

Now for a global company an application runs an order management system. The application manages inventory, customer records, and orders in an integrated system.

Clearly system requirements must include flexibility to adjust to changing needs where, it must be scalable enough to handle variable customer loads. Therefore, to allow User Interface (UI) development it must have separate front-end and processing layers to be isolated from business logic programming. Also it must be cost effective and should be able to leverage native, cost-effective services such as elastic load balancing and Amazon S3.

The application should be secure and steps should be taken to make sure that all traffic is properly protected in transit as well as at rest. Such that all access is controlled and monitored at all times. Here, all critical data should be stored in durable, highly-available systems, protected against node failure.

Serverless Design – Reference Architecture

The continuous evolution in the application design continues, individual instances are replaced with container services. Such that the final abstraction replaced the container service namely serverless architectures. Now there are many variations of serverless architectures rather than assume a generic use case, therefore at a specific scenario that might be used by your operations team.

Challenges with Serverless Architectures 

Given any scenario, it is required to find a better way to track the number of outstanding security updates on our production fleet. A serverless solution would be ideal, since we would not be adding any servers to maintain and we would be paying for the compute time of the AWS Lambda functions.