In this post, I will share an analysis to one of the projects requested in the Cloud Engineer Academy as part of the study program.
Requirement
Develop a conceptual design for a cloud infrastructure supporting a web application.
List the core components, determine the scaling needs, and diagram the architecture.
Disclaimer
If you are looking for a specific solution with each of the elements required to implement this sort of architecture in AWS, please refer to: Designing an Architecture for a Web Application written by David Reyes Jr.
My perspective
I will take a different approach. I will analyze the request as it would come from a client’s perspective and guide you through the mindset and required considerations to solve this architecture proficiently.
Whenever possible, I will try not to name specific components. Instead of naming EC2 as a web server, I will refer to it only as a web server (Again, for that approach, check the post from David mentioned above).
Let’s start by creating a user story as it would be requested by a client:
I need to implement a web application available through the internet on a specific domain that consists of a frontend, a backend, and a database. It will serve thousands, if not millions of users, ensuring proper performance, high uptime, and cost-effectiveness with minimal operational overhead.
Which are the key elements in this requirement?
- A web application
- Comprised of three layers
- High web traffic
- Performance
- High uptime
- Cost-effectiveness
- Low operational overhead
We will review each one of them to identify how it affects our design.
Web application
The requirements for a web application exposed to the Internet are:
- We need to have a registered domain. If the client doesn’t have it, it will be required to buy it from a Domain Name Registrar.
- This domain needs to be configured in a Domain Name Server (DNS).
- For that, we will need to configure the DNS records to point to our systems.
- Our application needs to serve web content, so it will need a web server.
- As the application will be used by users directly, we can assume it will need an interface, i.e HTML + CSS (at minimum).
- This interface needs to be exposed to the Internet, so it will needs proper routing.
- As it will have different layers (Frontend, Backend, Database) we can assume with certainty it will be a dynamic website.
Security considerations
We need to consider at least encryption for data-in-transit. For this we will need to have a **SSL/TLS server certificate**. We will need to configure our service to use this certificate.
Three-tier web application
- We need to consider a presentation layer (Frontend) that will handle user requests and communicate with the application layer (Backend), which will handle the application’s logic.
- A database will serve as the data storage layer and will receive requests for data from the Backend.
A simple raw diagram would look like:
High web traffic and performance
For managing a high volume of traffic, our application needs to have enough resources for handling those requests:
- Each user request needs to be processed by a web server.
- This web server will receive a HTTP request and will return a HTTP response according to the application process.
- Web servers have a limit of how many requests they can handle, primarily determined by available memory and CPU resoruces.
- To handle more requests on a single server, we can add more memory and CPU. This is called vertical scaling.
However, this approach has several drawbacks:
- It introduces a single point of failure. If the server fails, the entire application becomes unavailable.
- It’s expensive, as more hardware or assigned resources come at a higher cost.
- During periods of low traffic, it leads to a large amount of unused resources, again increasing the costs.
- We are limited by the throughput and bandwidth of a single web server.
Given these limitations, a different approach is needed.
What about adding more servers to distribute the requests?
- These servers would likely be smaller in terms of memory and CPU, a strategy know as horizontal scaling.
- We will need a component that can receive user requests, distribute them to the available servers, and return the responses. This component is an Application Load Balancer.
Another important aspect to consider is the fluctuation in traffic. How can we handle varying traffic loads, from small amounts to sudden spikes?
- We will need an Auto-scaling component. This element manages the number of available servers based on site’s traffic.
- It is crucial to configure this auto-scaling component accordingly to define the minimum, desired, and maximum number of servers available according to the requirements. Then, auto-scaling needs to have a setup and needs to be context aware, responsive to traffic variations.
Ok, we got the web tier. What about the other layers?
The logic tier can be analyzed in a similar fashion. It needs to scale accordingly to manage the requests coming from the different frontend web servers. We cannot afford to have a bottleneck in our architecture.
The data tier requires a different approach. I am not going deeper on this as there are many possible solutions such as read replicas, in-memory cached content, database clusters, or even vertical scaling.
The crucial aspect to consider is that the data we’ll store and retrieve will likely be used by many different users of the app, so it needs to be centrally managed, synchronized, and highly available to users.
Let’s consider a practical example: Imagine a banking web application where you have $100 in your account. You access your account using 2 different devices. You prepare two transactions, each for $100, and press the transfer button simultaneously on both devices. Clearly, the system must never approve two transactions for $100 each when you only have $100 in your account.
This issue needs to be addressed from both a development perspective (transactions) and an architectural perspective. For our purpose, we will consider a data storage component capable of handling high traffic volume.
Our diagram will have more pieces. Also we can add múltiple users communicating with our system.
Uptime
When we mention uptime, that means how much time your application is up, even if a disaster occurs. It could be an application bug, a cyber attack or even a natural disaster. How your system is prepared to keep it up or restore after it went down? How much time passed to be up again? How much data did you lose?
Two different concepts to tackle this: disaster recovery plan and highly-available application.
I will not go in deep with these 2 elements but I will mention a couple of things.
We have 4 types of disaster recovery strategies sorted from the less costly but with higher restoration time (RTO) and greater data loss (RPO):
- Backup and restore. We make backups of our environments so we can recover from there.
- Pilot light. A limited amount of resources are available and in-sync with the original system.
- Warm standby. The whole system is replicated but with fewer resources to reduce costs.
- Active-active (Multi-site). An identical copy of the system is available and can be used almost immediately whenever is needed.
We can see a schema comparing the different strategies and their trade-offs.
And for high availability, we need to consider set our backup components (or system replicas as appropriate) in a different location as our main system. Also, we can consider in our auto-scaling component to manage different servers in different locations, so it can route traffic to healthy or available server whenever it needs and, in case of failure in one of the locations, the other one should be available.
We will not draw the whole backup components, as we can approach different strategies for the different tiers and also to keep a simple and legible schema. We will draw dotted lines to define different locations for our servers. We will call them “zones”.
Cost-effectiveness
In terms of costs, we need to consider using the minimum amount of servers to obtain the maximum performance. And those servers needs to have the minimum amount of resources so they could handle requests properly while reducing costs at the minimum. We can think of a scale where efficiency is on one side and cost on the other. They need to remain balanced. That is the sweet spot we are looking for.
Low operational overhead
In this final element of the analysis, a Cloud Architecture truly excels.
Cloud components significantly reduce operational overhead because we don’t need to manage hardware, maintain physical space, handle wiring, or ensure physical security, among others.
Taking a step further, Cloud serverless components and services mean we won’t have to worry about operating system patches and updates, installing software, or staying up-to-date with system maintenance.
Additionally, in many cases we can rely on cloud services to manage scaling, high availability, and performance, allowing us to focus more on developing and improving our architecture and applications rather than managing infrastructure.
Key Takeaways
- A web application even the simplest one will have many different components to function properly.
- For production environments, the Cloud Architect needs to consider performance, high-availability, costs, and fulfill the client’s needs.
- Cloud services will make our life much easier if we know how to use them proficiently.
- From this analysis, we can go deeper and start naming the components according to the Cloud Service provider we use.
And that’s it for now, please leave a comment, questions and stay in tune for future posts.