Google: Difference between revisions

3,240 bytes removed ,  4 years ago
Line 331:
 
*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.
ApplicationBackend tierApplication
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.
 
Application tier
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?