Book Image

Amazon Web Services: Migrating your .NET Enterprise Application

By : Rob Linton
Book Image

Amazon Web Services: Migrating your .NET Enterprise Application

By: Rob Linton

Overview of this book

Amazon Web Services is an Infrastructure as a Service (IaaS) platform in the Cloud, which businesses can take advantage of as their needs demand. The Amazon Cloud provides the enterprise with the flexibility to choose whichever solution is required to solve specific problems, ultimately reducing costs by only paying for what you use. While enterprises understand moving their applications among infrastructure they own and manage, the differences in Amazon's infrastructure bring up specific business, legal, technical, and regulatory issues to get to grips with. This step-by-step guide to moving your Enterprise .NET application to Amazon covers not only the concept, technical design, and strategy, but also enlightens readers about the business strategy and in-depth implementation details involved in moving an application to Amazon. You'll discover how to map your requirements against the Amazon Cloud, as well as secure and enhance your application with AWS. This book helps readers achieve their goal of migrating a .NET Enterprise Application to the AWS cloud. It guides you through the process one step at a time with a sample enterprise application migration. After comparing the existing application with the newly migrated version, it then moves on to explain how to make the hosted application better. It covers how to leverage some of the scalability and redundancy built into the Cloud, and along the way you'll learn about all of the major AWS products like EC2, S3, and EBS.
Table of Contents (19 chapters)
Amazon Web Services: Migrating your .NET Enterprise Application
About the Author
About the Reviewers

Our sample enterprise application

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.

Rules of engagement

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

What will our sample enterprise application look like

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.


For more information on .ASP .NET MVC please visit the Microsoft website at

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

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

  2. Secondly, Microsoft is investing heavily in both .ASP Web Forms and MVC, and both are healthy, active communities.

  3. But thirdly, and most importantly, I'm going to show why a .ASP MVC application lendsitself much better to a cloud environment.


    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.

What will our sample enterprise application do

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'!


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