Google: Difference between revisions
Content added Content deleted
Line 331: | Line 331: | ||
*3-tier network design in public cloud. How do you design? |
*3-tier network design in public cloud. How do you design? |
||
Front End Application |
|||
A 3-tier application architecture is a modular client-server architecture that consists of a presentation tier, an application tier and a data tier. |
|||
⚫ | |||
The data tier stores information, the application tier handles logic and the presentation tier is a graphical user interface (GUI) that communicates with the other two tiers. |
|||
Database |
|||
The three tiers are logical, not physical, and may or may not run on the same physical server. |
|||
'''You need LoadBalancer''' |
|||
Presentation tier |
|||
This tier, which is built with HTML5, cascading style sheets (CSS) and JavaScript, is deployed to a computing device through a web browser or a web-based application. |
|||
The presentation tier communicates with the other tiers through application program interface (API) calls. |
|||
⚫ | |||
The application tier, which may also be referred to as the logic tier, is written in a programming language such as Java and contains the business logic that supports the application’s core functions. |
|||
The underlying application tier can either be hosted on distributed servers in the cloud or on a dedicated in-house server, depending on how much processing power the application requires. |
|||
Data tier |
|||
The data tier consists of a database and a program for managing read and write access to a database. |
|||
This tier may also be referred to as the storage tier and can be hosted on-premises or in the cloud. |
|||
Popular database systems for managing read/write access include MySQL, PostgreSQL, Microsoft SQL Server and MongoDB. |
|||
*Benefits: |
|||
Modularity |
|||
Teams can focus on different tiers of the application and changes made as quickly as possible. |
|||
Helps us recover quickly from an unexpected disaster by focusing solely on the faulty part. |
|||
Scalability: |
|||
Each tier of the architecture can scale horizontally to support the traffic and request demand coming to it. |
|||
Can be done by adding more EC2 instances to each tier and load balancing across them. |
|||
High Availability: |
|||
With the traditional data centre, our application is sitting in one geographical location. |
|||
With AWS, we can design our application in different locations known as the availability zones. |
|||
Fault Tolerant: |
|||
We want our infrastructure to comfortably adapt to any unexpected change both to traffic and fault. |
|||
This is usually done by adding a redundant system that will account for such a hike in traffic when it does occur. |
|||
So instead of having two EC2 instances working at 50% each, such that when one instance goes bad, the other instance will be working at 100% capacity until a new instance is brought up by our Auto Scaling Group, we have extra instance making it three instances working at approximately 35% each. |
|||
This is usually a tradeoff made against the cost of setting up a redundant system. |
|||
Security: |
|||
Application will communicate within themselves with a private IP. |
|||
The presentation (frontend) tier of the infrastructure will be in a private subnet (the subnet with no public IP assigned to its instances) within the VPC. |
|||
Users can only reach the frontend through the Application Load Balancer. |
|||
Backend and Database tier will also be in the private subnet because we do not want to expose them over the internet. |
|||
We will set up the Bastion host for remote SSH and a NAT gateway for our private subnets to access the internet. |
|||
*Will you need LB? Why? |
*Will you need LB? Why? |