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.
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.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.