dawright22/azure-VM-reference-arch-linux

---

N-Tier Architecture

Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.

Tiers are physically separated, running on separate machines. A tier can call to another tier directly, or use asynchronous messaging (message queue). Although each layer might be hosted in its own tier, that's not required. Several layers might be hosted on the same tier. Physically separating the tiers improves scalability and resiliency, but also adds latency from the additional network communication.

A traditional three-tier application has a presentation tier, a middle tier, and a database tier. The middle tier is optional. More complex applications can have more than three tiers. The diagram above shows an application with two middle tiers, encapsulating different areas of functionality.

An N-tier application can have a closed layer architecture or an open layer architecture:

In a closed layer architecture, a layer can only call the next layer immediately down. In an open layer architecture, a layer can call any of the layers below it. A closed layer architecture limits the dependencies between layers. However, it might create unnecessary network traffic, if one layer simply passes requests along to the next layer.

When to use this architecture

N-tier architectures are typically implemented as infrastructure-as-service (IaaS) applications, with each tier running on a separate set of VMs. However, an N-tier application doesn't need to be pure IaaS. Often, it's advantageous to use managed services for some parts of the architecture, particularly caching, messaging, and data storage.

Consider an N-tier architecture for:

• Simple web applications.
• Migrating an on-premises application to Azure with minimal refactoring.
• Unified development of on-premises and cloud applications.
• N-tier architectures are very common in traditional on-premises applications, so it's a natural fit for migrating existing workloads to Azure.

What we build

How to deploy

1. Open a cloud Shell from the Azure portal
2. Clone this repo by running this command:

git clone https://github.com/dawright22/azure-VM-reference-arch-linux.git

3. Change into the directory this created
4. Now copy and Run this command:

Terraform init

6. Now copy and Run this command:

Terraform apply

That's all Fokes! [to quote bugs bunny]

If you want to customise location or other componets then you can start playing with the Variables file to suit you.

To access the VM scale sets select the instance you wish to connect to and use the Bastion option as per these instructions https://learn.microsoft.com/en-us/azure/bastion/bastion-connect-vm-scale-set. Enter azureuser as the user and use the generated password from Terraform by running

terraform output password

in your cloud shell session.

Requirements

Name	Version
azurerm	=3.26.0
random	~>3.0

Providers

Name	Version
azurerm	=3.26.0
random	~>3.0

Modules

Name	Source	Version
app-gateway	./modules/app_gateway	n/a
bastion-host	./modules/management_tools	n/a
biz_scale_sets	./modules/biz_scale_set	n/a
networks	./modules/networks	n/a
private-lb	./modules/load_balancer	n/a
web_scale_sets	./modules/web_scale_set	n/a

Resources

Name	Type
azurerm_resource_group.rg	resource
random_password.password	resource
random_pet.name	resource

Inputs

Name	Description	Type	Default	Required
admin_password	Default password for admin account	string	""	no
admin_user	User name to use as the admin account on the VMs that will be part of the VM scale set	string	"azureuser"	no
app_gtw_ip	Name of the app gateway ip	string	""	no
app_gtw_sub	Name of the app gateway subnet	string	""	no
bastion_public_ip	bastion public ip	string	""	no
bastion_subnet_id	bastion subnet id	string	""	no
lb_sub	Name of the Lb subnet	string	""	no
resource_group_location	Location of the resource group.	string	"eastus"	no
resource_group_name_prefix	Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription.	string	"tf"	no
scale_set_sub	Name of the scale set subnet	string	""	no

Outputs

Name	Description
app-gtw-ip	n/a
application_gateway_name	n/a
bastion-ip	n/a
bastion_dns_name	n/a
mid_tier_lb_name	n/a
password	n/a
resource_group_name	n/a
subnet1_id	n/a
subnet2_id	n/a
subnet3_id	n/a
subnet4_id	n/a
subnet5_id	n/a