3-Tier Architecture in Azure Cloud: A Comprehensive Deployment Guide

This project demonstrates a robust and scalable 3-tier architecture deployed in Microsoft Azure, showcasing best practices for cloud infrastructure design. A special thanks to Piyush Sachdeva for hosting the #10weeksofcloudops challenge. This blog represents my take on the second week's challenge.The architecture provides several key benefits:

• Improved Security: Network segmentation through subnets and network security groups
• High Availability: Utilize VM scale sets and load balancers
• Scalability: Automatic scaling based on resource utilization
• Performance: Distributed application tiers with efficient traffic routing

The architecture follows a classic 3-tier model:

Web Tier: This is the user interface (UI) of the application. The web tier is responsible for interacting with the users and presenting the data retrieved from the app tier. In this case, it is built using React, a JavaScript library for building dynamic user interfaces.

Application Tier: The application tier handles business logic and data processing. It receives requests from the frontend and communicates with the database to retrieve or modify data.

Database Tier: The database tier is responsible for storing and retrieving the data required by the application. In this project, a MySQL database is used to store user data, application configurations, and other necessary information.

1. Lets start by creating a Resource Group for provisioning of resources.
   

2. Create a Virtual Network for the resource group.
   

3. Create Subnets for Web tier, App tier, and DB tier isolating the different tiers networks. Additionaly create subnets for the Bastion Host and ApplicationGateway which we will provision later.
   

4. Create Network security groups for the application tier, web tier and Bastion host of our architecture. We do this to add inbound security rules to control the network flow to the various tiers of the application.
   

5. For the Bastion Host, we provide access through SSH by allowing traffic through port 22.
   

6. Associate the Bastion NSG to the previosuly defined Bastion Subnet.
   

7. For the Web network security group, we will add port 80 and port 22 in the inbound rules to allow traffic through web and ssh respectively.
   
   

8. Associate the Web NSG to the Web subnet defined previously.
   

9. Now head to the App network security group and add port 22 for ssh access and port 4000 where our application will be listeining.
   

10. Associate the App NSG to the App subnet created previously.
    

11. For creating the Database server, we create the Azure mysql flexible server. Create a unique name for the Server name option.
    

12. Configure the server to choose appropriate sku for the database and also enable geo redundancy. We enable geo redundancy to provision high availability to the DB server in case of regional disruption to the servers.
    

13. Provision a standby server by allowing high availability to the DB server.
    

14. In the networking tab, select private access and select the vnet and DB subnet created.
    

15. Now we create an Application Gateway to allow public access to our web servers and also to load balance the incoming traffic from the web.
    

16. In the networking tab, we provide the Application gateway subnet provisioned previously which is a requirement for the application gateway.
    

17. For the frontend or the web tier access, let us create a public IP. From the frontend tab, create a new public IP.
    

18. In the backends tab, create a backend pool without providing targets for now. We will add the IPs of the Web Virtual machines after we provision them and install the frontend code to the VM.
    

19. From the configurations tab, we add a routing rule to the application gateway. Here we provide the Http protocol and port 80 to allow web traffic through the Application Gateway.
    

20. In the backend targets, create a backend settings by providing the following values.
    

21. Now we create the Bastion Vm, Web VM and App Vm. Select the resource group and provision a Ubuntu image which is available.
    Here we create the Bastion VM.
    

22. Now in the networking tab, we attach the vnet and Bastion subnet which we created previously.
    

23. Create the Web VM and App VM in the same format. Then attach the Web subnet and App subnet to their respective VMs.
    

24. Now we connect to the Bastion VM to access the Web VMs and App VMs for secure access. I have used a pair key value for the VMs created and have uploaded it to my azure cli. After that I have moved the key configuration to ~/.ssh/ and run chmod 400 'key_file_name'. After this access the VM by providing the key value with the ssh command.
    

25. Now we head to create the app and web tier with our application code. SSH into the AppVM by using the private ip provisioned for the VM. I have forked the github repo by Nishant Singh for the application code, web code, and configuration scripts. https://github.com/thakurnishu/10_Weeks_Of_CloudOps and checkout to week2 branch to get the steps to implement the app backend and web frontend code and also to setup the database

26. Modify the DBConfig.js with the values respective to your mysql DB server.
    

27. We also modify the server parameters to switch off require_secure_transport from the mysql server menu.
    

28. Also modify the sql host and add sql admin user name in the AppTier.sh config file before running the AppTier.sh script.
    

29. Now we run the AppTier.sh file to create the DB and also test the application. If we get response from the DB as follows, then the script ran successfully.
    

30. Now we create an Internal load balancer to balance the traffic from the frontend web-tier to the backend app-tier. From create a resource, name the internal load balancer and select internal as the type of load balancer.
    

31. Now for the frontend configuration, we add the web subnet.
    

32. Now for the Backend pool, we add the IP configuration of the AppVM for the app-tier part.
    

33. Now we add a load balancing rule where we can provide the frontend ip address and the backend pool which we created in the previous steps. We also must provide the ports for the frontend and the backend pool.
    

34. Now we log out of the AppVM and connect to the WebVM from the BastionVM.
    

35. We fork the same repo as before and checkout week2 branch of the repo.
    

36. Vi into the ./webtier.sh script and replace the REPLACE-WITH-INTERNAL-LB-DNS with the ip of the internal load balancer from the overview of load balancer created previously.
    

37. Now we run the ./webtier.sh script which will install the necessary applications to run the frontend code and start the frontend code on the WebVM.

38. Now since the WebVM is up and running, we can go ahead and add the IP address of the WebVM in the ApplicationGatway in the backend pool.
    

39. Now from the overview of the application gateway and copy the public IP address provisioned for the application.
    

40. Run the application on any web browser by using the public IP provisioned of the application gateway.
    

We have successfully provisioned a 3 tier architecture with secure access to all the tiers. Now in order to provide high availability to our architecture, we create a VM scale sets for the web-tier and app-tier.

1. Now since we have the three tiers running, we can move onto create availability sets to make the web tier and app tier highly availiable for high traffic scenarios. For this we need to create VM images of the WebVM and AppVM to create availiability sets. Select the WebVM and select the capture option to create VM image.
   

2. Create a compute gallery from the creation menu to store the VM image. Select specialised option so that we can get the image with all the preinstalled application which we created through the previous steps.
   

3. Create a VM definition with the details about the VM to save.
   

4. Repeat the same steps for AppVM and now we are ready to deploy the VM scale sets for high availiabilty. First, we create VM scale set for Web tier of the architecture. From create a virtual machine scale sets, set the name of the VM and also select multiple zones for high availity features.
   

5. Select unifrom option for orchestration and keep the instance count as 2.
   

6. Select out previously stored VM image to deploy for the VM scale set. Also configure the scaling to automatic. Set custom scaling options to maximum of 10 instances and increment of 1 instance when CPU threshold crosses 80% for 10 minutes.
   

7. In the networking tab set the Subnet to the Web subnet and in the network interface options, edit to change the default subnet to the web subnet.
   

8. As discussed previously, configure the scaling options according to a preset threshold criteria.
   

9. Now in the Application Gateway option, set the backend pool to now target the Web Virtual machine scale sets instead of the Web VM.
   

10. From the Web Virtual machine scales sets, select the instances and upgrade the instances to run with the latest changes by using upgrade option.
    

11. Create the App virtual machine scale set using the same steps. Now head to the internal load balancer and select App Virtual machine scale sets IP configuration for the backend pool.
    

12. Upgrade the App virtual machine instances to run with the latest changes by using the upgrade option.
    

That’s it! We have created a web application with a 3 tier architecuture, highly available and highly scalable. We also created network security rules to create secure access to all the application tiers. Many thanks to Nishant Singh for his detail blog which made this project possible. Also a big shoutout to Piyush Sachdeva's 10weeksofcloudops challenge. Please check out his youtube channel for some amazing cloud tech content.