In this chapter, we will be introducing you to our sample enterprise application that we will be using to demonstrate our step-by-step migration to the AWS cloud. Our sample application is not a simplified example, but a fully architected working example of an enterprise application that could be running within your organization today. As such, we have set ourselves some rather strict rules of engagement to make sure that we don't cheat!
But before we describe our sample enterprise application, and here's a spoiler, we have named it "Waaah" for reasons that will become obvious in a moment. We will go on to describe what AWS is, and what it is not.
We discuss some of the things you should watch out for with AWS, and discuss in general the differences between what AWS offers, and what services Microsoft Azure offers.
In the last part of this chapter, we take a look at the common architecture styles today, and how well they fit into cloud-based offerings such as AWS. We look at issues which are common across them all, and propose a new architecture, that addresses some of these concerns.
Finally, we take a brief look at AWS itself. We look at some of the legal issues, we give a brief technical overview, and pose two questions that you will need to find answers for before you start.
AWS is an Infrastructure as a Service (IaaS) provider. This means that they provide basic services such as networking and storage, but don't provide higher-level services such as application engines, or for that matter SQL Server database services. (However, they do provide some interesting database services, which we will cover later in Chapter 8 - Chapter 10).
A list of the services AWS provides is:
Online Storage
Near-line storage
Servers (With base operating system pre-installed or with user-created images)
Messaging services
Alerting and monitoring
Simple message queuing
Database services
AWS is not a Platform as a Service (PaaS) provider or Software as a Service (SaaS) provider.
What are these?
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.
So why go with AWS when there are options out there such as Microsoft Azure, where the underlying infrastructure is managed for you?
In my opinion, the biggest reasons are flexibility and control. PaaS services effectively 'lock' you into their platform. Applications designed for a particular PaaS vendor are not transparently transportable to other PaaS vendors. This can be a feature and a curse. By locking into a particular PaaS vendor, you are able to customize your application to take advantage of those features that are PaaS-specific (such as Azure). But by the same token, if you're not happy with your PaaS provider, you have nowhere to go, and the PaaS providers know it!
By keeping your application technology agnostic, you have the flexibility to 'shop around' if you need to.
What is the biggest benefit of all?
If you don't like the Cloud model, or for some reason security changes within your company, you can bring your entire application back in-house at any time with minimal changes.
Note
IaaS providers such as Amazon AWS give you the opportunity to rollback your migration to the cloud at any stage and allow portability between providers.
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.
Tip
Also beware of instances which may shut down or IP addresses which change unexpectedly; AWS does not guarantee that your instance will always be available or that your IP address will always remain the same. You will need to design for these eventualities (something we will address as we progress through the chapters).
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.
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.
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.
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.
Let's take a moment to talk about some of the legalities of cloud computing. The biggest obstacle that you will encounter when moving to a cloud-computing model, is that of data security and protection.
There are some interesting things to consider here.
Firstly, let's look at how AWS is set up.
AWS hosts its servers in 'regions'. Te current AWS regions are:
US-East (Northern Virginia)
US-West (Northern California)
EU (Ireland)
Asia Pacific (Singapore)
As you can see, the four regions cross three separate country boundaries.
Note
When provisioning a resource within the AWS cloud, Amazon guarantees that your data will never leave the geographic region in which it was initially placed.
It is unclear as to what AWS will have committed to in terms of liability. What laws apply to data stored, for instance, in Northern Virginia? The AWS contract stipulates that the State of Washington will govern the AWS Customer Agreement, however, what does this mean for your data?
At this point, Amazon is reluctant to commit to anything other than their click-through agreement (http://aws.amazon.com/agreement), and this will be a big stumbling block for some organizations.
However, in November 2009, AWS completed a SAS70 Type II audit (http://aws.amazon.com/about-aws/whats-new/2009/11/11/aws-completes-sas70-type-ii-audit), and as such passes the requirements for the storage and management of customer details and credit card data.
Sarbanes Oxley and HIPAA are also both areas of interest in relation to cloud services. While Amazon does briefly mention both of these in its security papers, neither is addressed directly.
Note
If your organization deals with government or health data, please note that Amazon advises companies to obtain separate legal advice before hosting their applications within the AWS cloud.
Amazon has released a security white paper located at: http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf.
It's probably time we took a brief overview of how AWS is set up.
Each AWS region is broken down into availability zones.
Each availability zone shares nothing with the other availability zones within the same region. The upshot of this is that if there is a service outage within a particular availability zone, servers in the other availability zones will not be affected. However, the downside of this is than availability zone-specific items such as Elastic Block Store (EBS) disk, cannot be made available to other availability zones within the same region.
When migrating your applications to the AWS cloud, the first decision you will need to make is to select your region, and then your availability zone.
Tip
Picking the closest geographic region will ensure the lowest latency and best performance, however, note that there are minor price differentials between regions.
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.
Let me introduce you to our sample enterprise application, but firstly let us run through some of the rules of engagement for our sample enterprise application, and the logic and reasoning as to why we have chosen the application that we have.
Web-based: The application must be web-based. While there are certainly a large number of .Net applications designed today that are still 'thick clients', the move by enterprises in conjunction with Microsoft is to build web-based applications. In this case, the majority of the code runs on a backend sever, with just the presentation layer running on the client machines in a web browser. So our enterprise application will embrace the new Microsoft technologies, as would be expected if this were a new application built today.
Good design principles: The application must abstract the data, application, and presentation layers. Our enterprise application must adhere to good design principles as would be expected from an enterprise application.
Standard technologies: Our application will use off-the-shelf Microsoft technologies. While this isn't always the case, as most enterprise applications contain some third-party technologies, in the case of this example, we wanted to be sure that we were as 'vanilla' as possible and that the technologies were freely available from the Microsoft website.
Browser agnostic: Our candidate enterprise application must be browser and operating system agnostic, so no Internet Explorer-specific, or Windows-specific code on the client. We feel this is important, because even though your organization may be based around the Microsoft platform, the organizations that are your vendors and clients may not be.
No proprietary technologies: No use of proprietary technologies in the browser. By that we mean no use of Flash, Silverlight or any other technology, which will limit the adoption of your cloud application, for the same reasons as mentioned in the previous point.
Single sign on: Our application must support single sign on within an enterprise framework. This is mandatory for any modern enterprise application, and our cloud application is no different.
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.
Note
For more information on .ASP .NET MVC please visit the Microsoft website at http://www.asp.net/mvc.
There are good design reasons for choosing a .ASP .Net MVC application, which are as follows:
Firstly, an MVC style application adheres very well to good enterprise design principles, separating the data (model), application (controller), and web (view) components of the application.
Secondly, Microsoft is investing heavily in both .ASP Web Forms and MVC, and both are healthy, active communities.
But thirdly, and most importantly, I'm going to show why a .ASP MVC application lendsitself much better to a cloud environment.
Note
Chapters 8 - Chapter 10 show how we can take our application and make it better in the cloud!
On the backend we are going to use Microsoft SQL Server. This is Microsoft's enterprise database solution and an appropriate choice for our enterprise application.
For the application tier, we will be using C# .NET.
For the presentation tier, we will be using Microsoft's Internet Information Server (IIS).
For our authentication, we are going to use Microsoft Active Directory (AD).
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'!
Note
Waaah! is also the sound you will most likely be making when you get to the end of this book and discover just how much you have been missing out on by waiting so long to get on the AWS cloud!
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).
Over the course of this chapter, we have looked at how AWS shapes up as a cloud provider, discussed our sample application that we will use to show step by step how to migrate to the cloud, and (briefly) had a look at how AWS is set up.
In the next chapter, we will map the features of our sample enterprise application against Amazon's offerings, and introduce in more detail the features and services available in AWS.
