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.