Building for Production: A Guide to Deploying a 3-Tier App on Azure

Introduction In the early stages of learning cloud development, it’s tempting to just "make it work"...

Introduction In the early stages of learning cloud development, it’s tempting to just "make it work" and spin up a single server, host your database locally, and call it a day. But in a production environment, "working" isn't enough. It has to be resilient, secure, and scalable.

For my latest project, I took on the challenge of deploying a Book Review Application (Next.js, Node.js, and MySQL) on Microsoft Azure. The goal wasn't just deployment; it was a total architectural shift. I moved away from a "monolithic" mindset - where everything sits in one place, and transitioned into a distributed, three-tier architecture.

The Blueprint: Networking First The foundation of any robust cloud architecture is a well-segmented network. For this project, the network serves as the primary security boundary and traffic controller.

The VNet: A Spacious Foundation I chose the 10.0.0.0/16 CIDR block for the Virtual Network (VNet). This provides a massive pool of 65,536 private IP addresses, ensuring that as the infrastructure grows, whether by adding microservices, logging clusters, or staging environments; we won’t face address exhaustion or the need for a complex readdressing mid-migration.

Subnet Strategy & High Availability The architecture utilises 6 subnets distributed across 2 Availability Zones (AZs). By mapping a Web, App, and Data subnet to both AZ A and AZ B, we ensure that the failure of a single data center does not take down the entire application. This "N+1" redundancy is the gold standard for high availability.

NSG Logic: The "Chain of Trust" To enforce a "Zero Trust" model, I implemented Network Security Groups (NSGs) using a Chain of Trust logic. Rather than leaving ports wide open, traffic is strictly unidirectional and limited to specific roles:

• Web Tier: Accepts Public Traffic (Port 80) -> Talk to App Tier only.

• App Tier: Accepts Traffic from Web Tier (Port 3001) -> Talk to DB Tier only.

• DB Tier: Accepts App Traffic (Port 3306) -> Deny all other inbound.

The Compute Layer: Scaling the Tiers Presentation: The Front Door The frontend runs Next.js on Ubuntu LTS. I configured Nginx as a reverse proxy because of its superior ability to handle concurrent connections, manage SSL termination, and serve static assets efficiently, shielding the Node.js runtime from direct public exposure.

Application: The Private Engine The Node.js backend lives entirely in private subnets. To bridge the gap between the public web servers and these private backends, I deployed an Internal Load Balancer (ILB). This ensures that the application servers remain invisible to the public internet, receiving traffic only from the web tier via a private, internal IP address.

The Data Layer: Persistence & Resilience For the data tier, I utilized Azure Database for MySQL (Flexible Server). This managed service offloads the heavy lifting of patching and backups while providing enterprise-grade stability.

To ensure the data layer isn't a single point of failure, I enabled High Availability (Multi-AZ), which automatically maintains a synchronous standby replica in a different zone. Furthermore, I implemented Read Replicas to offload heavy query traffic from the primary node, significantly boosting read performance during peak loads.

Challenges & Debugging The Hurdle: During the initial setup, the Web tier was unable to reach the Node.js backend through the Internal Load Balancer, resulting in "502 Bad Gateway" errors.

The Fix: After diving into the logs, I discovered that the NSG on the Application subnet was blocking traffic from the Web subnet's IP range because I had forgotten to allow the Load Balancer's health probes. By adding a rule to allow AzureLoadBalancer service tag traffic on the application ports, the probes turned "Healthy," and traffic began flowing. This taught me that in the cloud, connectivity is as much about health probes as it is about firewall rules.

Conclusion Building this 3-tier architecture wasn't just about clicking buttons in a portal; it was an exercise in security, scalability, and resilience. This project sharpened my ability to design "failure-aware" systems and solidified my skills in networking and automated load balancing—core competencies for any Cloud/DevOps Engineer.

Check out the full source code here: [https://github.com/cloud4ajadi/book-review-app]