Reference Architecture — Web Application Hosting (Part I)
A brief step-by-step walk through in designing a model architecture for any (read “most”) web hosting applications.
Web Application hosting is one of the basic IT needs of most businesses today. Every company which seeks to gain a mobile presence and improve its web footprint needs to ascertain its web application hosting architecture.
As businesses transition towards the cloud with each passing day, what’s also important is the ability to leverage the benefits offered by cloud providers rather than simply lift-and-shift existing on-premise resources.
Amazon Web Services graciously offers us reference docs for specific use cases (refer above image) which includes the recommended architecture for web application hosting. You can find the pdf for further reference.
While Amazon’s reference document is pretty self-explanatory, it assumes reader’s prior familiarity with AWS services and doesn’t explain the flow of information from user to the servers and back.
The reference architecture provided in this blog has some minor tweaks to AWS provided architecture while also trying to explain how and why each component exists in the overall scheme of things.
Apologies for using non-AWS confirmed icons/symbols. I should have referenced before I started my Power Point presentation but I am too far down the lane now to roll back each and every icon. I will work on correcting them at some point in the future. Having said that, most of those icons are still pretty accurate and won’t confuse the reader to be mistaken for something else.
STEP-BY-STEP WALK THROUGH
REFERENCE ARCHITECTURE : WEB APPLICATION HOSTING
- Let’s assume we have a set of users, who want to access our web application over the internet. This user could be sitting anywhere across the world, trying to access your website/ web application.
2. Now, let’s assume the user has keyed in the website address or opened the application on his/her device. This triggers what is called as a “http request” that will be needed to be responded to.
Now, what happens behind the scenes is that, users like you and me only remember human-readable domain names (Ex: www.amazon.com). However, in the networking world, everything is just a device with a unique IP address(Ex: 10.184.255.255).
In essence, even the website the user is trying to access is also just a server with a unique IP address. Now, there needs to be a translation service(just like a telephone directory) that connects the human-readable website address to its equivalent IP address. That service is what is called as DNS.
DNS stands for Domain Naming Service.
AWS has its own flavor of DNS service which it calls as Route 53(the 53 is a reference to the DNS port number 53 that is exclusive to DNS).
So, we add Route 53 to the equation.
3. The next logical step would be for the http request to be routed to the web server. However, as pointed out, it would make sense for us to leverage the advantages of Cloud services to drive our business efficiency.
So, we add what is called as a Content Delivery Network to the equation.
Amazon’s CDN service is called “AWS CloudFront”.
A Content Delivery Network is a cluster of servers offered at what are known as “edge locations” around the world. These edge locations host cached versions or frequently accessed data as close to your end user as possible.
Imagine, your end user(customer) sitting in Germany. Your web application is being hosted on a server in North Virginia, USA. CDNs offer a cached version of the site to be hosted within servers located in Berlin so that your end German user doesn’t have any problems accessing the site(if only a slightly less responsive version of your web application).
CDNs also take some load off your actual cloud resources and can be used to host static web pages or frequently accessed data so that the redundant information is not fetched each time as new HTTP requests.
Ultimately, how you use a CDN is your strategy, but utilizing a CDN ticks the right boxes in our architectural requirements.
CDN it is!
4. The next logical flow of the HTTP request (in case the request couldn’t be satisfactorily resolved at the CloudFront itself) would be to establish a connection to the actual Cloud environment.
This is done, through what is called as an “Internet Gateway” in AWS parlance. The Internet Gateway(IGW) as its name indicates is a gateway that establishes a stable, resilient connection between cloud environments and the free, open world of the internet. In other words, any cloud environment that has an Internet Gateway attached can freely interact with devices connected to the internet.
On the cloud-end(in this case, AWS), the cloud network is distributed across what are known as Regions, Availability Zones. A good example would be Canada. Canada constitutes to what is called a “Region”. Within the Canadian “Region”, there are multiple Availability Zones that physically host the servers that run your web applications.
AWS Regions and Availability Zones exist to distribute workloads in cloud environments across physical environments and avoid a single point of failure. A good web application architecture will leverage the benefits of multiple Regions/Availability Zones.
From a networking perspective, we have what are called as Virtual Private Clouds(VPC). A VPC is a logical network instance of the cloud. Think of it as your profile on Facebook. By signing up for Facebook, you don’t own Facebook as a company. You only own the photos, videos and content you’ve uploaded to your account and everything within your account. Similarly, a VPC hands you the control to all servers, databases and all other infrastructure resources deployed within your AWS account.
As a thumb rule, a single VPC is limited to one Region and cannot span multiple regions.
Our architecture with a VPC and an IGW attached below would look like this:
5. As mentioned earlier, any good architecture would leverage the use of regions and availability zones in order to have business resilience that can serve web content to its users in spite of physical disasters.
Taking that approach forward, our architecture will have at least 2 Availability Zones within the Region. The idea being that, one AZ can serve as a backup in case of failure of the other. You are of course, free to choose additional AZs if needed(and if offered by AWS within the region you chose).
The network equivalent of this design would be what are called as Subnets. Since, VPC is the network equivalent of a Region, a Subnet is the network equivalent of an Availability Zone. As again, a Subnet can’t span multiple AZs and must be limited to one AZ.
It is within each of these Subnets, that we deploy our n-tier architecture.
This concludes Part I : Reference Architecture : Web Application Hosting.
For Part II, click here