Go Live on Azure

Go Live Partners Series: Extended Results, Inc.

GregOliver — Thu, 21 Jun 2012 20:08:55 GMT

Founded in 2006, Redmond, Washington based traditional ISV Extended Results (http://www.extendedresults.com) specializes in business intelligence solutions. They sell primarily to enterprises worldwide across many verticals.

Companies spend a lot of money these days building business intelligence capabilities based on various vendor technologies. Workers sitting at their desks or connected via VPN are in great shape – their KPI’s are right where they need them. Extended Result’s PushBI product sees to that. But what about when they’re NOT at work?

Mobile devices operate outside the firewall. They don’t have direct access to a company’s internal systems and for good reason – it’s too easy to lose one. So – what’s the answer to most computing problems? Add a level of indirection! That’s what Extended Results did with the Windows Azure component of PushBI Mobile. (http://www.pushbi.com) Now users of popular mobile devices (Windows Phone 7, iPhone, iPad, Android, Blackberry, Windows 7 Slate) can get access to their critical business information while on the road or in the coffee shop via a short hop through a cloud component running in Windows Azure.

This long time Microsoft partner chose Windows Azure because they know .NET well. This familiarity allowed them to create this innovation quickly and get it to market in record time.

Congratulations, Extended Results!

Go Live Partners Series: Rare Crowds

GregOliver — Thu, 21 Jun 2012 16:38:26 GMT

Founded in 2012, Bellevue, Washington based Rare Crowds (http://wp.rarecrowds.com), is a SaaS Cloud Service Vendor and Microsoft Bizspark partner. Rare Crowds sells ad purchasing efficiency solutions to international enterprises in the advertising industry with plans to expand into SMB over time.

Ad buys are expensive, and no one ever buys just one ad so the waste associated with buying inefficient ads multiply. Especially in large companies that buy hundreds of ad placements at a time, any efficiencies at all can yield large monetary returns. To generate these efficiencies, Rare Crowds needs data – and lots of it. Not to mention the computing power to crunch all of that data. Putting it all together yields the right ad being delivered to the right audience at the right time.

Rare Crowds had choices when it came to deciding on which cloud vendor to work with. Several factors contributed to their decision to work with Microsoft to build on Windows Azure. Obviously, the technical capabilities of the Windows Azure platform had to be there. But they also wanted great developer support and a great partner to work with – one throat to choke, as it were. Their comfort with the .NET Framework makes it important that their cloud vendor fully supports .NET as a first class citizen. The solid integration with Visual Studio, making developers more productive because of their familiarity with the tools, played a big role as well. And to top it all off, they find OPX to be noticeably cheaper on Azure.

Congratulations, Rare Crowds, and thanks for your commitment to Windows Azure!

Go Live Partners Series: Cloud49, LLC.

GregOliver — Tue, 01 May 2012 04:41:58 GMT

Founded in 2010 and based in Anchorage, Alaska, Cloud49 LLC (http://www.cloud49.com) is a BizSpark startup and SaaS ISV providing human capital management software (HCMS) primarily to enterprises in the US over $100M in annual revenue.

Co-founders Nathaniel Gates and Paul Dicang worked together for several years in Alaska Native Corporations (ANCs) and experienced first-hand the limitations and expense of available solutions. In June of 2010 they left their jobs to start Cloud49, a cloud-based infrastructure services (i.e. backup, DR) company. They then built on their success by moving into building and selling HCMS solutions.

(NOTE: ANCs are regional or village companies in the State of Alaska that serve the interests of their shareholders - i.e. the inhabitants. By their nature, they are a mix of public sector, human resources, education and social. )

FireweedHCMS (http://www.fireweedhcms.com) is a new software suite incorporating 5 application areas (e.g. Shareholder Data Management, Student & Scholarship Management) that provide instant financial and social benefits. Azure compute, storage and SQL Azure were used to build the system.

Cloud49 chose the Azure platform for a couple of reasons. They were already familiar and comfortable with .NET technologies. They wanted to build and run their system in a cloud that runs .NET not as an afterthought, but as a first class citizen. In addition, data security and platform reliability are very important to their customers. When prospects hear that the system is running in Microsoft datacenters, these concerns vanish from the discussion.

Congratulations, Cloud49!

Auto-scaling Azure with WASABi–From the Ground Up

GregOliver — Thu, 26 Apr 2012 14:49:25 GMT

(The information in this post was created using Visual Studio 2010, the January refresh of the Windows Azure Platform Training Kit and v1.6 of the Windows Azure SDK in April of 2012. The autoscaler was installed in the compute emulator. The “app to be scaled” was deployed to Azure.)

The Microsoft Enterprise Library Autoscaling Application Block (WASABi) lets you add automatic scaling behavior to your Windows Azure applications. You can choose to host the block in Windows Azure or in an on-premises application. The Autoscaling Application Block can be used without modification; it provides all of the functionality needed to define and monitor autoscaling behavior in a Windows Azure application.

A lot has been written about the WASABi application block, notably in these two locations:

http://msdn.microsoft.com/en-us/library/hh680892(v=pandp.50).aspx
http://entlib.codeplex.com/ (PS: this is the place to get support questions answered!)
Plus a very informative video: http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications

In this post, I demonstrate the use of WASABi in a compute emulator hosted worker role scaling both web and worker roles for the “Introduction to Windows Azure” hands on lab from the training kit (the “app to be scaled”). I use a performance counter to scale down the web role and queue depth to scale up the worker. Here are a few links:

Windows Azure Platform Training Kit: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8396
Adding the Autoscaling Application Block to a Host: http://msdn.microsoft.com/en-us/library/hh680920(v=pandp.50).aspx
My earlier blog post on Azure Diagnostics: http://blogs.msdn.com/b/golive/archive/2012/04/21/windows-azure-diagnostics-from-the-ground-up.aspx

Here’s an overview of the steps:

Create a new cloud app, add a worker role.
Using the documentation in the link above, use Nuget to add the autoscaling application block to your worker role.
Use the configuration tool (check it out: http://msdn.microsoft.com/en-us/library/ff664633(v=pandp.50).aspx) to set up app.config correctly.
Start another instance of Visual Studio 2010. Load up “Introduction to Windows Azure”, Ex3-WindowsAzureDeployment, whichever language you like.
Change the CSCFG file such that you’ll deploy 2 instances of the web role and 1 instance of the worker role.
Modify WorkerRole.cs so that queue messages won’t get picked up from the queue. We want them to build up so the autoscaler thinks the role needs to be scaled.
Modify WebRole.cs so that the required performance counter is output on a regular basis.
Deploy the solution to a hosted service in Azure.
Set up the Service Information Store file. This describes the “app to be scaled” to the autoscaler.
Set up rules for the autoscaler. Upload the autoscaler’s configuration files to blob storage.
Run the autoscaler, watch your web role and worker role instance numbers change. Success!

And now some details:

For #3 above there are a few things to be configured:

Nothing under “Application Settings”. You can ignore this section.
The Data Point Storage Account must be in the Azure Storage Service rather than the storage emulator. The reason is that they’re using the new upsert statement which is not supported in the emulator. (how many hours did this one cost me???)
Your autoscaling rules file can be stored in a few different places. I chose blob storage. It can be either storage emulator or Azure Storage Service. An example of a rule is “if CPU % utilization goes above 80% on average for 5 minutes, scale up”.

The Monitoring Rate is the rate at which the autoscaler will check for runtime changes in the rules. You can ignore the certificate stuff for now. It’s there in case you want to encrypt your rules.
Next is the Service Information Store. This file describes the service that you want to monitor and automate. In it you tell the system which hosted service, which roles, and so on. The same configuration details as those for the rules file pertain.
You can ignore the “Advanced Options” for now.
When you’re done with the configuration tool, take a look at app.config. Down near the bottom is a section for <system.diagnostics>. In it, the Default listener is removed in a couple places. Unless you configure your diagnostics correctly, the effect of this is that the trace messages from the autoscaler will go nowhere. My advice: remove the lines that remove the default listener. This will cause the trace messages to go into the Output window of Visual Studio. As follows:

(If you have read my previous blog post about Azure Diagnostics (link), you already know how to get the trace log to output to table storage, so this step isn’t necessary.)

For #6 above, I just commented the line that gets the CloudQueueMessage:

For #8 above, reference my earlier blog post (link) on configuration of diagnostics to switch on the CPU% performance counter. Here are the lines you’ll need to add to the DiagnosticMonitorConfiguration object:

For #9 above, there are a few things I want to point out.

In the <subscription>, the certificate stuff points to where to find your management certificate in the WASABi host. WASABi knows where to find the matching certificate in your subscription once it has your subscription ID.
In the <roles> elements, the alias attributes point at (match – case sensitive) the target attributes in your rules in #10 (coming next).
In the <storageAccount> element you need to define the queue that you’ll be sampling and call it out by name. The alias attribute of the <queue> matches to the queue attribute of the <queueLength> element in the rules file.

For #10 above, this is the fun part.

To show the operation of performance counters causing a scaling event, I set up a rule to scale down the web role if CPU% is less than 5%. Since I’m not driving any load to it, this will be immediately true. Scaling should happen pretty soon. To show the operation of queue depth causing a scaling event, I set up a rule to scale up if the queue gets greater than 5 deep. Then I push a few queue messages up by executing a few web role transactions (uploading pictures).

Most folks initially learning about autoscaling wisely think that we need to set up some kind of throttle so that the system doesn’t just scale up to infinity or down to zero because of some logic error. This is built in to WASABi. Here’s how this manifests in this example:

Next, we need to think about how to define the criteria that we’ll use to scale. We need some kind of way to designate which performance counter to use, how often it gets evaluated, and how it’s evaluated (min/max/avg, whatever). The role’s code might be outputting more than one counter – we need some way to reference them. Same goes for the queue. With WASABi, this is done with an “operand”. They are defined in this example as follows:

Here, the alias attributes are referenced in the rules we’re about to write. The queue attribute value “q1” is referenced in the Service Information Store file that we set up in step #10. The queueLength operand in this case looks for the max depth of the queue in a 5 minute window. The performanceCounter operand looks for the average CPU% over a 10 minute window.

You should be able to discern from this that autoscaling is not instantaneous. It takes time to evaluate conditions and respond appropriately. The WASABi documentation gives a good treatment of this topic.

Finally, we write the actual rules where the operands are evaluated against boundary conditions. When the boundary conditions are met, the rules engine determines that a scaling event should take place and implements the appropriate Service Management API to do it.

Note that the target names are case-sensitive. Note also the match between the operand name in the reactive rule, and the alias in the operand definition.

For #11. Run the autoscaler and the “app to be scaled”, upload 6 pictures. Because we’ve disabled the ingest of queue messages in the worker role, thumbnails won’t be generated. It might be easier to use really little pictures. Now sit back and wait about 10 minutes. After about 5 minutes you should start to expect the worker role to scale up. After about 10 minutes you should start to expect the web role to scale down. Watch the messages that are appearing in the Output or table storage. They offer an informative view into how WASABi works. Because the actual scaling of the roles causes all of them to go to an “updating…” status, you might not see the distinct events unless you spread them out with your time values.

Please note this is a sample and doesn’t include best practices advice on how often to sample performance counters and queues, how often to push the information to table storage, and so on. I leave that to the authoritative documentation included with WASABi.

Cheers!

Windows Azure Diagnostics–From the Ground Up

GregOliver — Sat, 21 Apr 2012 21:59:00 GMT

(The information in this post was created using Visual Studio 2010 and the Windows Azure SDK 1.6 in April of 2012. All tests were done in the compute emulator.)

I think of Azure diagnostics in two broad categories: the stuff that you get more-or-less for free and the stuff that you log with statements similar to Trace.WriteLine. There is more – quite a lot actually – but with these two forming the basis the rest should flow more easily by referencing the documentation in MSDN.

Starting with Visual Studio 2010, create a new cloud project and add a worker role. Delete the Diagnostics plug in from your CSDEF file and the Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString from all CSCFG files (they have to match). Run the project. Take a look at the contents of the new GUID/directory/DiagnosticStore directory as depicted below. Put the lines back in the config files and run it again, examining the DiagnosticStore directory. Explore the Monitor directory deeply. You should see some pretty interesting things. This page gives the details:
http://msdn.microsoft.com/en-us/library/windowsazure/hh411546.aspx

What we’ve just demonstrated (with zero code) is the level of diagnostics information that you get more-or-less for free with the worker role and web role templates. This MSDN page details what we just did and what it means:
http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.diagnostics.diagnosticmonitor.aspx

Before:

After:

The information that’s being gathered is in a binary format, so you can’t view it easily. To do that, you need to set up a periodic transfer of the information to Azure table storage. This not only converts the information into a readable form, but also puts it into a location that is easy to access.

There is a singleton DiagnosticsMonitor associated with each role (web or worker) in your service. This object defines how much, how often and what is pushed out to table storage. There is a factory default configuration embedded into the object that says “push nothing to table storage”. There are three straightforward ways of changing this. One of them is to add code to your role. OnStart is the typical location of this code. Putting it here affects all role instances. Here’s an example (#1): (information logged with this example appears in Azure table WADDiagnosticInfrastructure)

Another way (#2) is to edit a rendition of the default configuration file that is put into blob storage when your instances start up. There is one of these files for each instance. If you edit this file, the DiagnosticsMonitor will pick up the change and change its behavior accordingly. So where are you going to find these files? In a container called “wad-control-container”. Which storage account? The one designated by the Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString setting in your CSCFG file. Seriously, try it! Don’t put the code above into OnStart, run your role, then edit the configuration file. Wait a couple minutes and voila! Diagnostics information will start dropping into table storage.

This page gives another code sample and some explanation of this:
http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx

This page talks more about the various methods of altering DiagnosticMonitor’s configuration:
http://msdn.microsoft.com/en-us/library/windowsazure/hh411551.aspx

So much for the more-or-less free stuff. What about sending trace output to the Azure logs?

This is almost as free. You have to write the Trace.WriteLine statements. And you have to tinker with the DiagnosticMonitorConfiguration a bit as well, but no more than you did for the previous stuff. Instead of DiagnosticMonitorConfiguration.DiagnosticInformationLogs as in the example above, set values for the properties of DiagnosticMonitorConfiguration.Logs instead. You can do this in either of the three ways noted above (I only gave examples of two, but you get the point.) The information shows up in WADLogsTable.

An important aspect to diagnostics is Trace Listeners. Listeners basically hook up information sources (IIS, your Trace.WriteLine code, etc.) with output mechanisms (text file, output window in Visual Studio, etc.) The web and worker role templates also include a listener for Azure diagnostics: Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener. This is configured in <system.diagnostics>in web.config or app.config. If you remove the listener, nothing breaks but you won’t get any output, either. Try it! Just remove the listener from app.config, run your project, then take a look in the Resources directory (detailed above). It’s pretty empty.

Cost

Logging isn’t free! It’s using Windows Azure Storage, both blobs and tables. There are about 43k minutes per month. If you push trace information once per minute and only use one storage transaction per push, that’s about $0.43 / month. Now multiply that by the number of things you’re logging. We are careful about writing multiple records at a time to minimize costs, but we can only do so much. Since you can configure logging so easily, be judicious about the amount and frequency of logging.

Tools

I used a couple of tools to assist with these tests. I used Azure Storage Explorer to access my developer storage directly – blobs/tables/queues. Cerebrata Azure Diagnostics Manager v2 did a really nice job of formatting the diagnostic information that was pushed into table storage. It allows you to look at it from offline, historical and live sources.

Cheers!

[UPDATE on 4/26/2012] Thanks to Fernando for pointing out an arithmetic error, which has been corrected.

Go Live Partners Series: Wealth Habit, Inc.

GregOliver — Fri, 30 Mar 2012 04:30:46 GMT

Angel-funded startup and Bizspark member Wealth Habit (https://wealthhabit.com/) is a Cloud Services company located in Portland, Oregon. Led by CEO James Werner, and CTO Brian Gambs, Wealth Habit provides enterprise-level B2B financial services. It adds value by reducing or removing financial stress on employees by providing up to the minute feedback on purchasing and savings decisions - either via a web browser or on the user's mobile phone. Based on the latest research in behavioral economics, their products help to reduce employee financial distress by clearly framing the spending and savings decisions of users.

Wealth Habit chose Windows Azure as their deployment platform because the costs are very low and the platform adds value over and above simply providing compute and storage capabilities.

For example, their SQL Azure database just runs, without any intervention on their part due to the massively scaled infrastructure of the Windows Azure cloud. While periodic backups are always recommended, failures due to hardware fault are all but unheard of due to replication-in-triplicate built in at a very low level to the Azure storage services.

In addition, their compute infrastructure is based on Azure web and worker roles. Because of this, they never have to be concerned with downtime or labor intensive patching, no matter how big their user base gets because Windows Azure automatically performs guest OS upgrades on their behalf. And, as their user base grows, their compute infrastructure will scale seamlessly, both up and down, to meet current user resource requirements.

Wealth Habit is a great example of the benefits that can accrue to folks that embrace the cloud.

Cheers!

Installing Windows Features in a Windows Azure Role Instance

GregOliver — Mon, 15 Aug 2011 20:45:06 GMT

In this posting I’ll talk about my experiences and final solution to what is usually a simple thing with a Windows Server box: installing Windows features.

If your Azure solution requires a Windows Feature, you might be tempted to set up a VHD and then upload to a VM Role. While this will work, for various reasons it’s not the optimal solution if a worker or web role can do the job. And, as is frequently the case these days, startup tasks can be used to handle this requirement quite nicely.

Initially, I experimented with techniques such as OCSetup and ServerManagerCmd. I used Remote Desktop to try out scripting these options before settling on PowerShell. OCSetup doesn’t give great feedback and has no option for querying status of existing features, and ServerManagerCmd is deprecated. I needed to learn a little bit about PowerShell, but as it’s the technology of the future I decided it was worth the effort.

I used a couple of excellent resources to learn what I needed to know:

Powershell.com has a free eBook entitled Mastering Powershell. Here’s the link: http://powershell.com/cs/blogs/ebook/default.aspx.
Microsoft’s own Scripting Guy, Ed Wilson, published an excellent series of videos for the beginner: http://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx.

The particular Windows Features that I needed to add are “Ink Support” and “Ink Handwriting Recognition”, where “Ink Support” requires a reboot and is a prerequisite for “Ink Handwriting Recognition”. Fortunately, the startup task that you can specify in your CSDEF file gets run every time a role instance boots (not only when the instance is created.)

Two scripts are needed in a PowerShell scenario, one CMD file and one PS1 file:

Startup.CMD

powershell -command "Set-ExecutionPolicy Unrestricted" 2>> err.out
powershell .\startup.ps1 2>> err.out
Startup.PS1

Import-Module Servermanager
$ink = Get-WindowsFeature "IH-Ink-Support"
$hwr = Get-WindowsFeature "IH-Handwriting"
if (!$ink.Installed) {
Add-WindowsFeature -name "IH-Ink-Support" -Restart
}
if (!$hwr.Installed) {
Add-WindowsFeature -name "IH-Handwriting"
}

Here, Get-WindowsFeature returns an object with various properties. The one we care about is “.Installed”, which returns a boolean value indicating the installation status of the feature. For the non-C crowd, the exclamation point, in PowerShell speak, indicates “not”.

Just a few notes:

Set-ExecutionPolicy

Here’s a great blog post that deals with this:
http://blogs.msdn.com/b/jimoneil/archive/2011/02/07/azure-startup-tasks-and-powershell-lessons-learned.aspx
Set up remote desktop

Another Jim O’Neil posting:
http://blogs.msdn.com/b/jimoneil/archive/2010/12/29/azure-home-part-13-remote-desktop-configuration.aspx
This page has a list of installable Windows Features on WS2008R2:

http://technet.microsoft.com/en-us/library/cc732757.aspx
Another good way to see a list of features but also each one’s current status on your instance is to open a PowerShell box, Import-Module Servermanager and then Get-WindowsFeature. Pipe the output to “more” (| more) if you want to see a page at a time.
And here’s Steve Marx’ very useful blog posting on Startup Tasks:

http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks

And finally, as mentioned before (but always important to remember), don’t create a command file in Visual Studio. Doing so inserts a couple of byte order chars at the front that prevent the command interpreter from being able to read it. Start your command file with notepad, add it to your project, then you can edit in VS.

Cheers!

Automating Blob Uploads, Part 2

GregOliver — Tue, 14 Jun 2011 22:04:11 GMT

I tossed out a challenge in a comment I left on the first of this series – there’s a problem with this approach to automating blob uploads. It’s not a problem that affects everyone. For example, perhaps you have a multi-tenant solution where each customer has their own storage account.

When a Windows Client wants access to the Azure Storage Service directly, the storage credentials must be available locally in order to structure the REST requests. Usually, as in the code that I’ve provided, the credentials are stored in clear text in the configuration file. However, if the client is part of a hybrid solution and many customers will have it, you probably don’t want to do this. These credentials are the keys to the kingdom – with them anything can be done with any of the data in the storage account.

One solution to this problem is to put the credentials behind a web service call. SSL encrypt the call to the web service and authenticate callers with the AppFabric Access Control Service (ACS) or some other means, then pass the storage credentials back to the client. Without going into the details of encryption/decryption, certificates, etc., this solution is the same as the one that I have already provided with very minor tweaks to the code.

Another solution is the one for which I am providing additional sample code. Use a Shared Access Signature (SAS) to protect blob storage access and put the accesses to queue storage behind secured and authenticated web service calls. In a nutshell, a SAS is a time-bombed key with specific access rights to either blobs in a container or a single blob.

In this modified solution, I have added a WCF web role to my Azure service. This WCF web role is based on the Visual Studio template that is listed along with web role, worker role, etc, when creating a new Cloud Solution.

The flow of control is altered only slightly:

Prior to uploading the blob, a call is made to request the SAS from the web service. The SAS is a string. This string is supplied as a parameter on the upload calls.
Instead of accessing queue storage directly, additional calls were added to the web service:

Send notification message
Get acknowledgement message
Delete acknowledgement message

While this solution solves some security concerns, there is again a cost. The client cannot run without the server in this architecture. I have lost loose coupling in favor of security. In my third article on this topic I’ll partially deal with this problem. (Hint: AppFabric Service Bus Queues)

Full source is provided here.

Enjoy!

Automating Blob Uploads

GregOliver — Sat, 11 Jun 2011 22:00:39 GMT

In my travels I hear about a lot of patterns of cloud computing. One that I hear frequently is “upload a file and process it”. This file could be financial data, pictures, video, electric meter readings, and lots more. It’s so common, and yet when I Bing (yes, Bing ) for blob uploaders, they’re all manual.

Now, I’m sure that lots of people have tackled this problem for their own needs, but I thought I’d put something together and share it with the community. Both client and server source code are here.

Architecture View

Process Flow

Sorry for the eye chart. I’ll try to explain (in order of the basic system flow.)

UI Thread

A FileSystemWatcher detects new files in a directory in the local file store. A tracking record is inserted into a SQL Express tracking DB.

Process Files Thread

If it’s a big enough file that the upload is attempted before the file is fully copied into the directory, the thread waits by attempting a write lock. The file is uploaded to Azure blob storage using parallel blocks. The block size and number of simultaneous blocks is configurable using the StorageClient API. Once the file is uploaded, a record is placed into the Notification Queue and the tracking record is updated.

Azure Worker

The Azure worker detects the notification, determines that the blob is “ok” in some way (application specific), acknowledges receipt (in order to free up client resources), processes the blob (or sets it aside for later), then deletes the notification message.

Process Acknowledgements Thread

Receipt of the acknowledgement message triggers deletion of the file in the upload directory and update of the tracking record. Then the acknowledgement message is deleted.

What could go wrong?

In a manual upload scenario, so many controls would get in the way. Automating the process demands that care is taken to ensure fault tolerance. Here are some things that can go wrong and how the architecture protects against them:

Azure worker is unavailable. (Perhaps it’s being upgraded, it’s very busy, it has a specific window of time that it runs.)
By placing the data into blob storage and creating the notification record, the system is unaffected by absence of the worker. If you need more workers to process the data, they can easily be created and will immediately start taking load. This procedure can be automated or manual.
Azure worker fails. (Hardware? Program bug?)
The last step in the process is deleting the notification message. The message will re-appear in the queue for processing by another worker in this case. You should check the number of times the message is de-queued to ensure the message or data in themselves aren’t the problem.
Upload fails. (Network connection?)
The upload is protected in a couple of ways. By uploading in blocks, if your upload fails in the middle you only need to upload the missing blocks. The last block that’s uploaded stitches the component blocks together. Also, the last step in the upload process is update of the tracking record. If the tracking record is not updated, the upload will be attempted again at a later time.
Client resource stretched. (Too many files in the directory.)
Files to be uploaded can come from many sources and perhaps 100’s at a time. By watching for acknowledgement of receipt from the server side the program can recycle this resource effectively. This is the main reason the program was written as a set of cooperating threads – so that a long upload wouldn’t prevent keeping the directory cleaned up.

Alternatives to the Process

Following on #4 above, if there’s lots of processing to be done on each data file (blob), but there’s also lots of files to be uploaded, you can run into trouble. If you don’t have enough workers running (costs more), files could back up on the client and potentially cause problems. By splitting the task load up, you will be able to acknowledge receipt of files quicker and clean up on the client more frequently. Just be sure you’re running enough workers to get the overall work done during your window of opportunity.

What about those queues?

Yes, you could use SQL Azure tables to manage your notifications and acknowledgements. Queues have the advantage of being highly available and highly accessible in parallel via HTTP, though this comes at a cost. If you have millions of files to process, these costs are worth considering. On the other hand, presumably your SQL Azure database will be busy with other work and you don’t want to load it down. Also, if you have lots of customers you would need to either wrap access to SQL Azure behind a web service or open its firewall to them all.

What about the FileSystemWatcher?

FSW has a buffer to hold events while they’re being processed by your code. This buffer can be expanded, but not infinitely. So you need to keep the code in your event logic to a minimum. If large numbers of files are being dropped into the upload directory, you can overwhelm the buffer. In a case like this it might make sense to set up multiple incoming directories, multiple upload programs, etc. An alternative to FSW is enumerating files, but this can be slow.

As always, I’m interested in your thoughts. Comment freely here or send a mail. Full source for both client and server are here.

Accumulus Makes Subscription Billing Easy for Windows Azure

GregOliver — Mon, 21 Feb 2011 19:18:04 GMT

The Accumulus Subscription and Usage Billing System enables businesses to find more success with subscriptions and recurring payments. The system includes a suite of integrated tools designed to help a business grow its customer base by improving customer acquisition, fully automating the customer life-cycle and maximizing customer retention. The system handles promotion tracking, usage tracking, fee calculation, credit card processing, provisioning, billing statement emailing and customer support.

I sat down with Gregory Kim, CEO of Accumulus, and Christian Dreke, President/COO of Accumulus to talk about how the Accumulus Subscription and Usage Billing System makes it easy to monetize subscription services in Windows Azure. The video ends with a demonstration of how quick it is to get started with Accumulus.

Please take a look!

Azure Email-Enables Lists, Low-Cost Storage for SharePoint

GregOliver — Mon, 14 Feb 2011 22:22:39 GMT

vorApps for SharePoint Online delivers an email enabled information management solution leveraging the power of Microsoft SharePoint Online.

Diane Gallagher of Vorsite Corp talks to Greg Oliver, ISV Architect Evangelist, about how vorApps was built on Windows Azure and how Office 365 customers can use it with Exchange Online and SharePoint Online.

View the video: http://tinyurl.com/4df67fs

Cheers!

Installing a Windows Service in a Windows Azure Worker Role

GregOliver — Sat, 12 Feb 2011 00:32:51 GMT

It might seem like a giant leap backward to bother with installing a Windows service in a worker role. After all, the Windows Azure and Visual Studio teams went to a lot of trouble to create worker roles as a core part of the platform. Worker role code is monitored by the fabric controller, so we know when it is no longer healthy and we can take steps to remediate. Windows services have additional plumbing associated with them so they can be started up, paused, shut down and managed by the Services.msc MMC plug-in. So why bother?

At this point I know of only one good reason: on-ramping to the cloud. You might have a Windows service that you rely on and want to do a proof of concept on Windows Azure but not want to take the time to refactor to worker role code. I’m sure that there are other good reasons and I’d love to hear them!

The process to making this happen is pretty simple. It involves the use of admin mode (available with the 1.3 SDK) and a short cmd script. Here’s a brief overview of the process:

Create a Windows service app for your test. I used the template in VS2010, made it installable and gave it a name. Nothing else.
Create a new cloud solution and add a worker role.
Add the Windows service app (my example is testapp.exe) to the worker role files. Mark its properties “Build Action = None”, “Copy to Output Directory = Copy Always”.
Add InstallUtil.exe and InstallUtil.exe.config in the same way. My service was compiled using .NET 4.0, so I found the .NET 4.0 version of InstallUtil on my system to use.
Create a command script using Notepad. This command script will install your service using admin mode during the spin up of your worker role instances. Include this file in your worker role files the same way as the others. (NOTE: Don’t use VS to create the command script. According to Steve Marx’ and Wade Wegner’s recent Cloud Cover episode, this causes the file to not execute.)
Add a few lines to your ServiceDefinition file that will cause your script to run.
Configure Remote Desktop connections on your roles. You’ll use RD to debug your script. Here’s another Cloud Cover episode that should help you get this going.

When you’ve got it set up correctly, your service will install automatically each time an instance of your role starts up.

Here are a few details:

InstallService.cmd creates a new user account and makes it an administrator. This user account is needed for the InstallUtil invocation. The last line (exit /B 0) is to ensure that the script exits with a good return code. This allows you to RDP into the instance while testing. If you didn’t do this, the worker role will cycle, attempting to get a clean start. Once your code is clean, you can remove the exit.

One more thing: what did I put into my worker role code? Nothing! I just used the code as it comes out of the template. It loops, waits 10 seconds, loops, etc.

Cheers!

Putting data in cold storage with Windows Azure Table

GregOliver — Wed, 09 Feb 2011 02:43:09 GMT

Sometimes the data that’s being kept in SQL Azure relational storage doesn’t really need to be there. A couple of examples of this are blobs and historical records. Lots of folks have discovered the wonders of moving blobs from relational storage to Windows Azure blob storage. Just leave behind a pointer and add a line of code and instantly save relational storage capacity for more valuable pursuits.

It’s a little more complicated with historical records. Lots of transactional systems have a few big tables (such as invoice item). The rest or the tables can be thought of as forming contextual frameworks (customer / product) or provide reference (zip code). Most of the transactional records just sit there doing nothing most of the time. You input them, manage them through to a completed state (paid invoice, for example) then print a few reports. Done. Wouldn’t it be nice if you didn’t have to keep them in (relatively expensive) relational storage for the next few years though you must keep them for regulatory or compliance reasons (for example)?

The idea of expensive storage and cheap storage isn’t new. The main thing I wanted to do with this blog is remind folks of it and give an example of some code that implements one variation. In this example, I imagine that each and every invoice must be represented in the relational store with a tombstone so that it can be retrieved easily. You never know when someone will decide to reach back a couple months or years into the archive.

A tombstone in this context is just a record that says data exists, but not in the relational table. The tombstone contains enough information to find the original data at need. You could set up tombstones to represent single records or any grouping that you care to imagine and that makes sense. For example, maybe you permit people to reach into the archive to print a report for a single day and so you set up your tombstones to represent a whole day’s transactions.

Ideally, the tombstone record is small relative to the data that you’re archiving. A few bytes to point to a lot of bytes. In my example, the invoice record has a invoice number, customer number and a creation date making up the primary key. The actual invoice record will have columns representing shipment method, payment terms, the amount of the invoice, the amount paid, and so on. For simplicity sake, I created an InvoiceMetadata table that has exactly one record for each Invoice record. The InvoiceMetadata table has the primary keys plus a couple of flags that are used for tracking archived data.

When the management of the invoice is complete (it’s paid), the ReadyToArchiveFlag is set to true. If the ArchivedFlag is set to true, it means that there is a copy of the Invoice record in the archive already.

There are 4 main use cases associated with this example:

Create new invoice records and manage them through their lifecycle
In the sample code, this is accomplished through the “Reset” button and “Test” button. “Reset” clears the data store and then creates 50 invoices. “Test” sets some of them as “paid” and therefore ReadyToArchiveFlag is also set. Finally, a message is dropped into a queue. The message instructs a worker role to archive any invoices that are ready.
Archive invoices that have completed their lifecycle
The worker role finds the message and makes a copy of each invoice that is ready. It copies the records to Azure Table storage and deletes them from the SQL Azure table. It also sets the “ArchivedFlag” in InvoiceMetadata.
Bring back invoices that are needed for research, reporting, etc.
For this use case I have a “Report” button. I imagine that someone wants to print invoices for a certain date. The code behind the “Report” button drops a message into the queue. The worker role picks up the message and as instructed, copies the records from Table storage back to SQL Azure.
Remove invoices from relational storage that are no longer needed
After the report is printed, any invoice that’s in SQL Azure that has the “ArchivedFlag” set is deleted. There’s already a copy in the archive so nothing else needs to be done.

How can costs and savings be calculated? Both SQL Azure and Azure Table storage are charged by the gigabyte. SQL Azure storage charges are calculated daily. So – if your database has a max capacity of 5gb for the day, you’re charged 5 * $9.99 / (average # days / month). If you can do your retrieval of archived data without expanding your database, then it costs nothing extra to do your “reports” under this scheme. (If you do need to expand your database to hold archived data temporarily, use ALTER DATABASE.) Savings may be calculated as the number of gb that get archived * ($9.99 – .15) and prorated to the number of days in the month.

A few comments about the source code:

I built this starting with a plain cloud project + 1 web role + 1 worker role. I added a data model and used Entity Framework for data access. The deletes were done with embedded SQL so that I didn’t have to read the records into memory that I wanted to delete. Some readers may be familiar with sparse columns in SQL Server. SQL Azure doesn’t support sparse columns at this point, so I elected to split out the InvoiceMetadata.

Accommodating Your Batch Window in Windows Azure

GregOliver — Wed, 26 Jan 2011 22:52:00 GMT

Certain functions of a system need to run once per day in a typical “batch window” scenario.

You might already be aware that Azure compute is paid by the CPU-hour. If you’re occupying the CPU, whether or not actively using it, you’re still paying for it. You occupy the CPU ‘slot’ by having a role deployed, regardless of state - it doesn’t have to be in the ‘Ready’ state.

So how do you get your batch of work done without paying for the slot 24 hours per day?

The answer is found in the Windows Azure Service Management API. The CreateDeployment API can be used to deploy an app into an existing Hosted Service. You can do this in various ways including client code, a PowerShell script, or a web or worker role that’s running in Windows Azure.

There are a couple of versions of the Service Management API: managed code and REST. At the time of this writing, the REST version of the API is the most complete and feature rich. The managed version doesn’t currently support the ability to CreateDeployment.

For my purposes, I looked at how to use an Azure role to deploy an app. The PowerShell script already exists and is easy to use – as depicted in one of the Hands on Labs in the Windows Azure Platform Training Kit. By creating code that runs in a worker role you can then replicate (multi-instance) it in a management pack for your service, thus giving it high availability and fault tolerance.

The sample code that I provide is in a web role. I used the web page to display diagnostics as I went along. The project is just a new cloud solution with a web role as provided by Visual Studio 2010. I’m using the 1.3 version of the Windows Azure SDK, but everything I’ve done here can also be done with the 1.2 version. In my code, I:

Load the certificate
Initialize storage
(user clicks “test” button)
Get ServiceConfiguration.cscfg from blob storage
Build request and payload
Submit the request
Display the ID of the request as returned from the platform.

source code

Following are signposts to help you avoid some of the bumps on the road:

Certificate Handling

When you are accessing the Service Management API from the client, you must use a certificate to authenticate the program to the portal. You must upload the management certificate to the Azure portal and have the original certificate on the client. The PowerShell script (or windows client) references the local version and matches it to the version that’s in the portal.

When you’re using a web or worker role, the cert has to be loaded into the role as well as the management certificate store so the role can match its copy to the one in the management certificate store. Hence, you actually have to export the certificate twice – once to the DER version (to a file with .CER extension) as well as export the private key version (.PFX extension). The source code that I’ve provided has additional details.

Request URI

One of the parameters in the request URI is <service-name>. The value that you need to use is the one in the ‘DNS Prefix’ field in the management portal. It’s case sensitive.

Creating the Payload

The web request for CreateDeployment requires a payload. I tried a couple of ways to create the payload and decided I like using XDocument and XElement (System.XML.Linq) to manage this. The other way I tried is plain old embedded text.

If you like the plain old text method, there’s a wrinkle to avoid. Don’t precede your XML with a newline. I tried this at first for readability, but the request fails with InvalidXMLRequest.

GOOD

payload = string.Format(@"<?xml version=""1.0"" encoding=""utf-8"" standalone=""yes""?>
<CreateDeployment xmlns=""http://schemas.microsoft.com/windowsazure""> <Name>{0}</Name>
…

BAD

payload = string.Format(@"
<?xml version=""1.0"" encoding=""utf-8"" standalone=""yes""?>
<CreateDeployment xmlns=""http://schemas.microsoft.com/windowsazure""> <Name>{0}</Name>
…

If you prefer the System.XML.Linq approach, there is another wrinkle to avoid.

XNamespace xn = "http://schemas.microsoft.com/windowsazure";
XDocument doc = new XDocument(
new XElement(xn + "CreateDeployment",
new XElement(xn + "Name", "gotest-20101231"),
…

After building up the XDocument, you need to get it into a string before transmitting it. This string must be UTF-8 encoded. XDocument.Save wants a StringWriter, and StringWriter.ToString() outputs UTF-16. (If you forget and do this, you’ll get ProtocolError.) The solution is to subclass StringWriter, adding an encoder that outputs UTF-8. Again, details are in the provided source.

Referencing REST Resources

In general, REST resource designators are case sensitive in the Windows Azure REST API. The portal will enforce lower case on some things, but your deployment package might be upper and lower case, so be careful with that.

Multiple Versions

There have been several releases of the API, and older versions are still supported. Hence, when you build your request, you need to specify x-ms-version in a request header. Check carefully for the correct version; the value given for CreateDeployment is 2009-10-01 (or later) in the Request Headers section of the documentation. If you read further you’ll find that it must be 2010-04-01 if you include StartDeployment or TreatWarningsAsError in your payload.

I hope these tips come in handy. Please comment freely and let me know if there are other aspects of this topic that you’d like to hear more about.

Cheers!

Attribution:

Thanks to Steve Marx for his very valuable assistance on several fronts.
Thanks to Ricardo Villalobos for his assistance with the StringWriter subclass.