Design a Multi-Tier Solution
The course is part of this learning path
Single tier generally implies that all your application services are running on the one machine or instance. Single-Tier deployment is generally going to be a cost-effective and easy to manage architecture but speed and cost is about all there is for benefits. Single tier suits development or test environments where finite teams need to work and test quickly. Single tier can also suit very simple applications or small sites with low traffic demand which will benefit from the effective and economical resource utilization single tier allows
When should we consider a single-tier design?
Single tier generally implies that all your application services are running on the one machine or instance. So the benefit of a single tier architecture, is that we have everything in one tier. So potentially one instance or group of instances can run our entire application. The three tiers will be sharing the memory, process, and storage of that one machine or group of machines. And that is fine, when we just need a simple service, say, a dev or test environment that's not customer facing. Or we have a very small application that may not need to scale up or down to meet demand. However, keep in mind, to scale a single tier architecture, you are generally going to need to scale an instance or machine horizontally, i.e. you're gonna have to implement a bigger machine. Yes you can run single tier on multiple availability zones. So yes, a single tier architecture can be made more resilient by running it in AWS, and yes, you can put your single tier machine or instance into an auto scale group so that it effectively scales based on demand. However, the design flaw in doing that, is that you are not decoupling your services so that they can scale independently. That's the big benefit of running cloud services in a decoupled environment. So if you are asked to make that a single tier application highly available and fault tolerant, you will need to refactor it as a multi-tier architecture.
As a single tier design, you are going to have to have all your services on the same machine, using the same resources. Which can create an availability risk. If the server is down, then the entire application will be down. If availability is a requirement, you need a decoupled multi-tier architecture. If an exam scenario describes a very simple application that doesn't need to be highly available, and fault resilient, then running that application on a single tier architecture, may be a consideration. The key thing to remember is that the benefit of multi-tier architecture is that the tiers are decoupled, which means they can be scaled up or down to meet demand. And it is a major benefit of building applications in the cloud. If the presentation layer is suddenly hit with 100,000 user requests, that presentation layer can be scaled to meet that demand. If the application tier needs to run end of month report, and so it's very busy for two or three days at the end of the month, their application tier can be scaled up to meet their demand, and then scale back down to its usual operating level. Responding to this type of burst activity really suits cloud environments, and specifically suits AWS auto scaling, and more specifically auto scale groups.
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.