Introduction to the 3-Tier Architecture

What is a 3-tier architecture?

The three-tier architecture is a standard architectural pattern that separates software into three logical and physical computing tiers. They are presentation, application, and database. Each tier is designed to handle specific responsibilities and can operate independently. The goal of this separation is to enhance scalability, availability, security, and maintainability.

Here’s a breakdown of each layer:

Presentation Layer:

The presentation layer is the layer that the user interacts with. It typically is what the user can see and click. Think of it as the face of the application. It usually comprises buttons to perform actions, forms to fill, colours, images, etc. Examples of these are the homepage of a website or the registration page. Or even the screens you see on your mobile apps.

Application Layer:

The application layer handles the business logic of the software. Imagine you are in a restaurant; there are waiters, and then there is the kitchen and chef. A waiter takes your order to the kitchen, ensures the chef processes it, and then brings it back. The waiter is like the presentation layer; he/she is the one you interact with. The chef is like the application layer.

The application layer is responsible for processing requests. It acts as an intermediary between the presentation and the database layer (which we will soon discuss). It performs and makes decisions based on pre-defined rules written in the code, then returns the result to either the database or the presentation layer. Examples are backend services or APIs.

Database Layer:

The database layer is responsible for storing and managing the application data.

Using the restaurant analogy, the chef needs to store meat, veggies, and perhaps spices. This could be in the refrigerator or on shelves. Whenever a customer places an order, the chef will get the materials from there and cook the food. After cooking the food, the waiter will take the food back to you.

The database stores all the application’s data. When a user makes a request that requires application data, the application layer fetches it from the database, performs the operations, and sends the feedback to the user. Examples are relational databases like PostgreSQL or non-relational databases like MongoDB.

Why Use a Three-Tier Architecture?

The three-tier architecture offers several advantages:

• Scalability: Each layer can scale independently based on demand.
• Security: By isolating the layers, sensitive data is better protected. It also helps with fault isolation.
• Maintainability: Changes in one tier can be made without affecting others.
• Flexibility: Different teams can work on separate tiers simultaneously.
• Performance: Load balancing can distribute traffic across multiple servers, reducing bottlenecks.

Why Use Terraform for Building a Three-Tier Architecture?

Terraform is a powerful Infrastructure-as-Code (IaC) tool that can be used to define, provision, and manage infrastructure efficiently. For this project, I chose Terraform for the following reasons:

1. Declarative Configuration: You define the infrastructure you want using code, and Terraform will provision that infrastructure for you.
2. Modularity: Infrastructure components can be organized into reusable modules, simplifying complex setups.
3. State Management: Terraform tracks infrastructure changes through its state file, ensuring consistency.
4. Multi-Provider Support: Terraform works with AWS, Azure, Google Cloud, and many other providers.
5. Automation: Terraform automates infrastructure provisioning, reducing manual errors and deployment time.

Understanding the Architecture Design

Here’s an overview of the architecture we’ll implement:

1. Presentation Layer (Frontend):
   • Resources:
     • Web servers in an Auto Scaling Group (ASG).
     • Load Balancer for handling HTTP/HTTPS traffic.
     • Security groups and Network ACLs (NACLs) for enhanced protection.
     • Public subnets for internet-facing traffic.
   • Purpose:
     • Serve web content and handle user requests.
2. Application Layer (Backend):
   • Resources:
     • Backend services in an ASG.
     • Load Balancer for internal communication between layers.
     • Private subnets for securing backend instances.
     • Security groups and Network ACLs (NACLs) for enhanced protection.
   • Purpose:
     • Process application logic and coordinate between frontend and database.
3. Database Layer:
   • Resources:
     • Relational databases in private subnets.
     • Security groups and Network ACLs (NACLs) for enhanced protection.
   • Purpose:
     • Store and retrieve data for the application.

Overview of the Terraform Code

The provided Terraform code is modular, reusable, and organized for clarity. Key highlights:

1. Resource Abstraction:
   • Resources like VPCs, subnets, and security groups are defined as reusable modules.
   • Modules are sourced from another GitHub repository: https://github.com/davidshare/terraform-aws-modules/
2. Variables and Maps:
   • Configurations for each tier (e.g., frontend, backend, database) are stored in variable maps. This approach:
     • Reduces duplication.
     • Makes the architecture flexible and scalable.
3. Dependency Management:
   • Dependencies between resources are managed automatically using Terraform’s resource graph.
   • For example, ASGs depend on launch templates, and subnets depend on the VPC.
4. Dynamic Configurations:
   • Many resources (e.g., subnets, scaling policies) use for_each or count loops to handle multiple instances dynamically.

Goals for This Tutorial

By the end of this tutorial, you will:

1. Understand how to provision a three-tier architecture in AWS using Terraform.
2. Learn the purpose and configuration of each resource involved.
3. Gain the ability to customize the architecture for different use cases.

The next part will dive into setting up the foundational infrastructure: VPCs, subnets, and gateways. These form the backbone of the architecture.