1. Home
  2. Training Library
  3. Serverless, Component Decoupling, and Solution Architectures (SAP-C02)

Architecture Basics


Course Introduction
Utilizing Managed Services and Serverless Architectures to Minimize Cost
Decoupled Architecture
Amazon API Gateway
Advanced API Gateway
PREVIEW11m 29s
Amazon Elastic Map Reduce
Introduction to EMR
Amazon EventBridge
Design considerations

The course is part of this learning path

Architecture Basics
4h 43m

Architecture Basics
A business application generally needs three things. It needs something to interact with users - often called the presentation layer -  it needs something to process those interactions - often called the logic or application layer - and it generally needs somewhere to store the data from that logic and interactions - commonly named as the data tier.


Okay, let's get started with some architecture basics. Now you need to be familiar with a number of technology stacks that are common to multi-tier solution designed for the associate certification. LAMP, MEAN, Serverless, and microservices are the most relevant patterns to know for the exam. So LAMP is a common tool stack used for building web services. And the acronym is made up of the first letters of the four components of that solution stack. So that's Linux operating system, the Apache web server, MySQL as a database, and the PHP programming language. MEAN is another evolving stack pattern, and that comprises Mongo DB as a database layer, ExpressJS, Angula JS, or NodeJS, which are JavaScript frameworks.


Then we have our serverless architecture patterns. And serverless functions can be very beneficial in multi-tiered designs. Generally using Amazon API Gateway and AWS Lambda to replace our logic tier. Now in microservice design, it's not so tied to the notion of tiers. So with microservice architecture patterns, each of the application components is decoupled and independently deployed and operated. However, we still often have tiers to consider with microservice architecture, especially when refactoring monolithic applications to run on microservices. But firstly, what do we mean by multi-tier architecture? Now, a business application generally needs three things. It needs something to interact with users, which often is called the presentation layer. It needs something to process those interactions. And that's often called our logic layer, or application layer, and it generally needs some way to store the data from that logic in that interaction. And that's commonly called our data tier. So these three services, the presentation, logic, and data are quite specialized. So they tend to be services or applications that just do those specialist things. Now the word tier means layers, and specifically, one of several layers or levels. A multi-tier architecture pattern means that these services, presentation, logic, and data are separated into tiers or levels. Now the concept of layers is a little misleading, as your technology tiers do not always sit in a hierarchy. They are not necessarily logical layers.


They tend to look like layers in architecture diagrams, a design doesn't have to have three tiers, they can be more or they can be less. It's common for web applications to have two tiers, for example. And there is no rule of thumb for how many tiers you should have in an architecture design. Multi-tier architecture provides a general framework to ensure decoupled and independently scalable application components can be developed, managed, and maintained separately. So layers can be scaled independently, and often can be managed by entirely different teams. But keep in mind that the actual services in these tiers can exist in parallel, and often in different availability zones or regions. Okay, let's make sure that we're clear on the concept of availability zones. And availability zones are distinct data centers located in different geographical locations, on distinct floodplains, and with independent power supplies, et cetera. AWS makes it possible to make our multi-tier designs highly available by distributing our application tiers across multiple availability zones. So what that means, is that each of your tiers, can be set up to run on up to four distinct availability zones. Multi-tiers, running across multiple availability zones, provides us with a highly available, scalable, resilient architecture. Now the first point to note here is that this highly available multi-tier architecture is quite complex. It is designed to be highly resilient.

About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.