As you can see in the below image the new magic “OS Settings…” button is now available.

Clicking on the “OS Settings…” button takes you to the following screen to configure your operating system options and how it is updated:

Hopefully, more updates will start rolling out to the dev portal over the coming months.

Infrastructure Access Layer (IAL)

The Infrastructure Access Layer is simply a way to abstract away your underlying infrastructure from your business logic or processing. This means that I can easily change how my applications interact with the infrastructure just by changing a method within the IAL and the business logic would be none the wiser.

Lets take a simple example, I may be developing an applications that takes work items and processes them. I create a method in the IAL called GetWorkItem which will return to my business logic the work item to be processed. This method can then call out to Azure Queues to get a work item, or maybe in the future you will want to switch out where we are getting the work item from, maybe we want to use a web service to call another location, use blob storage to store large work items or listen for a work item to be passed onto a service bus. This can all be dealt with in a single place.

All the business logic knows and cares about is that it is going to call the GetWorkItem method and get a work item back, not where it came from or how it received it it.

Cloud Ready…

Even with more and more people are moving toward the cloud, there are still companies that aren’t quite ready to make the jump, but realise that in the near future may have to and want to know how to create applications that will be able to transition easily to the cloud when they are ready.

By programming against the Infrastructure Access Layer companies will be able to make this move a lot smoother, by just replacing the needed classes so that they interact with the cloud rather than the old infrastructure.

A great example of this would be using a messaging system such as MSMQ as part of your on premise application, and then being able to easily switch this out for Windows Azure Queues or the App Fabric Service Bus when moving into the cloud. Having to make minimal if any changes to your business logic.

Keeping the cloud contained

As I talked about in my last post the cloud can end up getting everywhere and you can soon end up breaking the principle of DRY (Don’t  Repeat Yourself).

With the IAL you can easily keep the cloud contained, letting a minimal number of project have access to the cloud, making SDK upgrades and maintenance easier.

Is that it?

It is indeed. As I said at the start, the IAL is a simple concept that allows you to abstract away your underlying infrastructure from your business logic and also help create cloud ready applications for when people are ready to make that push to the cloud.

Clouds can Spread …

The ash cloud started out in Iceland where it eventually moved and spread out to cover the UK and Europe, even some reports say that it got as far as Canada. Grounding planes and crippling transport for a number of weeks.

This got me thinking, not all clouds are nice white clouds, some are evil volcanic clouds that actually do more harm than good especially when not contained to where we want them to be.  (the ash cloud would have been fine if it had not strayed into European airspace).

The same is true in your applications, when developing for the cloud you can find that the cloud can end up spreading throughout your applications and if your not careful touching every section of code you write.

This can then be a real problem when the underlying SDK to interact with the cloud changes and you have to go through all of your application looking where to refractor and make changes.

Contain Your Cloud

To combat this I contain any code that will access the cloud within few specialised “cloud” projects within my application.

This means that throughout the application if I want to access the Azure message queue, I call a single method from one of my cloud project that will return me a message, meaning that no other part of you application needs to know how to deal with the cloud.

Added Benefits

Containing your cloud not only allows you to keep to the DRY principles and code re-use it, makes maintenance of your application easier and can reduce code smells. One of the biggest benefits is that it also allows you to easier test your applications without having to rely on the cloud or developer fabric, as you can create your cloud methods in a mock-able way.

This isn’t great as you don’t want everyone knowing about your internal system and especially the URL of one of your web roles, with which they could do who know what.

This can easily be fixed with this patch for WCF that will now show the expected endpoint. This endpoint is actually the address of the load balancer that will then forward your request to an web role.

Once the patch is download and installed you can then simply add the following xml snippet into your behaviour for the WCF service:

With this snippet added into your web.config you can browse back to the previous service and will now see that the correct URL is displayed for your service.

I have recently been asked a number of questions both internally and from customers about when you will be billed for Azure usage.

As Eric Nelson’s recent post describes, if you suspend a service you will still be paying this is due to the fact you will still have your application deployed on the server ready to start again. With your application utilizing the server others will not be able to provision its usage.

When you select delete you will stop paying as you will no longer have servers provisioned for your application and the recourses will be freed up for others to use.

Memcached is a distributed cache used to help speeding up large scale web applications by taking pressure off the database. Memcached is used by many of the internets biggest sites, including Twitter, Wikipedia, and YouTube to name just a few.

A distributed cache is one of the things that I’ve been hoping to see released for Windows Azure for quite a while, and I am hoping that AppFabric Caching will make the move to the cloud in the coming year. However, until that happens I was determined to find a way to get a distributed cache and this great Windows Azure Memcached sample showed me how.

“Brad Fitzpatrick, I love your ass!"

Sorry, I just couldn’t help myself. I found this great quote on in the Caching Story page of the Memcached wiki.

After installing and setting up Memcached you will be able to cache any data, including data that is retrieved from your database so that the next time you need it you can get it from cache and not need to re-query your database. Therefore, reduce the pressure on the database and earning the love of our DBA.

Azure Memcached sample

You can download the sample code for Windows Azure from the codeplex download page you then need to download a Windows friendly version of Memcached (here is where I got mine). With the sample code from codeplex just add the memcached exe to your worker roles. You will now be able to run the sample code either on the dev fabric or in the cloud.

One thing to watch out for, the Memcached exe’s seem to take an age to get up and running. I actually left mine to set up overnight (glad I’m still on a CTP account) as the Memcached Worker Roles were all showing busy for a long time, during which the sample would not work correctly.

After the servers have started up you can easily set and retrieve values from the cache as shown in the screenshots below.

Under the hood

Now that we have got our distributed cache working lets have a look how the sample code works.

Memcached Server

On the server side we set up an internal endpoint that will be used to connect the clients to the Memcached server. When the node is created we launch the Memcached server that we downloaded before, passing in the nodes cache size and endpoint as arguments.

          string arguments = 	"-m " + cacheSize +
				" -l " + endpoint.Address +
				" -p " + endpoint.Port;

            ProcessStartInfo startInfo = new ProcessStartInfo();
            startInfo.CreateNoWindow = false;
            startInfo.UseShellExecute = false;
            startInfo.FileName = "memcached.exe";
            startInfo.WindowStyle = ProcessWindowStyle.Hidden;
            startInfo.Arguments = arguments;

This node is now exposing a Memcached server, which can be used by the client nodes to cache data.

Utilizing Memcached – Clients

The client node in the example looks a lot more complicated that it actually is. The most important part is adding the configuration for our memcached client within the settings tab of the node.

Then comes the interesting bit using the Enyim caching library (others libraries are available) and creating a MemcachedClient object, allowing us to get and set objects in the cache.

Each time a new MemcacedClient is needed the program loads a configuration based upon the data within the settings (picture above) and then loops through all of the instances of memcached servers nodes that we are running in our hosted service getting their endpoint, to add this to the configuration of available servers.

            _endpoints = new Dictionary();

            foreach (var endpoint in RoleEnvironment.Roles[_memcachedRoleName].Instances)
            {
                foreach (var epi in endpoint.InstanceEndpoints)
                  {
                    if (epi.Key == "memcached")
                    {

                        _endpoints.Add(epi.Value.RoleInstance.Id.ToString(),epi.Value.IPEndpoint);
                    }
                }
            }

Now that the connection to our memcached nodes we can use the caching library to set and get values in the cache.

AzureMemcached.Client.Store(StoreMode.Set, key, value);          

AzureMemcached.Client.Get(key);

With this code we now have distributed caching on Windows Azure, and can use the example to build out much bigger applications.  

The natural progression from here was to get the code working from within a web or worker role instance hosted within the cloud. Using a web role, I used the OnStart method to set up a IServiceManagent class that could then be shared with the remainder of the classes within the role.

When tracing the hosted services from either the OnStart method or from within default.aspx.cs I could successfully print out all of the services within my account. However, when I set up a WCF REST service to return these hosted services in an array I started to get an error with the connection to the Management API. Giving a argument error stating that a property with the name “httpRequest” is not present. This was even happening when I was using exactly the same code as I was elsewhere.

After a push in the right direction from Simon Davies we found out  that the issue was in the WCF REST service already having an OperationContext from the original REST call before calling out to the Service Management API. This handy blog post, help solve all my issues, all that was needed was to create a second OperationalContext before calling the management service.

using(new OperationContextScope((IContextChannel)WebRole.serviceManagement))
{
  var hostedServices = WebRole.serviceManagement.ListHostedServices(subscriberID);

  foreach (HostedService service in hostedServices)
  {
    Trace.TraceInformation("Hosted Service: {0}", service.ServiceName);
  }
}
            

Ta dar … everything now works, we can use the above code snippet to retrieve back all our hosted services by calling our own web role.

Once I had began playing with the API’s, I wanted to be able to use them within an application so that I would be able to create something like a simple dashboard for managing your services without calling to csmanage all of the time.

I started to do this by building up the REST requests within the application and performing a HTTP GET from my application. However, I then found this very handy library from Microsoft that has done the leg work around all of the calls needed for the service API (almost like a Blue Peter, here’s one I made earlier).

You can see in the code below that to utilize the library, we first need to create a ServiceManagementHelper class. This class will then be used to call out to each of the available services. To create this helper class we need to pass in a reference to an endpoint in app.config (show further down) and a reference to the certificate uploaded to manage our service.

namespace serviceManagementConsoleApplication
{
    class Program
    {
        private const string subscriberID = "...";

        static void Main(string[] args)
        {
            var serviceManagment = ServiceManagementHelper.CreateServiceManagementChannel				   ("WindowsAzureEndPoint", new X509Certificate2("insertcert"));

 	    var x = serviceManagment.ListHostedServices(subscriberID);

            foreach (HostedService s in x)
            {
                Console.WriteLine(s.ServiceName);
            }

            Console.Read();
        }
    }
}

As you can see in the code once the helper is set up we can call any of the services such as ListHostedServices which will return an list containing each service we have hosted in our account.

As mentioned above we need to have an endpoint set up for the helper class to call out to, the configuration for this is shown below.

With the configuration set up and the sample service management API library, we can easily get any application to call out and manage our cloud services.

Download the sample library here.

This afternoon I noticed that I was able to select Europe and Asia regions to deploy my Azure application.

I have yet to see official word of these locations being available, but this must be for the move from CTP to production.

The total cost of ownership (TCO) and return on investment (ROI) calculator allows end users and organisations see how much money they are likely to save / spend when migrating or developing an application on the Azure Platform.

The TCO & ROI Calculator takes the user through a number of steps, starting with a number of questions about the application. Selecting such things as the type of business / application, use of SQL Azure and how you expect to see the service fluctuate over time.

Answers from this questionnaire can then be used to calculate an estimate on the total cost and nodes needed for the application.

This can then be seen over a number of years to see what the cost would be over a longer time period as well as a comparison to how much would be spent hosting the application on premise.

Check out the TCO & ROI Calculator here.