Some free Azure eBooks

Digging around the net, I found a few free e-Books. Here are the links:

From the p&p group:

Others:

(Not sure if I should be showing the last link, which I am not sure is a legal download! It’s a great book though)

There is also a heap of whitepapers available from Microsoft, that you may want to look at:

Architecting for the cloud talk

I am doing a talk next week on Architecting for the cloud, with a focus on Windows Azure. Here is the blurb for the talk:

The cloud offers a number of great benefits to organizations such as low upfront & ongoing costs, seemingly infinite resources and elasticity on demand. But how do you design applications to take advantage of what the cloud has to offer? How do you architect applications to work in the cloud? What are the things you need to consider when you are moving your existing application to the cloud? Mahesh Krishnan, Technical Specialist on Windows Azure answers these questions and talks about how you go about architecting applications for the Windows Azure platform

If you are in Melbourne on the 25th of October and would like to come along, please RSVP to janice(dot)itchins(at)robertwalters(dot)com(dot)au.

  • Date and time of event: Thu, 25 Oct, 2012, 5:30pm
  • Location: Level 41, 385 Bourke Street

Refreshments will be provided, but please RSVP ahead of time. I’ll post slides after the talk…

WASABi

At Tech Ed this year, another talk I did was titled “Writing Robust Azure Applications using P&P guidance”. The title is probably a bit hard in working out what the talk really contains, but it is split into two separate topics – one on the Windows Azure Autoscaling Application Block, aka WASABi, and one on the Transient Error Handling Application Block, aka Topaz.

Considering the fact that these are two separate topics, I thought I’d cover them separately in the blog as well, starting with WASABi in the first post. But even before I get into WASABi, I want to give a general introduction into scaling, and why you need it.

To discuss scaling, let’s take the example of the recently concluded Olympics. The Olympics as you know runs once every four years, and the traffic to the website that hosts the Olympics, spikes during the duration it runs, and may be a couple of weeks before and after the event – which is close to about 4 or so weeks – in 4 years! Sure you have traffic coming into the site during other times, but you don’t want to be catering for peak loads during the entire 4 years. That’s where scaling comes into play.

If you look at some of the reasons people move their application to the cloud, it is due to the following reasons –

  • low initial and low ongoing costs, in most cases metered by the hour
  • seemingly infinite resources at your disposal
  • elasticity or scaling on demand

The third one “elasticity or scaling on demand” is what makes the cloud so very appealing to a lot of customers. Scaling is all about balancing running cost with load and performance. If you had an infinite budget you wouldn’t really worry about scaling – in the real world though, it makes sense to get the cost saving benefit and scale only when needed.

Although your site may not experience the “once every four years” kind of surge like the Olympics, you may find that most sites will still have a predictable usage pattern – sometimes even on a day to day basis, based on which you can scale, and get some cost benefits.

Types of scaling

There are two types of scaling:

  • Vertical Scaling: this is when you scale up or down – Windows Azure comes with 5 different instance sizes – XS, S, M, L, and XL. Each instance size comes with different number of cores, CPU speed, memory along with other things including cost/hour.
  • Horizontal Scaling: this is when you scale in or out – By increasing or decreasing the number of instances, you can get true elasticity on demand.

In addition to this, it is also important to know when you are going to scale, you can again, scale in two ways:

  • Proactive: You can scale proactively if you know exactly when to scale. For instance, when your website is hosting a big sale, and you are expecting heaps of traffic, you can just scale out just before the sale starts. Even if you don’t have a sale, you may be able to see a consistent pattern in your site’s traffic (even on  a day to day basis) and scale based on that.
  • Reactive: Sometimes you may not know when the traffic to your site is going to surge. For instance, you may be running a web site that on-sells flight tickets, and an airline may suddenly announce a sale starting mid-night, leading to a lot of traffic on your site. If you did not know about the sale, and your site can’t handle the sudden surge in traffic, then your website could potentially lose out on good business. So, proactive scaling does not always work. You may need to also be reactive, and scale depending on the load on the server, traffic etc.

Scaling can be done manually. To manually do horizontal scaling, all you have to do is go to the Scaling tab in the Azure Management portal (http://manage.windowsazure.com), and increase/decrease the number of instances by dragging the slider. Manual scaling may work well, if you have to do it once in a while, but if you would like to adjust scaling on a day to day basis, then you have to start looking at Autoscaling.

AutoScaling Options

If you want to do Autoscaling, then you have 3 main options –

Roll your own: This is easier said than done. You are probably better of writing applications that provide business value than writing a autoscaling framework from scratch

Use a Service provider: There are companies out there that specialize in Autoscaling. All you have to do is pay them some money, provide your subscription details, and they will take care of all the autoscaling bits. Of course you still have control over the scaling configuration. One such provider is Paraleap with their AzureWatch product offering.

Use an existing framework: This, IMO, is probably the best option for autoscaling. The Patterns and Practices (p&p) group from Microsoft have done all the hard work and released an Application block for Autoscaling. This application block is called WASABi and stands for Windows Azure AutoScaling Application Block (with an i thrown in for Infrastructure – and to make the acronym sound nice). WASABi supports the following features out of the box:

  • Scale based on a time table
  • Scale based on Performance counters, queue size, etc
  • Work to SLAs + budget
  • Keeps configuration separate from code
  • Allows throttling
  • Allows working to billing cycles
  • Supports various hosting options including running in a Worker role
  • In addition, it can also cover multiple roles with one Application

There are three main things you need to know about WASABi: How to install it, how to configure it and how to implement it, which I cover in the following sections.

Installation

WASABi is available as a NuGet package. If you want to install it, just start up your NuGet console from within Visual Studio and type in the following command:

Install-Package EnterpriseLibrary.WindowsAzure.Autoscaling

This will bring in all the libraries and dependencies you will need for your Autoscaling. Typically, I run this against a new Worker role, but in theory you don’t have to – you can even run it as a Console App – which is great for testing purposes.

In addition, I would also recommend getting the Enterprise Library Configuration Editor, which allows editing the App or Web config file easily.

Configuration

There are three pieces of configuration you need to do to get WASABi to work:

  1. The first one is the App or Web config file that specifies where all the configuration information for the Application block are stored. It is best to update this information using the EntLib Configuration Editor.
  2. A Service configuration file: This contains information about the Cloud services you wish to scale. This includes the subscription id, the certificates needed for authenticate, the different roles that need to be scaled, etc.
  3. A rule configuration file: This contains all the rules needed to scale the services.

One point to note is that although the service and rule configurations can be stored as actual files, it is better to store them in a blob, so that you don’t have to redeploy your worker role (assuming of course that you are deploying your Autoscaler as a web role). WASABi has watchers that will pick up any changes you make to the blob.

Implementation

There are 4 main things you need to do actually implement autoscaling:

  • Changes to code: You need to create a worker role (or use an existing one), use NuGet to get WASABi, and make changes to your WorkerRole.cs file
  • Changes to your app.config: As mentioned in the previous section, you need to update your app.config file to specify where the configuration information for WASABi exists
  • Configure your service information: Specify the service information configuration, so that the Autoscaler knows how to connect to the services that need to be scaled
  • Configure the rules: Specify the rules based on which the Autoscaler scales the services

Changes to code

The code changes required to get Autoscaling working WASABi are minimal – actually just about 4 lines of code as shown below (shown in bold):

public class WorkerRole : RoleEntryPoint
{
 private Autoscaler _autoscaler;
 
...
 public override bool OnStart()
 {
     _autoscaler = EnterpriseLibraryContainer.Current.
                            GetInstance();
     _autoscaler.Start();

     ...
 }
 public override void OnStop()
 {
     _autoscaler.Stop();
     ...
 }
}

Changes to App.config

To make changes to the config file, right click the file from the Solution Explorer and choose “Edit Configuration File” from the menu. This will open up the Entlib Configuration Editor.

In the EntLib configuration editor, choose Blocks->Add Autoscaling settings from the menu. This will add the necessary sections in the app.config file. You need to expand and fill out all the necessary fields in the Autoscaling settings section – this includes specifying where the blobs holding the service information and rules are.

image

Creating the Rules store configuration

The rules configuration file in nothing more than an XML file, that has a bunch of constraint and reactive rules. Constraint rules let you set rules in a proactive fashion. Sample constraint rules are shown in the XML snippet below:

<rules xmlns=
   "http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules">    <constraintRules>     <rule name="Default" rank="1">        <actions>          <range min="2" max="6" target="SM.Website"/>        </actions>      </rule>      <rule name="Peak" rank="10">        <timetable startTime="08:00:00" duration="08:00:00" 
                     utcOffset="+10:00" >          <!--<weekly days="Monday Tuesday Wednesday Thursday Friday"/>—>          <daily/>        </timetable>        <actions> ... </actions>     </rule>    </constraintRules>
  </rules>

The XML is fairly self explanatory, but I would like to point out a few things:

  • The constraintRules element contains a bunch of rules
  • Each rule has actions and an optional timetable on which the actions needs to be performed
  • actions contain a set of range (min and max) elements that specify the minimum and maximum instance count of the role that it is targeting
  • When you have conflicting rules, then the rank takes precedence.

If you want to use reactive rules, the XML in rules looks something like this:

<reactiveRules>
  <rule name="ScaleUpOnHighUtilization" rank="15" >
   <when>
     <greater operand="CPU" than ="60"/>
   </when>
   <actions>
      <scale target="SM.Website" by="1"/>
   </actions>
  </rule>
  <rule name="ScaleDownOnLowUtilization" rank="20" >
    <when>
      <less operand="CPU" than ="30"/>
    </when>
    <actions>
      <scale target="SM.Website" by="-1"/>
    </actions>
  </rule>
</reactiveRules>

When you specify reactiveRules, instead of specifying a timetable as you did with constraintRules, you specify a when, followed by the actions to perform. A typical item in actions is scale, which is used to specify the number of instances you want to increase/decrease the role by. In addition to scale, you can also use changeSetting to change the value of a setting that you have defined in your Service configuration file. The application can then check that setting to perform some kind of throttling operation.

The operand specified in the when clause can be specified separately, and looks something like this:

<operands>
   <performanceCounter alias="CPU" 
      performanceCounterName="\Processor(_Total)\% Processor Time"
      source="SM.Website"
      timespan="00:05:00" 
      aggregate="Average"/>

</operands>

Under operands, you can specify the performance counters or queues you want to monitor.

Creating the Service configuration

The service configuration is another XML file that looks something like this:

<serviceModel 
    xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/serviceModel">
 <subscriptions>
   <subscription name="3-Month Free Trial" 
                 subscriptionId=…>
    <services>
     <service dnsPrefix="TechEdAuScaling" 
              slot="Production"
              scalingMode="ScaleAndNotify" 
              notificationRecipients="mahesh@blah.net" >
       <roles>
           <role alias="WebApp" …/>
       </roles>
     </service>
    </services>
    <storageAccounts>
     <storageAccount …>
       <queues>
         <queue alias="dummy-text-queue" 
                queueName="dummy-text-queue"/>
       </queues>
    </storageAccount>
   </subscription>
 </subscriptions>
 <stabilizer>
  <role roleAlias="WebApp" scaleDownCooldown="00:01:00" 
        scaleUpCooldown="00:01:00"
   />
 </stabilizer>
</serviceModel>

As you can see from the XML, the service configuration is  used to specify details about your subscription, what service you intend to scale, the storage accounts you are using, etc.

You will also notice a section called stablizer. The stablizer is used to ensure that oscillations that happen due to alternating scale out and scale in operations are prevented if they happen in quick succession.

In closing

Hopefully this post has given you enough to get started with WASABi. If you want to find out more about WASABi, here are some additional links to get you started:

Casablanca

We (John Azariah and Mahesh Krishnan) gave a talk at Tech Ed Australia this year titled Casablanca: C++ on Azure. The talk itself was slotted in at 8:15 am on the last day of Tech.Ed after a long party the night before. The crowd was small, and although we were initially disappointed by the turn out, we took heart in the fact that this was the most viewed online video at Tech.Ed this year Smile – lots of five star ratings, Facebook likes and tweets.  This post gives you an introduction to Casablanca and highlights the things we talked about in the Tech.Ed presentation.

So, what is Casablanca? Casablanca is an incubation effort from Microsoft with the aim of providing an option for people to run C++ on Windows Azure. Until now, if you were a C++ programmer, the easiest option for you to use C++ would be to create a library and then pinvoke it from C# or VB.NET code. Casablanca gives you an option to do away with things like that. If you are a C++ developer and want to move your code to Azure right away, all Iwe can say is “Hold your horses!” It is, like we said, an incubation effort and  not production ready, yet. But you can download it from the Devlabs site, play with it and provide valuable feedback to the product team.

You are also probably thinking, “Why use C++?” The answer to that question is really “Why not?” Microsoft has been providing developers the option to use various other languages/platforms such as java and Node.js to write for Azure, and now they are giving the same option to C++ programmers – use the language of their choice to write applications in Azure. Although there has been a bit of resurgence in C++ in the last couple of years, we are not really trying to sell C++ to you. If we are writing a Web App that talks to a database, then our first choice would probably still be ASP.NET MVC using C#, and maybe Entity Frameworks to talk to the DB. What we are trying to say is that you still need to use the right language and framework that works best for you, and if C# is the language you are comfortable with, then why change.

On the other hand if you are using C++, then you probably already know why you want to continue using it. You may be using it for cross-platform compatibility or better performance or maybe you have lots of existing legacy code that you can’t be bothered porting across. Whatever the reason, Casablanca gives you an option to bring your C++ code to Azure without having to use another language to talk to its libraries.

The Node influence

When you first start to look at Casablanca code, you will notice how some of the code has some resemblance to Node.js. A simple Hello World example in node will look like this –

var http = require('http');

http.createServer(function (request, response) {

  response.writeHead(200, 
                  {'Content-Type': 'text/plain'});
  respose.end('Hello World!');

}).listen(8080, '127.0.0.1');

The equivalent Hello World in C++ would look something like this –

using namespace http;

http_listener::create("http://127.0.0.1:8080/",
    [](http_request request)    
    {        
    	return request.reply(status_codes::OK, 
                      "text/plain", "Hello World!");
    }).listen();

Notice the similarity? This isn’t by accident. The Casablanca team has been influenced a fair bit by Node and the simplicity by which you can code in node.

Other inclusions

The proliferation of HTML, Web servers, web pages and the various languages to write web applications based on HTML happened in the 90s. C++ may have been around a lot longer than that, but surprisingly, it didn’t ride the HTML wave. Web servers were probably written in C++, but the applications themselves were written using much simpler languages like PHP. Of course, we did have CGI, which you could write using C++, and there were scores of web applications written in C++ but somehow, it really wasn’t the language of choice for writing them. (It didn’t help that scores of C++ developers moved on to things like Java, C#, and Ruby). What C++ needed was a good library or SDK to work with HTTP requests, and process them.

In addition to this, RESTful applications are becoming common place, and is increasingly becoming the preferred way to write services. So, the ability to easily process GET, PUT, POST and DELETE requests in C++ was also needed.

When we talk about RESTful apps, we also need to talk about the format in which the data is sent to/from the server. JSON seems to be the format of choice these days due to the ease with which it works with Javascript.

The Casablanca team took these things into consideration and added classes into Casablanca to work with the HTTP protocol, easily create RESTful apps and work with JSON.

To process the different HTTP actions and write a simple REST application to do CRUD operations, the code will look something like this:

auto listener = http_listener::create(L"http://localhost:8082/books/");

listener.support(http::methods::GET, [=](http_request request)
{
	//Read records from DB and send data back
});

listener.support(http::methods::POST, [=](http_request request)
{
	//Create record from data sent in Request body
});

listener.support(http::methods::PUT, [=](http_request request)
{
	//Update record based on data sent in Request body
});

listener.support(http::methods::DEL, [=](http_request request)
{
	//Delete
});

/* Prevent Listen() from returning until user hits 'Enter' */ 
listener.listen([]() { fgetc(stdin); }).wait();

Notice how easy it is to process the individual HTTP actions? So, how does conversion from and to Json objects work? To convert a C++ object to a Json object and send it back as a response, the code will look something like this:

using namespace http::json;
...

value jsonObj = value::object();
jsonObj[L"Isbn"] = value::string(isbn);
jsonObj[L"Title"] = value::string(title);
...

request.reply(http::status_codes::OK, jsonObj);

To read json data from the request, the code will look something like this:

using namespace http::json;
...


value jsonValue = request.extract_json().get();

isbn = jsonValue[L"Isbn"].as_string();

You have a collection? no problem, the following code snippet shows how you can create a Json array

...
auto elements = http::json::value::element_vector();
for (auto i = mymap.begin(); i != mymap.end(); ++i) 
{
	T t = *i;

	auto jsonOfT = ...; // Convert t to http::json::value
	elements.insert(elements.end(), jsonOfT);
}
return http::json::value::array(elements);

Azure storage

If you are running your application in Windows Azure, then chances are you may also want to use Azure storage. Casablanca provides you with the libraries to be able to do this. The usage, again is quite simple, to create the various clients for blobs, queues and tables the usage is as follow:

storage_credentials creds(storageName, storageKey);

cloud_table_client table_client(tableUrl, creds);

cloud_blob_client blob_client(blobUrl, creds);

cloud_queue_client queue_client(queueUrl, creds);

Notice the consistent way of creating the various client objects. Once you have initialized them, then their usage is quite simple too. The following code snippet shows you how to read data from Table storage:

cloud_table table(table_client, tableName);
query_params params;
...
auto results = table.query_entities(params)
                      .get().results();

for (auto i =  results.begin(); 
          i != result_vector.end(); ++i) 
{
	cloud_table_entity entity = *i;
	entity.match_property(L"ISBN", isbn);
	...
}

Writing to Table storage is not difficult either, as seen in this code snippet:

cloud_table table(table_client, table_name);

cloud_table_entity entity(partitionKey, rowKey);

entity.set(L"ISBN", isbn, cloud_table_entity::String);
...

cloud_table.insert_or_replace_entity(entity);

Writing to blobs, and queues follow a similar pattern of usage.

 

Async

Another one of the main inclusions in Casablanca is the ability to do things in an asynchronous fashion. If you’ve looked at the way things are done on Windows Store applications or used Parallel Patterns Library (PPL), then you would already be familiar with the “promise” syntax. In the previous code snippets, we resisted the urge to use it, as we hadn’t introduced it yet Smile

Also, we have been talking mainly about the server side use of Casablanca, but another thing to highlight is the fact that it can also be used to do client side programming. The following code shows the client side use of Casablanca and how promises can be used:

http::client::http_client client(L"http://someurl/");
client.request(methods::GET, L"/foo.html")
.then(
      [=](pplx::task task)
      {
         http_response response = task.get();
         //Do something with response
         ...
      });

If you need to find out more about ppl and promises, then you should read the article “Asynchronous Programming in C++” written by Artur Laksberg in the MSDN magazine.

Wait, there is more…but first lets get started

Casablanca has also been influenced by Erlang, and the concept of Actors, but let’s talk about it another post. To get started with Casablanca, download it from the DevLabs site. It is available for both VS 2010 and 2012. At the time of writing this post, the version of Casablanca up on the site does not work with Visual Studio 2012 RTM, and a few code snippets shown above do not work (we’ve been working on a private build). But don’t despair, a new version that works on VS 2012 RTM is coming soon…and we’ll have another post to get you started.