Every Penny Counts in the Cloud

There are many potential benefits of cloud computing that an organization can evaluate, but my favorite one to talk about is the efficient use of your I.T. dollars that is made possible by the elasticity of the cloud. This is easily explained through 2 simple diagrams that you can jot down on a nearby whiteboard or napkin whenever the opportunity arises. There are more elaborate versions of these diagrams out there in slide decks, but you can tell the story effectively just by drawing a couple of lines and narrating them.

The first diagram has a wavy line showing changing application load over time. To this we add a staircase which depicts cycles of hardware purchases (the vertical parts of the staircase) and time passing (the horizontal parts of the staircase). What this shows is that companies are forced to buy more capacity than they really need just to be on the safe side—in effect, spending more money than is necessary or spending it earlier than necessary. Even worse, if there is an unexpected change in load an undersupply situation can result where there is insufficient capacity. This arrangement is what we’re used to in the enterprise—but it is hardly ideal.



The second diagram has an identical wavy line showing changing application load over time. Instead of being joined by a staircase, the wavy line is paralleled by another wavy line that is nearly identical. This second line is the size of your footprint in the cloud. It is dialed larger or smaller in accordance with the load you measure. Anyone can see quite readily how more efficient this is.



Does this superior arrangement the cloud makes possible come at a price? Yes it does: you need to monitor your application regularly and expand or reduce your deployment in the cloud accordingly. Failure to do this will undermine the financial premise of using the cloud. Today this monitoring and adjusting is not something Windows Azure does for you as an out-of-box feature. However, you can achieve the monitoring and adjusting programatically via the Windows Azure Diagnostic and Service Management APIs.

Dynamically Computing Web Service Addresses for Azure-Silverlight Applications

If you work with Silverlight or with Windows Azure you can experience some pain when it comes to getting your WCF web services to work at first. If you happen to be using both Silverlight and Azure together you might feel this even more.

One troublesome area is the Silverlight client knowing the address of its Azure web service. Let’s assume for this discussion that your web service is a WCF service that you’ve defined in a .svc file (“MyService.svc”) that resides in the same web role that hosts your Silverlight application. What’s the address of this service? There are multiple answers depending on the context you’re running from:

1. If you’re running locally, your application is running under the Dev Fabric (local cloud simulator), and likely has an address similar to http://127.0.0.1:81/MyService.svc.
2. If you run the web project outside of Windows Azure, it will run under the Visual Studio web server and have a different address of the form http://localhost:<port>/MyService.svc.
3. If you deploy your application to a Windows Azure project’s Staging slot, it will have an address of the form http://<guid>.cloudapp.net/MyService.svc. Moreover, the generated GUID part of the address changes each time you re-deploy.
4. If you deploy your application to a Windows Azure project’s Production slot, it will have the chosen production address for your cloud service of the form http://<project>.cloudapp.net/MyService.svc.

One additional consideration is that when you perform an Add Service Reference to your Silverlight project the generated client configuration will have a specific address. All of this adds up to a lot of trouble each time you deploy to a different environment. Fun this is not.

Is there anything you can do to make life easier? There is. With a small amount of code you can dynamically determine the address your Silverlight client was invoked at, and from there you can derive the address your service lives at.

You can use code similar to what’s shown below to dynamically compute the address of your service. To do so, you’ll need to make some replacements to the MyService = … statement:
1. Replace “MyService.MyServiceClient” with the namespace and class name of your generated service proxy client class.
2. Replace “CustomBinding_MyService” with the binding name used in the generated client configuration file for your service endpoint (ServiceReferences.ClientConfig).
3. Replace “MyService.svc” with the name of your service .svc file.

string hostUri = System.Windows.Browser.HtmlPage.Document.DocumentUri.AbsoluteUri;
int pos = hostUri.LastIndexOf('/');
if (pos != -1)
{
    hostUri = hostUri.Substring(0, pos);
}
MyService.MyServiceClient MyService = new MyService.MyServiceClient("CustomBinding_MyService", hostUri + "/MyService.svc");

With this in place you can effortlessly move your application between environments without having to change addresses in configuration files. Note this is specific to “traditional” WCF-based web services only. If you’re working with RIA Services, the client seems to know its service address innately and you should not need to worry about computing web service addresses.

Azure ROI Calculator Updated for Azure 1.2

Neudesic's Azure ROI Calculator has been updated. You can get to the calculator and other useful Azure resources from http://neudesic.com/cloud.

The updated calculator reflects new features and pricing model changes added to the Windows Azure Platform in the 1.1 and 1.2 releases, including these:

• Windows Azure Compute - VM Size
  
• Windows Azure Content Delivery Service - added
  
• SQL Azure Database - broader selection of databases sizes
  
• AppFabric - Access Control Service revised pricing model
  
• AppFabric - Service Bus revised pricing model / connection packs
  

Although there is a very comprehensive TCO tool available at http://azure.com/, Azure ROI Calculator is useful when you need to compute cloud charges or the ROI of a migration quickly.

Azure Bootcamps

Microsoft's Azure Bootcamps are going strong! At an Azure bootcamp you get a full day of learning Azure through a combination of presentions and hands-on labs. Starting next week, Neudesic is sponsoring the following 12 Azure bootcamps across the country in 12 locations:

• New York - June 15 RSVP
  
• Washington DC - June 22 RSVP
  
• Dallas - June 8 RSVP
  
• Chicago - June 24-25 RSVP
  
• Denver - June 4 RSVP
  
• Salt Lake City - June 11 RSVP
  
• Portland - June 1 RSVP
  
• San Diego - June 1 RSVP
  
• Orange County - June 2 RSVP
  
• Los Angeles - June 3 RSVP
  
• San Francisco - June 15 RSVP
  
• Seattle - June 16 RSVP

Speaking at Executive Cloud Computing Roundtable in Portland

I'll be speaking at the Executive Cloud Computing Roundtable on the evening of Thursday May 6th in Portland Oregon. To lead off our discussion, I'll present on the business benefits of Windows Azure and examine what cloud computing means for I.T. under the best and worst of circumstances--and how to direct the outcome.

For more information, contact me through this blog.

Speaking on VS2010 and C# 4.0 at LA .NET Developers Group Meeting on May 3rd

On Monday May 3rd I'll be speaking at the Los Angeles .Net Developers Group on C# 4.0 and Visual Studio 2010.

Next Meeting

Monday, May 03, 2010 at
Visual Studio 2010 and C# with David Pallman
TOPIC: Tour of Visual Studio 2010 and C# 4.0

David Pallmann will take us on a tour of Visual Studio 2010 and C# 4.0. In the Visual Studio 2010 portion of the talk, many new IDE features and improvements will be shown that improve your design, development, debugging, and deployment experience, including: zoom, box selection, call hierarchy, navigation, highlighting, generate from usage, and more intelligent IntelliSense.

In the C# portion of the talk, new language features will be demonstrated including: named and optional parameters; the dynamic language runtime; variance; and COM interop.

We're meeting from 6:30 to 9:30 pm on the UCLA campus. You can get directions from the the LA .Net Developers Group web site. If you're in the LA area, we hope you can join us!

Windows Azure Best Practices

At Neudesic we do a great deal of Windows Azure consulting and development. Here are the best practices we've identified from our field experience:

1. Validate your approach in the cloud early on
2. Run a minimum of 2 server instances for high availability
3. SOA best practices generally apply in the cloud.
4. SOAP is out, REST is in.
5. Be as stateless as possible.
6. Co-locate code and data as much as possible.
7. Take advantage of data center affinity.
8. Retry calls to Windows Azure services, SQL Azure databases, and your own web services before failing.
9. Use separation of concerns to isolate cloud/enterprise differences.
10. Get as current as possible before migrating to azure.
11. Migrate applications one tier at a time.

1. Validate your approach in the cloud early on. Once you have a tentative solution design, test the viability of your design in the cloud early in your project to validate its viability. Don’t wait until the end of your project to find out if your approach will work. Your solution in the cloud may reveal very different dynamics and performance from the enterprise, and you may encounter issues with supported features and deployment. Waiting until the last minute to test viability in the cloud is dangerous.

2. Run a minimum of 2 server instances for high availability. When hosting in Windows Azure, consider 2 as the minimum server farm size. If you only run 1 server, you will experience periods of unavailability as patches or updates are applied. When you have 2 more servers in a farm, patches and updates are sequenced to prevent downtime. The Windows Azure SLA is only guaranteed when there are at least 2 servers in a farm.

3. SOA best practices apply to the cloud. The principles of Service-Oriented Architecture apply equally well to the cloud as they do in the enterprise:
 Connect programs with loose coupling
 Define explicit boundaries
 Use interoperable standards
 Define coarse-grained contracts and avoid chatty interfaces
 Favor stateless services

4. SOAP is out, REST is in. REST is part of “how we do things in the cloud”. The best way to write effective cloud software is to be in line with its philosophies and preferred protocols. SOAP does of course play a role in key areas such as federated security but for application developers it’s about REST these days. Take advantage of related technologies like WCF RIA Services.

5. Be as stateless as possible. Farms for web applications, web services, and workers can be adjusted at any time to larger or smaller sizes. The best way to code wherever possible is to avoid session state. If you must have session state, implement it in a way that doesn’t rely on server affinity.

6. Co-Locate code and data as much as possible. Whether your code is in the cloud or in the enterprise, it’s best if code and the data it accesses are near each other. Avoid unnecessary traffic between cloud and enterprise.

7. Take advantage of data center affinity. Since many cloud solutions involve multiple projects (hosting, storage, database, communication, security) use the Affinity Group feature of the Azure management portal to ensure a related set of projects reside in the same data center.

8. Retry calls to Windows Azure services, SQL Azure databases, and your own web services before failing. Any HTTP call can fail, and you should expect calls to the cloud will fail or time out at times. Your calling code should attempt a limited number of retries before failing. This applies to your own web services, to Windows Azure services (storage, communication, security), and to SQL Azure databases.

9. Use separation of concerns to isolate cloud/enterprise differences. Use common interfaces and dual service implementations to provide equivalent cloud and on-premise functionality to your apps. If you’re writing applications that need to work in the cloud as well as on-premise, you’ll have to implement some things slightly differently—for example, accessing a local file server vs. accessing blob storage in the cloud. A great way to do this is to define a common service interface (with functions like GetFile, PutFile) and have two implementations, one for on-premise and one for in the cloud.

10. Get as Current As Possible Before Migrating to Azure. The more current you are on Microsoft technologies in your enterprise app before migration, the easier the migration will be. A case in point is SQL Server to SQL Azure. If you’re not on SQL Server 2008 yet, you should get compatible with that before migrating to SQL Azure. Otherwise you’ll have twice the number of issues in getting the database migrated and it will be less clear what’s an Azure issue vs. a SQL Server version issue.

11. Migrate applications one tier at a time. Since most solutions have multiple tiers, a migration to the cloud can be approached one tier at a time—keeping the solution running all the while. This is analogous to keeping a patient alive through a series of surgeries. By focusing on one software layer at a time, you carve a complex job into a series of smaller more focused tasks. It’s best to migrate database first, then web services, then front end.