Introduction to AWS Security Services – Microsoft AWS

Two-tier model

The two-tier or client-server model is a slight advancement over the mono-tier model. In this setup, a client communicates directly with a server to access data. The client usually contains the application code and is often referred to as a thick client. This model introduced the concept of distributed computing but still had its limitations. For instance, if the server went down, the client would lose access to all functionalities tied to that server.

The following figure (Figure 6.2) represents a two-tier model where the application works as a client-server:

Figure 6.2 – Two-tier architecture

Three-tier model

Three-tier architecture is a more mature evolution of the two-tier model. It relies on a lightweight client, such as a web browser, and separates the code between a frontend and a backend layer. The backend is often called the business logic layer or the application layer. It handles the application’s core functions and communicates between the frontend layer and the data-tier layer. This separation allows for better security, as each layer can only interact with its adjacent layers and offers more straightforward scalability options.

The following figure (Figure 6.3) represents an example application deployed as a three-tier model:

Figure 6.3 – Three-tier architecture example

N-tier model

As applications continue to grow in complexity, they may require additional layers or tiers to handle various functionalities such as caching, queuing, and load balancing. This leads to an N-tier architecture, where N can be any number greater than three. Each additional tier can be independently scaled, providing more flexible architecture but also adding complexity in terms of management and monitoring.

Self-contained codebase

In monolithic architecture, the code base is a single, indivisible entity, even though it might be logically structured into different layers, such as the presentation layer (frontend) and the processing layer (backend). This makes version control simpler but poses challenges as the application grows. For example, a small change in one part of the code might necessitate rebuilding and deploying the entire application, which is both time-consuming and risky.