Last year Sydney had the first Australian CloudCamp Unconference. This year CloudCamp is coming to all the major cities in Australia. Sydney has already gone by again, and here’s some details for other cities coming up:

Brisbane

• Details and Registration
• June 8th, 2010
• Local organiser: Me!

Melbourne

• Details and Registration
• April 1st, 2010
• Local organiser: David Burela

About CloudCamp:

CloudCamp is an unconference where early adopters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place where we can meet to share our experiences, challenges and solutions. At CloudCamp, you are encouraged to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate.

I hope to see you all there! Spots are limited so please register ASAP.

Introduction

One of the things you have to consider in any application is configuration. In windows and web forms we have *.config files to help configure our application prior to start. They are a useful place to store things like provider configuration, IOC container configuration, connection strings, service end points, etc. Let’s face it – we use configuration files a lot.

In this article I will discuss the different types of configuration available to you, how they can be leveraged in your application, and how configuration items can be changed at runtime without causing your application roles to restart.

The Problems With Configuration in the Cloud

In Windows Azure applications, configuration can work exactly the same as standard .Net applications. If you have a web role, then you have a web.config. And if you have a worker role, you get an app.config. This allows you to provide configuration information to your role when it starts.

But what about configuration values you want to change after your app is deployed and running? It certainly is a lot harder to get in and change a few angle brackets in your web.config after it is deployed to production in the cloud. Do you really want to have to upload a whole new version of the app package with the new web.config file in it?

Or what about being able to change configuration aspects of all your running instances in one go, and not having to stop them from running to do so? Why should a configuration change necessitate a restart, such as is needed with web.config and app.config files?

In Windows Azure we have a new method of configuring our roles that gives us flexibility and consistency in our applications.

Service Configuration and Service Definition Files

In Windows Azure we can get the above benefits of flexibility and consistency in our configuration, via the service configuration file: ServiceConfiguration.cscfg.

This file contains information about your app that can be used at start-up, and can be changed at runtime without requiring a new package upload. This includes the number of running instances, certificate information, and specific application configuration settings, such as connection strings, port numbers, REST endpoints, etc.

The service configuration works in partnership with the service definition file: ServiceDefinition.csdef.

Both files are located in your main cloud project. The service definition is the “boss”. It can not be changed at run time. When you upload your Azure application, the service configuration is part of the application package, but the service definition is uploaded separately. This is because the service definition contains all the instructions about how an application should be deployed including: details about each of the roles, what their fault and upgrade domains are, TCP ports to open (for worker roles), what local storage should be available, VM size to use, level of trust, and more. After upload, the service definition is shipped off to the fabric controller who will parse it and work out what to do with your cloud package.

We’ll focus on one more thing you will find in the service definition file – information about configuration items. Essentially the service definition states what configuration values will be available in the service configuration file, for each role. It looks something like this:

   1: <WorkerRole name="ImageSearch.Cloud.Overlord">

   2:   <ConfigurationSettings>

   3:     <Setting name="ImageSearchSettings" />

   4:     <Setting name="ImageSearchDBC" />

   5:     <Setting name="SearchMultiplier" />

   6:     <Setting name="MatchTolerance" />

   7:   </ConfigurationSettings>

   8: </WorkerRole>

If a configuration setting name is not specified in the service definition, it can not be used in the service configuration file to configure your app. Think of it as an instruction to the fabric controller: “My app can be configured with these 4 values”. Also, once you’ve uploaded your application, you can’t add or remove settings, since the service definition file is not editable; you can only change the configuration values. I’ll show you how later on.

In the service configuration file, our entry would look like this:

   1: <Role name="ImageSearch.Cloud.Overlord">

   2:   <Instances count="1" />

   3:   <ConfigurationSettings>

   4:     <Setting name="ImageSearchSettings" value="UseDevelopmentStorage=true" />

   5:     <Setting name="ImageSearchDBC" value="Data Source=..." />

   6:     <Setting name="SearchMultiplier" value="3" />

   7:     <Setting name="MatchTolerance" value="50" />

   8:   </ConfigurationSettings>

   9: </Role>

Its pretty similar to the <appSettings> element you are probably familiar with. There is an element for every role in your cloud project, and the <ConfigurationSettings> child element contains all the settings of your application as “name/value” pairs.

Setting Configuration Values

When setting values in the service configuration and definition files directly, you will get complete intellisense, making it very easy to work out what the appropriate values are. It is also possible to set configuration values via the tooling.

In your main cloud project (which contains the links to all your roles) you can bring up the properties window for a role. Under the ‘Settings’ tab you can add new configuration values.

When adding a new setting, the IDE will insert the relevant placeholder in the service definition, and insert the value in the service configuration. This makes the Visual Studio IDE approach a bit of a time saver and helps ensure your definition and configuration files are in sync. In the above screen shot you can see we have two configuration items: the first is a cloud storage connection string, while the second is a database connection string. Essentially, all configuration items are strings, but the IDE gives you some shortcuts when creating configuration values for storage accounts via this connection string type. Clicking the ellipses […] delivers a new modal window where you can specify the details of your storage account.

In the end this just creates another string configuration value that can be used by the app.

<Setting

  name="ImageSearchSettings"

  value="DefaultEndpointsProtocol=https;AccountName=ImageSearch;AccountKey=3ob...UY=="

/>

Changing Configuration Values At Runtime In Azure

To change a configuration value of an app that is already deployed in Azure, you click the Configure button from your project, and this will take you to a screen with a textbox where you can edit all your values directly, or can optionally upload another configuration file. Once saved, that new configuration will take affect. The default behaviour of Windows Azure is to restart your instances now, using the new configuration. However this isn’t ideal, and we’ll look at ways to handle that differently.

Simple Handling Of Configuration Values In Code

The simplest way to leverage configuration items in your code is to use the API that comes with the Cloud tools. This provides a bunch of useful assemblies that give you strongly typed access to all the things you would want to do with your application. In the Microsoft.WindowsAzure.ServiceRuntime assembly (and namespace) we have a sealed class called RoleEnvironment which affords us a static method for accessing configuration values at runtime:

var tolerance = RoleEnvironment.GetConfigurationSettingValue("MatchTolerance”);

Handling Storage Connection Strings In Code

   1: public class StorageAccountFactory

   2: {

   3:     public static CloudStorageAccount Create()

   4:     {

   5:         return CloudStorageAccount.FromConfigurationSetting("ImageSearchSettings");

   6:     }

   7: }

The Catch With Using Configuration Methods In The Storage API

SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used

What this is trying to tell you is that you need to instruct the CloudStorageAccount to use the standard configuration definition file when loading configuration settings. That might seem a little silly at first.. where else could your configuration settings be coming from? Haven’t you just wasted half an hour reading about the Azure configuration files?

Well when running your app in Azure, your configuration will certainly come from the Azure service configuration file. But the tooling guys at Microsoft wanted you to create apps that could still be easily switched back to running on private infrastructure without having to remove all the Azure related integration points; and unfortunately the service configuration file is an Azure only integration point. We need to be able to factor that out into abstraction and make our apps transparent to the source of configuration settings.

Let me explain further with an example. Consider this scenario: you have a web role that puts items into a queue, and a worker role that grabs items out of the queue and processes them. You have your web role setup to use CloudStorageAccount.FromConfigurationSetting to load your storage client from the service configuration file. However later on you decide to move your web role on premise, and leave the other bits running in Azure. You detach your web role from the cloud service project; it now stands on its own two feet and can be run on IIS. But that also means you no longer have a service configuration file; you’re stuck with plain old web.config again. Ideally you should still be able to use the same static method to load your storage account from configuration settings, its just that those configuration settings are now in a different place.

The SetConfigurationSettingsPublisher method that the error refers to is another static method on the CloudStorageAccount class that lets us specify where configuration should be loaded from. According to the MSDN documentation:

This method should be called once to set up the environment. The environment could be the Windows Azure runtime, in which case the publisher is a simple wrapper of the configuration reading and change event. The environment could also be a .NET environment, in which case the developer can hook up a custom configuration reader and change notification.

As stated in the documentation, you should only setup the configuration publisher once, so this ideally should happen in your role’s OnStart event. The code to tell CloudStorageAccount to use the configuration definition uses a delegate which is stored and called every time the configuration is requested:

   1: CloudStorageAccount.SetConfigurationSettingPublisher(

   2:     (configName, configSetter) =>

   3:         configSetter(RoleEnvironment.GetConfigurationSettingValue(configName))

   4:     );

In essence, a configuration setting publisher is just an Action – a delegate that is called when attempting to get the value of a configuration setting name. In the code above we are telling the storage account client that whenever it needs to get a configuration item (configName) then call the standard RoleEnvironment.GetConfigurationSettingValue static method with that name to find and return the value.

How Can I Make My Application Utilise This Abstraction

Great question! Lets say we actually wanted to make our code more flexible and be able to switch between the configuration definition when running in Azure, over to web.config appSettings when running in plain old IIS on our own server. We would like our app to detect that it is no longer running in the world of Azure, and there is a property we can use that does just that: RoleEnvironment.IsAvailable. We can use it to customise who our setting publisher is. Consider the following static method on a factory class that I have created called StorageAccountFactory:

   1: public static Action<string, Func<string,bool>> GetConfigurationSettingPublisher()

   2: {

   3:   if (RoleEnvironment.IsAvailable)

   4:     return (configName, configSetter)

   5:       => configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

   6:

   7:   return (configName, configSetter)

   8:     => configSetter(ConfigurationManager.AppSettings[configName]);

   9: }

You would then call the new method like this:

   1: CloudStorageAccount.SetConfigurationSettingPublisher(

   2:     StorageAccountFactory.GetConfigurationSettingPublisher()

   3: );

Walla! Our app is now aware of when it is and is not running in Azure and can switch its settings provider as needed, while still giving us the benefit of using the CloudStorageAccount API to load our storage account from configuration.

Handling Configuration Changes At Runtime

As I mentioned earlier, you can change configuration values at runtime while your app is already strolling along happily in production. The reasons for needing to make a change can vary; perhaps you want to tweak a performance setting or change the format of log file output.

Most importantly, you don’t want your app to always stop and restart on a configuration change. The default behaviour of Azure roles is to restart on any configuration change so if you want to prevent this behaviour, read on!

You can detect changes to the role environment by handling the 2 following static evenst, available on the RoleEnvironment class:

RoleEnvironment.Changing += RoleEnvironmentChanging;

RoleEnvironment.Changed += RoleEnvironmentChanged;

When you create a new web or worker role, the first event is automatically inserted for you, along with the event handler code:

   1: private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)

   2: {

   3:     if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))

   4:     {

   5:         e.Cancel = true;

   6:     }

   7: }

The default behaviour of this code is to ‘cancel’ the event on any configuration change. Cancelling the event is a bit misleading; what this actually means is that the role will be recycled, configuration changes will be applied, and the role will start up again. So “e.Cancel” actually means “e.Reboot”.

Naturally we need to make changes to this default code. Its up to you to decide which changes require the role to restart and which ones don’t. Personally, I like to make a static array of names of configuration items that I don’t want to cause a restart, like so:

private static readonly string[] ExemptConfigurationItems =     new[] { "MatchTolerance", "SearchMultiplier" };

Then in the RoleEnvironmentChanging event handler we can decide whether or not to reboot, and if we don’t need to reboot, apply the new configuration changes in the RoleEnvironmentChanged event:

   1: private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)

   2: {

   3:    Func<RoleEnvironmentConfigurationSettingChange, bool> changeIsExempt =

   4:       x => !ExemptConfigurationItems.Contains(x.ConfigurationSettingName);

   5:

   6:    var environmentChanges = e.Changes

   7:        .OfType<RoleEnvironmentConfigurationSettingChange>();

   8:    e.Cancel = environmentChanges.Any(changeIsExempt);

   9:

  10:    if (!e.Cancel)

  11:    {

  12:        var oldMultiplier = RoleEnvironment

  13:            .GetConfigurationSettingValue("SearchMultiplier");

  14:    }

  15: }

The RoleEnvironmentChangingEventArgs supplies a Changes property which is a list of all changes that caused this event to fire. Typically these will be a change of the number of instances that the role is running, or a change to configuration items. We request all the changes that are of type RoleEnvironmentConfigurationSettingChange which represents just setting changes. We then compare the changed items to our static list of configuration names, and if any of the changes aren’t in the list, we’ll do a reboot. If we don’t do a reboot (which means all changes belonged to our exempt list) we will apply those new changes as necessary.

Summary

And that’s all there is to know about configuration at this point in time. Here’s a couple of points summarising what we’ve learnt:

• Configuration values can be changed while your app is still running
• Default behaviour in such cases is to reboot the role
• Configuration is just XML but the Visual Studio IDE gives nice design time experience
• Connection strings are a special kind of configuration string that store details for a Windows Azure Storage account
• Using the API we can abstract our settings publisher to create flexibility of usage in Azure and non-Azure applications
• Runtime configuration changes can be checked and instance recycling can be avoided if necessary

Please keep in mind that this was valid at the time of writing and that the Azure platform is continually evolving, so there might already be a better technique for what you want to do.

Additional Links

• Overview of Service Architecture
• Changing The Windows Azure Service Configuration when running on the DevFabric
• Windows Azure Services – Exercise 2: Configuration, Logging, and Debugging

Late last year Microsoft announced the availability of a Content Delivery Network (CDN) in Azure that you can use to distribute your Windows Azure Blobs to over 18 different edges, including Australia.

However this technology is not actually a new offering. Microsoft has been building/leasing CDNs for some time now. Prior to 2007 Microsoft leveraged the CDNs of a variety of companies such as Akamai and Level 3. Then in early 2007 Limelight Networks announced that they were supporting Silverlight with a focus on streaming media, and not long after, a Microsoft and Limelight joint partnership was announced where Microsoft would lease some key CDN technologies from Limelight and start building their own CDN. Rumour spread about Microsoft acquiring the company but those were quickly dismissed.

Like all other things infrastructure related, Global Foundation Services (GFS) is the department that is responsible for Microsoft’s CDN technology. At the end of the day you have to remember that Azure is not the first product to come along that requires massive storage and compute resources. Bing, Virtual Earth, Photo Gallery, Hotmail, etc are all services that require massive scale and Microsoft has been working in data centre technology for a long time. GFS is responsible for all of that and more. In their own words:

Global Foundation Services (GFS) is the engine that powers Microsoft’s Software Plus Services strategy. We focus on smart growth, high efficiency, and delivering a trusted experience to customers and partners worldwide

Microsoft has been building data centres for some time and it makes sense that they would start  improving on their own CDN offering. And even with the Limelight deal in 2007, Microsoft has started scaling back its other outsourced CDN needs, improving on its own CDN capability instead. At the Content Delivery Summit of 2009, the GM of Microsoft’s Edge Computing Network Jeff Cohen released some interesting statistics around Microsoft’s CDN services, as this article states:

..one of the points that really stood out was how quickly Microsoft is moving away from relying on third party CDNs for delivery and instead, using their own internal CDN..

In 2007 about 95% of Microsoft content was delivered by 3rd party CDN, however by the end of 2010 they expect this number to have dropped to a lowly 40%. It would seem that Microsoft is moving away from partner CDNs for small/large file transmissions, opting instead to use its own CDN technology, but sees its video streaming still sitting firmly in the hands of other companies like Akamai and Limelight. It makes sense. As I said before, Microsoft is in the market of building data centres for its various products and has already built data centres all around the world, including this one in Dublin (there was a feasibility study done for an Australian based data centre a couple years ago and Microsoft opted not to build one here yet).

With the release of ASP.NET 4.0 Microsoft are also offering CDN support for various JavaScript libraries such as its ASP.Net Ajax libraries, and the JQuery libraries. Google started with this idea in May of 2008 so Microsoft has been a bit slow to the punch. Google also supports a large variety of Ajax frameworks in its Ajax API CDN whereas Microsoft’s list is still growing.

So this all begs one question: Where does my CDN enabled Azure blob data actually sit? Microsoft or some third party CDN provider? 

Well I hunted around and couldn’t find any specific information stating one way or the other whose CDN the blob storage uses, but I can tell you that it would appear to be hosted on 3rd party CDNs. How do I know for sure? I don’t, but there’s some clues that hint to the fact, and I’ve dropped 2 key clues in this article for you to find. The first one to work out the 2 clues/indicators and post them in a comment to this post will win an Azure T-Shirt! (Australian residents only please).

Is there any real cause for alarm that my blob data could be hosted on a 3rd party CDN provider? Well no – you can only enable CDN availability on blob containers that are public access, which means everyone can get your data anyway.

In a country like Australia where we have communication ministers who want to introduce ISP level internet censorship and telco-providers refusing to improve bandwidth, CDNs will be critical to content delivery speed and adoption of higher quality information (eg HD streaming).

During the early CTP of Azure you could only select 2 locations for your Windows Azure compute and storage accounts, and 1 location for SQL Azure (SQL Data Services) and AppFabric (.Net Services). Now we have a lot more options for all 3 main technologies:

• North Central US
• South Central US
• North Europe
• Southeast Asia

On top of this we now have a single location for Dallas accounts:

• South Central US

The Microsoft CDN is now also utilisable from Windows Azure Blob Storage as well. Microsoft has been building a CDN for some and uses it for a variety of purposes. There are over 18 edges in the CDN, Australia being one of those nodes.

So next time you’re wondering about the locations available, hopefully you won’t need to go into the actual portal project creation process just to find out.

It has been a hectic week in Australia around the Windows Azure Platform space. The official Windows Azure launch happened in Sydney and Melbourne. I was lucky enough to pop down on Tuesday for the Sydney event and see David Chappell and Dianne O’Brien present along side Australia’s own Gianpaolo Carraro on the current face of the Windows Azure Platform.

You might recognise David (David Chappell and Associates) as the author of the various Azure whitepapers found on the Azure site. I’ve also seen his slide deck before but after much hunting around this afternoon was unable to find them. David spoke about the basics of the platform, covering off Windows Azure roles, SQL Azure, and AppFabric (formerly .Net Services). David has obviously presented this topic many times before as it shows through in his presentation style. I learnt some tips I will reuse in future when presenting Azure topics. I was also lucky enough to have lunch with David after the event and gain some insight into his thoughts about the near future of Azure and other cloud platforms.

The other presenter was Dianne O’Brien, Senior Director for Business Strategy and Operations in the Windows Azure product team. Dianne was also over in Australia from the mother ship to talk about the Azure offering in Australia. She indicated that we will likely see Azure release in Australia in April 2010, quite a long way given this launch event was held in February. Dianne had an awesome slide deck I would love to get my hands on, and she talked about the Azure pricing strategy, data centre locations, and more.

Not sure how this escaped my notice, but it would seem that service bus pricing will now be based on connection. Exactly what defines a connection and how disconnects and retries are affected is beyond my limited knowledge. I’ll endeavour to find out a little bit more about this as soon as I have bandwidth.

Something else Dianne mentioned that really caught my attention was a statement about how she expects people to architect their applications around the Azure pricing model. I think she is probably right about this to a certain degree (people will seek to minimise cost), but I dearly hope she is wrong. The cloud as an industry already suffers terribly from a lack of anything closely resembling portability. Vendors are all vying for business and platform lock-in. The manifesto debacle last year indicated portability as one of its tenants, yet none of its major sponsors can advertise portability of their products while maintaining a straight face.

Architecting solutions around a pricing model is fraught with danger and is the antithesis of portability in general. No other platform is the same as Azure but that doesn’t mean there isn’t hope for application portability. Ok so you won’t be able to take your C# code over to Google Apps but at least your app should still be hostable on a VM instance in Amazon EC2 or GoGrid. In my opinion we should all be thinking about the cloud-portability problem since we can all make a difference in how this will play out (developers, team leads, middle/senior management, Microsoft, Amazon, etc).

The other event of interest this week was a road trip by Mr David Lemphers, Senior Program Manager on the Windows Azure team. It was great to finally meet David after conversations exchanged over twitter. David was presenting a more developer focused view of the Windows Azure platform and hit most of Australia’s capital cities.

While I didn’t learn a lot personally about the technology or business model of Azure this week, I did come to the realisation that despite having my head deep in Azure for so long, the rest of the community is still quite clueless to Azure and what it can do for them. Which means I better pick up some blogging velocity again hey? =)

Last Thursday evening (18th Feb 2010) I did a presentation to the Gold Coast .Net SIG about developing applications for the Windows Azure Platform. The talk went for almost 2 hours (for that I apologise!) and seemed well received.

I started with an overview of the platform, and then dived into Windows Azure, SQL Azure and .Net Services. I used a demo application that performed searches for images based on colour content, using Azure to do the grunt work of analysing images.

You can find the files from that presentation here:

• Slide Deck PPTX (1.9Mb)
• ImageSearch Demo Application (2.9Mb)

The night seemed to go well, except for the fact that my SQL Azure account expired on that very day, mere hours before my presentation. I received no warning email and was pleasantly surprised by the little ‘disabled’ flag against my SQL Azure account.

I will now spend the next few days trying to work out what I have done to anger the demo gods. In the meantime, stay tuned, as future blog posts will break down that demo application to talk about some of the techniques used to share code, use configuration settings, and utilise database access, all in a fashion that is agnostic to whether we are using the developer fabric, or the production Azure fabric.

If you attended on the night, I’m more than happy to hear any feedback about the presentation you may have. I am trying to continuously improve as a presenter and appreciate any constructive criticism you can provide.

Earlier this week I did a presentation to the Brisbane Infrastructure Group (BIG) (twitter: #bigau) about the Windows Azure Platform. I want to say a ‘big’ thankyou to all those who attended and also to Avenade for supporting the event.

I’ve uploaded the slide deck as a zip file for you to peruse. I’ve also added annotations in the ‘notes’ section on most pages where necessary including extra links to articles of relevance.

Please note that this slide deck is a combination of slides from the Azure Training Kit, the PDC08 talk delivered by Erick Smith and Chuck Lenzmeier, and my own content. Please feel free to reuse anything you find within, except my humour. I only request a link back to this site in return.

I’ve done a couple behind closed doors for my Readify work mates and for various clients, but this will be my first presentation to the open public. I’ll be presenting on the Windows Azure Platform at the Brisbane Infrastructure Group in Brisbane Queensland (Australia for my international readers).

Those who know me know that, amongst other things, I am a developer. My work with Readify in a consulting manner is all development related to some degree. I love to code! For me to present to an Infrastructure group about Azure has many potential hazards. I might be lynched, have fruit thrown at me, or just simply no one will show up to the presentation. But still, I must spread the message!

Besides, I am confident that the prospect of hearing about an operating system for the cloud will be too much for these infra nerds to resist! So log off those domain admin accounts, tuck your shirts into your undies, and come along to hear all about the next generation of computing in the cloud!

Please RSVP as soon as possible via this link or by emailing the BIG group at: bigau@live.com.au

Also, I will be awarding a prize based on the best developer or sys admin joke on the night!

Disclaimer: Prize may have no real value

This posting may very well be banter. You have been forewarned.

Services

Everywhere I look I see services. I can get pizza delivered, my clothes dry-cleaned, and my shopping delivered to my home without ever leaving my computer. These are all services provided by someone, somewhere. A little closer to home I have my TV which delivers a digital service, radio which delivers an analog service, phone line which delivers a communication service, an XBOX which delivers an entertainment service, and even my kitchen counter, which props up the toaster and bowl of fruit, is performing a useful service.

Definition

Here’s a site I often use that provides a service that explains the meaning of words. The word I am interested in, surprisingly, is “service”:

an act of helpful activity; help; aid

Ok I ignored the other definitions but they all pretty much relate back to the concept of something, someone or some corporation doing something useful for others. Sometimes we pay for services, sometimes they are free. But really, services are there to help and form the cornerstone of our very society.

Now that you love services as much as I do, you’ll completely appreciate what this means in software engineering: A service is any code component that helps your application achieve completeness. It is not necessarily something that communicates over the wire, via named pipe or some message queuing application. It isn’t always found in the form of XML, JSON, or binary formats. Its just like your kitchen counter, a piece of code that provides a useful function to your application.

Too abstract?

I think we often get too wrapped up in someone’s interpretation of various buzz words and lose site of the meaning of the words themselves. I have no problems using the term ‘service’ in a way that relates in no way to objects going over the wire, WCF, ASMX, etc. Instead, our repositories, factories, presenters, controllers, managers, builders, all those code classes that have a single responsibility, they are all services. For example, in an app I am working on now for a client (ASP.Net, WCF, MS SQL) I am using the MVP pattern and am using IOC (Ninject). I wanted my presenters to be responsible for navigation, but didn’t want them to know anything about page urls. So I created a ‘NavigationService’ (with matching interface) with a simple ‘Navigate’ method on it. It takes a view ‘name’ and looks up the sitemap to work out where to navigate to. This works great because now my presenters are controlling page flow without knowing anything about how navigation works. Its highly testable since my NavigationService can be mocked out easily (thus the interface). You obviously don’t have to put the word ‘service’ in the name, its just sometimes helpful if your class can’t easily be classified as a repository, factory, etc. If you had ‘Helper’ somewhere, generally you could probably replace that with ‘Service’ since it means the same thing.

Service Oriented Architecture

Yes SOA means Service Oriented Architecture, not Service Oriented Application, and certainly not Service Only Architecture, which is what some people seem to think it means even when they say the word ‘oriented’. The term ‘oriented’ means ‘aligned’ or ‘related’ and in my mind, the literal translation of the phrase means “an architecture where the majority of modularisation is achieved through services”.

OASIS is a standards group and has a reference model for SOA which states:

“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

When we hear the word ‘distributed’ in computing we automatically assume disparity and remoteness. But again if we look to our word salad service (dictionary) we get:

“to divide into classes”

Oh this is almost too easy! Of course it doesn’t mean software classes (example, plant species as classes of plant distribution) but it fits too well to ignore. And those capabilities are of course our helpers, repositories, etc. The last part of that statement says “that may be under the control of different ownership domains”. I guess the point here is that it doesn’t have to.

What’s your point?

Lets say I have a smart client application, WPF since that’s my drug of choice. I’ve broken it down into a main EXE and a separate DLL where I store all my repositories, builders, factories, presenters, etc. I go to great lengths to ensure everything acts like a service (as per my explanations above). All my capabilities are distributed into separate classes.

In this scenario, am I implementing a Service Oriented Architecture?

Well I’m overly focused on services, some services call others, each is defined by a contract (since I use IOC to locate and resolve them), the implementation is hidden behind the interface, and the only implementation not in a service is the UI. So as far as I’m concerned, the answer is yes!

The great thing about IOC and services in general in .Net is that you can easily turn one of those interfaces into a WCF service contract with very little effort. You want to ‘distribute’ over the wire? You can! The important thing is that you have control over how the services are surfaced.

So the final takeaway is this: consider SOA for every application you ever design. This doesn’t mean WCF, ASMX, named pipes, etc. It just means designing your application with individual services that take care of all your application needs. If you can do that, you will realise clean abstractions, encourage testability, improve maintainability, and create reusability. And I can assure you, once you adopt this style (and a good IOC container to help), you’ll never go back.

The Azure Part

Some of that service stuff above is not overly relevant to what I’m going to talk about next. But SOA in general certainly is. Windows Azure supports division of labour very well: If your services are all located within one application assembly, then just provision one web project. If you feel you need to scale out certain services due to work load, slap some service contracts on them and push them into a new instance of their own. Want to keep some of those services on premise? No problems, use the Service Bus to route requests to your on-premise services, easily skipping through those firewalls. Want your data in the cloud too? No problem, stick it in SQL Azure or just plain old Windows Azure Storage if necessary. Hell you could even put it in Amazon S3 if you wanted, Azure doesn’t care: it supports these service abstractions easily and doesn’t know if the service you are calling is hosted in Azure, on-premise, through the service bus, or some external service (eg. S3, Flickr, etc).

Summary

The point I am trying to make is that if you follow the SOA principles above, your application design will “just work” when you want to move to Azure. The applications that are hardest to move to Azure are those with tightly coupled components and leaky abstractions. Its certainly difficult to adopt this style of development at first and is certainly something that your architect should be involved in continuously (code reviews, etc). But even if you don’t plan on moving to the cloud, its a great way to build your applications and helps you benefit in the long term. Once you get used to the style, it certainly improves your development speed, and removes dependencies on the components being built in other teams. And it certainly works well for large and small projects alike.

Firstly this is pure speculation. Either that or it is known fact and I am behind the game (I’ve been out of action for a couple months, you may have noticed my absence in blogging). If I am the first person you have heard this from, then there is every chance that it is false, so once again, this is just speculation.

Recently there have been a spate of questionnaires going out to Azure consumers/clients. Being a good CTP user and evangelist of the platform, I filled out every single one that came my way. Some took hours, some took minutes. But while it would seem that Microsoft were collecting information from me, it also alluded/hinted at some features that might be released by Microsoft sometime in the future. This post is simply identifying those features that have already been discussed in those surveys.

Get on with it already

The feature name currently is ‘Managed VM Role’ and would essentially be an instance that you could remote to like any other server. This would fall into direct competition with GoGrid/EC2 type hosting where you provision server instances and get full terminal services access to the instance. In this case it would be custom Server 2008 instances that could still be managed by the Fabric Controller. Microsoft summarises the concept like so:

‘A mechanism to snapshot an entire application environment and create a Windows VM to be deployed and managed by Windows Azure together with the relevant data, registry settings, and the ability to choose and control OS versioning. In this case, the customer is responsible for installing security patches, OS updates, and upgrades by creating a new image snapshot updating the running VM roles using the Windows Azure upgrade facility’.

This would work in harmony with a ‘Managed Application Role’ which basically sounds like what they are already doing with Windows Azure, however it also hints at using a packaging facility like MSI for the deployment process. Also some elevated privileges might be possible in the final release (currently you can run in full trust but under a restricted user account).

Anything Else?

There’s a few other smaller bits and pieces hinted at, summarised below:

• Cloud Storage Explorer (although there are already good candidates)
• Better deployment story from Visual Studio (I’d like to see MSBuild tasks)
• Better deployment feedback (provisioning process for example)
• Design surface for your service oriented application (this would be way cool)

Remember as I said before, its all speculation at this point.