🚀 Building a 3-Tier Web Application on Azure — My Hands-On Journey

When I started this project, my goal was simple: 👉 Understand how real-world applications are deployed in the cloud.

But as I went deeper, I realized this wasn’t just about deploying an app — it was about designing, debugging, and thinking like a Cloud/DevOps engineer.

🌱 Getting Started

I began by planning the architecture. The application follows a 3-tier structure:

• Web Layer (Frontend)
• Application Layer (Backend)
• Database Layer

To implement this on Azure, I first created a Virtual Network (VNet) with the address space:

10.0.0.0/16

Then, I divided it into 6 subnets:

• Web Tier → 10.0.1.0/24, 10.0.2.0/24
• App Tier → 10.0.3.0/24, 10.0.4.0/24
• DB Tier → 10.0.5.0/24, 10.0.6.0/24

This separation helped me clearly isolate each layer.

🔐 Securing the Architecture

Next, I configured Network Security Groups (NSGs) to control traffic:

• Web Tier → allowed HTTP (80) and SSH (22)
• App Tier → allowed traffic only from Web Tier on port 3001
• DB Tier → allowed MySQL (3306) only from App Tier

This was my first real understanding of how secure communication works between layers.

⚙️ Setting Up Compute & Database

After networking, I moved to compute:

• Created a Web VM (public) for frontend
• Created an App VM (private) for backend
• Set up Azure MySQL (Flexible Server) in private subnet

For outbound access from private VM, I configured a NAT Gateway.

🔁 Load Balancers — Making It Real

This is where things started to feel like real production architecture:

• Public Load Balancer → handles incoming user traffic
• Internal Load Balancer → routes traffic to backend

Flow looked like this:

User → Public LB → Web VM → Internal LB → App VM → Database

🌐 Deploying the Application

I deployed:

• Frontend → Next.js (running behind Nginx on port 80)
• Backend → Node.js (running on port 3001)
• Process Manager → PM2

Nginx acted as a reverse proxy, forwarding:

• / → frontend
• /api → backend via internal load balancer

🚧 Challenges I Faced

This is where the real learning happened.

Things didn’t work smoothly at all 😅

• Nginx showed default page instead of my app
• APIs were failing with 504 Gateway Timeout
• Books were not loading
• Some requests returned 404 errors
• Frontend was calling localhost instead of backend

At one point, everything looked correct, but nothing worked.

🛠️ How I Solved It

Instead of guessing, I started debugging step by step:

🔍 1. Tested backend directly

curl http://localhost:3001/api/books

👉 Confirmed backend is working

🔍 2. Checked connectivity between layers

• Verified Web VM → App VM communication
• Fixed NSG rules (allowed port 3001)

🔍 3. Fixed Nginx routing

Updated config to correctly forward /api requests to Internal Load Balancer.

🔍 4. Fixed frontend API issues

• Removed localhost
• Used /api/... routes
• Avoided duplicate /api/api paths

🔍 5. Rebuilt frontend properly

npm run build
pm2 restart frontend

🎉 Final Result

After fixing everything:

• App loaded successfully through Public Load Balancer
• Backend worked via Internal Load Balancer
• Database connected securely
• Users could register, login, and view books

That moment when everything worked… 👉 honestly felt like a big achievement 🔥

💡 Key Learnings

This project changed how I see development:

• It’s not just about writing code
• Networking and configuration matter equally
• Debugging is the most important skill
• Small mistakes (like wrong API path) can break everything

Most importantly:

👉 Real learning happens when things don’t work.

🙌 Final Thoughts

This project gave me confidence that I can:

• Design cloud architecture
• Debug real-world issues
• Understand how applications run in production

And now, I’m even more excited to explore Cloud and DevOps roles 🚀

3 — Tier Architecuture Diagram for Book Review Application

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this Discord community ( https://discord.pravinmishra.com/ ).