Amazon Web Services: Migrating your .NET Enterprise Application: Evaluate your Cloud requirements and successfully migrate your .NET Enterprise Application to the Amazon Web Services Platform

A Platform as a Service (PaaS) is a service where you do not manage the underlying infrastructure. An example of this would be Microsoft's Azure framework or Google's App Engine. The benefit of this approach is that you don't have to worry about things such as servers, networks or storage. The downside to this approach is that you have no control over how these services are integrated into your existing infrastructure, and in some cases this isn't even an option.

In this scenario, you would write your application and then deploy it into their controlled environment, letting the PaaS provider manage the underlying infrastructure.

A Software as a Service (SaaS) is a service, that provides an application, rather than a framework. Examples of this would be Microsoft Office Live and Salesforce.com, that provide online mail and collaboration services. SaaS services typically are pre-written and do not provide the ability to change minor things such as themes or branding.

AWS has been around for a while now, and was one of the first IaaS providers of any size in this space. But does that mean they are the best?

Well in my opinion, yes. While they are not perfect by any means, they have one thing which other IaaS vendors cannot match, and that is scale. The size of the compute capacity that Amazon provides is in the order of magnitude greater to their closest rival, which means the chances of you not getting capacity from the pool when you need it is that much less. AWS is also innovating, in my opinion, faster than their closest rivals; this means that if you are using AWS, those innovations become available as soon as they are released.

But AWS is not infallible.

Because AWS is the biggest, it is also the greatest in demand. This means that on occasion (rarely though) you may be denied new service requests within a particular availability region. Luckily though, your existing services will always run ok.

This means that you will still need to manage the growth of your cloud application in advance. If you think that because your application is in the cloud it is 'infinitely' scalable, then think again! Amazon—just like any other provider—still has to manage spare capacity at any given time. Too much, and Amazon is paying for capacity that will never be used, and too little, and they will run out just when you need it.

However, it is public knowledge that Amazon does not use AWS for their own bookstore. These resources are managed outside of the AWS envelope. So peak periods on the Amazon bookstore will never impact your AWS cloud applications. However, in general, Christmas will! So beware of peak periods, and manage your capacity in advance, just in case.

So what's driving you to read this book?

Well we suspect that you have heard and read a lot about the 'cloud', and you are interested in finding out how the cloud can benefit your organization. Certainly, you don't want to be left behind, and certainly the thought of getting your hands on as many servers as and when you need them is an attractive proposition.

You may be thinking of using the cloud only for development and test at this point, which is perfectly ok. This is much like how virtualization was initially used, and look how quickly that moved onto production systems.

You may have a brand new application ready for development and you find the thought of lock-in to Azure too restrictive.

But no matter what your driver is, it is now time for your enterprise to embrace cloud computing.

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 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 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 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.

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.

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.

The second decision will be whether you would like a Public Cloud or a Virtual Private Cloud (VPC).

A Public Cloud is a self-contained group of servers within AWS that is protected by the AWS firewall from all external connections (including those from inside your own network). The benefit of a public cloud is that AWS allows servers—that you choose—to be selectively presented to the outside world. An example of a public cloud would be the hosting of web servers, which are available to the general public.

A Virtual Private Cloud (VPC) is also a self-contained group of servers within AWS; however, these servers are, for all intents and purposes, on your own internal network. The way AWS handles a VPC is significantly different to a public cloud. IP addresses are under your control, rather that AWS's. Security between the enterprise and servers in your VPC is your responsibility, and AWS security groups do not apply within your VPC.

The technology behind AWS EC2 is based around Xen, a hypervisor virtualization technology used within many major organizations today. Xen provides an environment that allows multiple virtual instances to run in the same hardware environment, similar to VMware. Each instance has a measure of compute units to represent CPU and memory, which is guaranteed by the underlying Xen environment.

So now that we have our rules of engagement, where does that leave us?

Well, we have a 100 percent pure Microsoft web technology stack, using no proprietary technologies in the browser, which supports single sign on and is built using good design principles.

So what will our enterprise application look like?

Our enterprise application will be a fairly typical .ASP . Net application with one twist. Instead of using a .ASP Web Forms application, we will be using a .ASP Model View Controller or (MVC) application.

There are good design reasons for choosing a .ASP .Net MVC application, which are as follows:

So our application will look something like this:

Our enterprise application will have a network load balancer, which will forward to two IIS servers. These in turn will use a redundant pair of application servers, which in turn will communicate with a SQL server database set up in a mirrored environment.

So that's the general architecture, but what will our enterprise application be called and what will it do?

Well, let's make it something that would be typically used within an organization, but something that wouldn't already be catered for by an off-the-shelf product. That rules out time-sheeting, for example.

Let's assume that our company makes software widgets for the software services industry. So our company would need some way of displaying what software services the company makes, as well as some way for customers to buy services on an on-going basis. There would need to be a way to identify clients, and to enable clients to stop their services at any time.

Let's call our company 'The Widget Company', and let's call our application "Widgets are always available here" or 'Waaah'!

For the purposes of this book, we will assume that the actual payment and purchasing of these widgets are handled elsewhere.

Here is a screenshot of our enterprise application Waaah:

We have a login screen, a screen that shows us all of the available products, and a screen that shows us just the products that the user has selected. (These are actually the same screen but displayed slightly differently using a filter).