What application models work/don't work in AWS
While AWS is a perfect fit for some application models, for other application models it would be inappropriate. Luckily, these models are among some of the older architectures. Let's look at each of them in turn.
One-Tier
Single-tier models, or the original green screen terminals, have been around for a very long time, and in some ways have already embraced the cloud model of hosting. In this model the main server is hosted elsewhere in a data center and is accessed through terminals, usually TTY terminals or text terminals. While on the surface these would seem a perfect candidate for cloud computing, the fact of the matter is that these systems were designed to run on one single monolithic computer system. The requirement for more capacity usually requires more CPUs, RAM, or even an upgrade of the entire backend server. So while we could run these systems in the cloud, they unfortunately would be unable to take advantage of the scalability inherent in the cloud.
Two-Tier
Two-tier models, or the original client sever models are inappropriate for migration to the cloud. One of the biggest issues today with cloud computing is the terms latency and bandwidth. Both of these terms relate to how fast the resources in the cloud can be accessed. In this model, the client runs locally on the client's computer system, so in a cloud environment the client would be constantly communicating with the server component running in the cloud. Unless the application was specifically designed to ensure that the data transfer was limited in scope, the performance impact of this design on the user would make this a bad candidate for migration into the AWS cloud.
An example of such a system would be a .Net application running locally on your computer, accessing a SQL Server database located in your corporate data center.
Three-Tier
Three-tier models are a grey area when it comes to the cloud. Moving only some of the components into the cloud can provide some of the same performance issues as two-tier applications. Moving all of the tiers to the cloud provides the greatest benefit. However, unless the presentation layer has been designed to minimize communication requirements, this again can be problematic. Most people take three-tier to refer to an application designed with a web server layer, an application logic layer, and a database layer, and in this specific instance of a three-tier application, the presentation layer is optimized for communication over slow or limited connections.
An example of a three-tiered system would be your local intranet or company web portal. Typically, an intranet application consists of just a web server and a database server. Moving just the database server to the cloud would result in database traffic being trafficked over the Internet connection to the cloud. Database traffic is not stateless and is verbose, which works fine on your local network, but results in frequent dropouts and errors when used on a slow or unstable connection. However, moving both the web server and the application server to the cloud results in the traffic being a stateless HTTP—a protocol designed specifically with the inherent unreliability of the built-in Internet.
N-Tier
N-Tier models suffer from the same issues as three-tier models. Unless all of the tiers are migrated to the cloud, communication delays between the tiers will be problematic. However, as in three-tier, if n-tier is taken to refer to a web-based application in which the application logic layer is broken up into differing sublayers, then also in this specific instance, the application is well-suited for migration to the cloud. However, be wary of security implications, as the single sign on component (or tier) may never be migrated into the cloud, and as such may be the one component that slows the entire system down.
However, Amazon does provide scalable database services such as SimpleDB, that can be leveraged once the application has been migrated.
Common issues across all architecture models
One thing you would have noticed in all of the models mentioned earlier is that while some components are scalable in certain architectures, some are not. In both the three-tier and the n-tier architectures, the application servers are able to be scaled sideways. However, our database was not!
What does this mean?
Well, it means that for all the scalability that the cloud provides, there will always be limiting factors. In the case of the Microsoft platform stack, our limiting factor is that SQL Server cannot scale sideways, only up. So our scalability is effectively limited by the size of our SQL Server infrastructure. Database scaling is a hot topic at the moment, and to explain what I mean by vertical versus horizontal scaling, let's look at how data is stored in SQL Server. In SQL Server, there is a single database stored on a single server. At this point in time, it is not possible to split a SQL Server database between servers, which is what is termed horizontal scaling. Oracle, however, does limited horizontal scaling with Oracle Real Application Clusters (RAC), but is effectively limited to a few servers. In general, the more horizontally scalable a database is, the greater reduction in functionality. An example of this is SimpleDB, which is highly scalable, but however, is relatively simplistic compared to SQL Server and Oracle.
So what would be an example of good cloud architecture?
A good architecture would allow for scalability at all tiers of the model, including the database tier. While this is not readily achievable using Microsoft SQL server, we can approximate this by using various techniques, which we will explain in chapters 8-10.
Note
While an ideal architecture involves scalability at all levels, in reality, this is rarely achieved.
So in summary, if you have an existing web application, this is definitely a good candidate for migration to the cloud. However, bear in mind that other applications that require a high number of computing resources are also great candidates. Just be sure that whatever application you decide to migrate, you look carefully at the types of communication required between your application hosted on the cloud, and the client interface running locally in your enterprise.
If you are thinking of developing a new application, ensure that your client has a web-based frontend and that your intermediate tiers are designed to scale sideways, so that when the time comes to migrate your new application to the cloud, you will have a successful migration experience.
Tip
Any application that is designed for the Web will usually migrate well to the AWS cloud.