Having worked with the Windows Azure Platform since 2008 it’s easy to forget some of the initial hurdles I ran into and assume that others won’t have the same challenges. Of course, any time you assume anything you risk being wrong. Rather than assume you won’t run into the issues I did, I thought it would be good to review some of the lessons I’ve learned over the years and share what I’ve learned. In the first lesson I wrote about Windows Azure billing. In this lesson, I’ll look at running multiple web sites with Windows Azure.

Many people I talk to who are interested in using Windows Azure to host their web sites, but don’t know much about the platform tell me something like this:

“Well, we’ve looked at using Windows Azure, but the annual cost to host our four web sites is way more than we’re paying with our current hosting provider.”

To which I reply:

“OK. Let’s take a look at how you determined your Windows Azure cost.”

We’ll spend some time white boarding the solution they’ve put together, and it typically looks something like this:

azure-mult-sites-00-initial-solution

In this case, we have a company that has four web sites. The company thinks that they need to run each web site in it’s own web role, and that they need to have at least two instances of each web role to get guaranteed SLA’s from Microsoft. The math to determine monthly costs from the company’s perspective is pretty simple:

Sites

 

Servers/Site

 

Hours

 

Rate/Hour

 

Total

4

x

2

x

720

x

$0.12

=

$691.20

In fact, if we use the Windows Azure pricing calculator, we get the same thing:

azure-mult-sites-01-cost

At nearly $700/month it’s hard to argue against the client’s case that Windows Azure is just too expensive. It’s at this point in the conversation I’ll ask this question:

“Did you know you can run multiple web sites in a single web role?”

I’ll then take to the whiteboard and draw something along these lines:

azure-mult-sites-02-alt-a

I’ll then do the math:

Servers

Hours

Rate/Hour

Total

2

x

720

x

$0.12

=

172.80

As well as verify using the Windows Azure pricing calculator

azure-mult-sites-04-alt-a-cost

This will usually raise some eyebrows. The Windows Azure champions at the client will say:

“See! I told you we could save money! Let’s do it now!”

That statement is usually tempered by someone else in the room who will respond with:

Well, that’s nice and all, but we don’t want traffic from our marketing site affecting performance of our other sites.”

Based on the last requirement of not letting the marketing site affecting the other sites, we can use a deployment that looks like this:

azure-mult-sites-03-alt-b

The math:

Servers

Hours

Rate/Hour

Total

4

x

720

x

$0.12

=

345.60

As well as verify using the Windows Azure pricing calculator

azure-mult-sites-05-alt-b-cost

What’s the point of all this? Simple, Windows Azure isn’t a one size fits all solution. You can mold the platform to your needs rather than having to retrofit an exiting solution to the demands of the platform. As a result, it’s very easy to slice and dice your applications to get the performance and scalability your business needs while keeping costs in line.

The only secure computer is one that’s unplugged, locked in a safe, and buried 20 feet under the ground in a secret location… and I’m not event too sure about that one. – Dennis Huges, FBI

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards – and even then I have my doubts. – Eugene Spafford, Purdue University Professor of Computer Science and Executive Director of CERIAS

As the above quotes indicate, and as you’re hopefully aware, simply by turning a computer on you open it up to risks. Connecting it to a network opens it up to even more risks. Connecting it to the internet opens it up to even greater risks still. Because of these risks it’s more important for you to consider the deployment topology of your applications and where the vulnerabilities lie. In this post I’ll talk about an enhancement made to Windows Azure SQL Database to give you finer grain control over who gain access your data.

When it comes to securing your Windows Azure SQL Databases, Microsoft has done some of the heavy lifting for you. Prior to the June update to the Windows Azure platform, you were able to secure your databases at the server level by specifying firewall rules. These rules filtered granted/denied connections based on the client’s IP address. The result was something like this:

 

sql-database-firewall-00-server-fw

You can configure these server levels rules in the portal. Alternatively, and much more to a DBA’s liking, you can also use some system views and stored procedures to view, create, update, and delete server firewall rules. These objects are available in your server’s master database. Here’s a rundown of what you can use:

  • System view sys.firewall_rules will display the server’s current firewall rules.
  • System extended stored procedure sys.sp_set_firewall_rule creates or updates a server-level firewall rule.
  • System extended stored procedure sys.sp_delete_firewall_rule deletes the specified server-level firewall rule.

While Windows Azure SQL Database server-level firewall rules were a good first step, they weren’t quite good enough. The problem is that server-level rules are an all-or-none proposition. If a client IP address has access to the server, then the client has access to any database on the server. Of course you can, and should, use SQL authentication to harden your databases, but that won’t prevent a decent hacker from trying to brute force his or her way into your database once server access is gained.

In the June update to the Windows Azure platform, Microsoft introduced another layer of security to SQL databases. This layer is the database firewall rule. With this level of security you can now filter traffic to specific databases on a given server based on client IP address. The result looks something like this:

sql-database-firewall-01-db-fw

In this scenario I’ve created a database-level firewall rule for database three. As a result, even if a client is able to access the server where database three resides, unless the client’s IP address is accounted for in the database-level firewall rules, the client will not be able to access the database.

Currently you cannot configure database-level firewall rules in the portal. However, just like server-level rules, you can take advantage of system views and stored procedures to view, create, update, and delete server firewall rules. These objects are available in your server’s master database. Here’s what you can use:

  • System view sys.database_firewall_rules will display the current firewall rules for databases on the server.
  • System extended stored procedure sys.sp_set_database_firewall_rule creates or updates a database-level firewall rule.
  • System extended stored procedure sys.sp_delete_database_firewall_rule deletes the specified database-level firewall rule.

{Analysis}

Apple

Microsoft

Sencha

Xamarin

{Analysis}

Amazon

Apple

Cloud Foundry

Force.com

Microsoft

Rackspace

It seems I get 5-6 emails per week asking me how to move an existing ASP.NET MVC Web application to the Windows Azure environment. I have a short list of steps I’ve been copying and pasting into my responses, but I thought I’d take a couple of minutes to expand on those bullet points and make my answer a little more permanent by putting it on my blog.

Step 1 – Make sure you have the latest Windows Azure SDK for .NET installed. You can get it here: https://www.windowsazure.com/en-us/develop/net/.

Step 2 – Open your ASP.NET MVC project in Visual Studio. Here’s what mine looks like:

azure-convert-00-initial-project

Step 3 – Add a Windows Azure Cloud Service to the solution

Here’s where we actually have to start doing some work.

First you’ll need to right-click on your solution and select Add and then select New Project

azure-convert-01-add-project

In the Add New Project dialog make sure the target framework is set to .NET Framework 4, select Cloud project types, then select Windows Azure Cloud Service, give the new project a name and click OK.

azure-convert-02-cloud-service

In the New Windows Azure Cloud Service dialog, don’t add any roles, just click OK.

azure-convert-03-roles

You should end up with a solution that looks something like this:

azure-convert-04-solution-with-service

You’ll want to make sure your Windows Azure Cloud Service project is set as the StartUp project for the solution. If the title of the Windows Azure Cloud Service project is bold in Solution Explorer you’re good to go. If it isn’t, simply right-click the project and select Set as StartUp Project.

azure-convert-05-startup-project

Step 4 – Adding a Web Role

We’re almost done. The last thing we need to do is associate our current ASP.NET MVC application with the Windows Azure Cloud Service project.

Start by right-click the Windows Azure Cloud Service project and selecting Add, then select Web Role Project in solution…

azure-convert-06-add-web-role

In the Associated with Role Project dialog, select your ASP.NET MVC project and click OK.

azure-convert-07-select-project

Your ASP.NET MVC application should now appear as a Role in your Windows Azure Cloud Service project.

azure-convert-08-final-solution

Run your application and note the URL.

azure-convert-09-url

If everything was done correctly, your URL should be http://127.0.0.1:81/. If it is your running in the Windows Azure Compute Emulator, which means you were successful!

If you’ve made it this far you know that there were really only two steps involved in the process, and those weren’t even that difficult. Keep in mind that just because it’s easy to convert your ASP.NET MVC application to a Windows Azure Cloud Service does not mean that it will just work in the Windows Azure environment. There are a number of things to consider when moving to the Windows Azure Platform as a Service (PAAS) model. For example, the Windows Azure environment is stateless, you need to understand the consequences of putting your application in a truly stateless environment. Questions to ask include:

  • How does your application manage session? If you’re using an in-process session state provider you’ll need to change your provider. Luckily there are a number of providers available to you that leverage a number of Windows Azure technologies from table storage to distributed caching.
  • How does your application store persistent data? If you’re using local disk you’ll need to make some changes as Windows Azure disks are volatile. These means that any data you write to disk is not guaranteed to be there if the virtual machine is rebooted.

Of course there are number of other things to consider from third party components required by your application, to dependencies on other systems and services that do not reside in the Windows Azure data centers, to geopolitical regulations regarding where data can and cannot reside. The point of this post was to help you get started taking your existing application to the cloud.

Now for a few bonus points:

*Bonus – you may have noticed I’m using the release candidate of Visual Studio 2012. The steps above also work with Visual Studio 2010.

*Double Bonus – these steps work for versions 3 and 4 of ASP.NET MVC.

*Triple Bonus – these steps also work for ASP.NET Web Forms applications.

*Quadruple Bonus – these steps also work for ASP.NET web sites hosting WCF services.

Having worked with the Windows Azure Platform since 2008 it’s easy to forget some of the initial hurdles I ran into and assume that others won’t have the same challenges. Of course, any time you assume anything you risk being wrong. Rather than assume you won’t run into the issues I did, I thought it would be good to review some of the lessons I’ve learned over the years and share what I’ve learned. Lesson number one is all about billing.

Question, under which scenario will Microsoft bill me for Windows Azure compute instances?

Scenario A: My service is deployed, running and ready to receive requests

azure-billing-01-ready

Scenario B: My service is deployed, stopped and will not receive requests

azure-billing-02-stopped

When Windows Azure became commercially available in early 2010 my initial assumption was that I would only be charged in scenario A above. So, I deployed several services, tested them out, and then stopped them, assuming I could start them up again on demand and only pay for when they were actually running. Of course, my downfall was the fact that I made an assumption. Imagine my surprise when I received a bill for $75 at the end of the month for services that I had running for no more than 10 hours. After doing some digging into the pricing documents I realized that Microsoft charges based on deployment not on status.

If we take the technology out of the equation and apply an analogy it might make a bit more sense. Let’s say I’m traveling and need a place to stay for three nights. The logical thing to do would be to reserve a hotel room for my trip. When I reserve my hotel room I’m not just booking it for the time I’ll be in the room, I’m reserving it for the entire three days. This means I can come and go when I please during the length of my stay. Similarly with Windows Azure, if I deploy a service, regardless of whether or not it’s running, I have at least one reserved virtual machine in Microsoft’s data center, which means I will incur charges based on the size of the instance(s) deployed.

So, the answer to the question is that Microsoft will bill me under both scenarios A and B.

The moral of the story is that while operationally it’s important to know what you have running in Windows Azure, financially it’s important to know what you have deployed to Windows Azure.

Lap Around Windows 8

August 13, 2012

Over the past several days I’ve been introducing a series of screencasts I recently recorded to introduce Windows 8 to developers. The goal is to give developers a high level understanding of Windows 8 so they can have some initial familiarity with the platform without feeling like they have to commit to a technology deep-dive. Each video is short (under five minutes) and to the point. Below are links to all of the videos in the series. Click on the image to start watching and enjoy!

lap-around-win8-01-tools-thumb Tools
In this episode I talk about the tools available to both XAML and HTML developers for creating Windows 8 Metro style apps.
lap-around-win8-02-building-apps-thumb Building Apps
In this episode I talk about how XAML and HTML developers can leverage Windows 8 platform components from within their applications.
lap-around-win8-03-hardware-thumb Hardware
In this episode I talk about how you can integrate your Windows 8 Metro style apps with device hardware.
lap-around-win8-04-tiles-notifications-thumb Tiles & Notifications
In this episode I talk about how you can make your apps feel alive with tiles and push notifications.
lap-around-win8-05-contracts-thumb Contracts
In this episode I talk about how you can use Windows 8 contracts to make your Windows 8 Metro apps feel completely integrated into the overall Windows 8 experience.
lap-around-win8-06-store-thumb Store
In this episode I talk about the Windows Store and how you can leverage to monetize your applications.

{Analysis}

Apple

Microsoft

{Analysis}

Amazon

Cloud Foundry

Eucalyptus

Force.com

Google

Microsoft

Rackspace

I recently sat down to record a series of screencasts that introduces Windows 8 to developers. The goal is to give developers a high level understanding of Windows 8 so they can have some initial familiarity with the platform without feeling like they have to commit to a technology deep-dive. Each video is short (under five minutes) and to the point. Over the next several days I’ll be introducing them to you here on the blog. The last video is about the Windows Store. In this episode I talk about the Windows Store and how you can leverage to monetize your applications. Click the picture below to start watching and enjoy!

lap-around-win8-06-store-thumb

Previous videos

lap-around-win8-01-tools-thumblap-around-win8-02-building-apps-thumblap-around-win8-03-hardware-thumb

lap-around-win8-04-tiles-notifications-thumblap-around-win8-05-contracts-thumb