Clouds for Clunkers?

Its been several months since I did a more editorial styled update, so when this popped into my head this morning (its only 6am my time as I write this) I had to share it. I also plan to use it in my Windows Azure presentation this evening.

One of the key things you hear being asked about cloud computing is “what is the value”. Well recently the governments “Cash for Clunkers” program highlighted a real world problem that could be addressed by could computing. This short term program had a website where dealers could go and submit their sales for reimbursement. Unfortunately, as the deadline for the program approached, traffic on the site overwhelmed and eventually crashed it.

This is an ideal example for how cloud computing could have helped prevent this issue. The program was a short term program, so it wouldn’t have made sense to acquire new hardware simply to host this site. By using a cloud hosting provider, the program could have quickly gotten resources in place to host the website. No significant up-front costs from purchasing hardware or putting it in place. Just swipe a credit card and start hosting.

Then there’s the big issue of capacity planning. Anyone that’s ever dealt with a potentially high demand, time-bound program such as this would have easily predicted that the spike in traffic could (and probably would) happen towards the programs end. But since its a short-term program, imagine the costs associated with purchasing and setting up all the resources necessary to handle the estimated peak load. A load that would only last several days. Instead, by hosting it in the cloud, you can scale up your resources during peak utilization and then just as quickly scale them back down when the spike is over. Little fuss and almost no muss. And definitely much less expensive.

To the cloud computing pundits, this example is definitely a no-brainer. But for those still curious or cautious about the benefits of cloud computing, here is a highly visible example of where cloud computing could have helped prevent a high profile failure and also helped an organization realize a substantial cost savings.

.NET Service Bus (Part 2 continued) – Hands on Queues

Back again in rapid succession and feeing very strong. Over the weekend I smoked a bunch of turkey (most yummy) and also finally made my first weight loss goal. How did I decide to celebrate these accomplishments you ask…. I decided that I’d jump right back in with another blog post about .NET Service Bus queues. Yes, I’m a geek.

If you read my last post, you may recall that I said that .NSB queues were more robust and I pointed out a few key differences. Well, I was understanding things just a bit. They are actually significantly more robust and also require a few different techniques when dealing with them. In this update I will explore those differences in a bit more detail as well as cover the basics of sending and receiving messages via .NET Service Bus queues.

Queue Policy (yeah for governance)

Azure Storage queues are pretty basic. As far as I can tell, they were created to be a simple, lightweight option for doing inter-process communication. As such, they were kept pretty simple, the single-scoop vanilla ice cream of queue storage mechanism. Well the .NSB Queues are closer to what I think of as traditional queues. Each queue has a policy that dictates how the queue will behave. Here are some of the queue policy settings:

Property Type Description
Authorization AuthorizationPolicy Determines if authorization is required to send and/or receive messages to a queue.
Discoverability DiscoverabilityPolicy Is access public, or can it only be discovered by managers (default), listeners, or senders (based on Access Control Service token)
ExpirationInstance DateTime When the queue will expire. If not periodically renewed, the queue and all its messages will be deleted (unrecoverable).
MaxMessageAge TimeSpan Messages that have been in the queue in excess of the TimeSpan value are dropped. Default is 10 minutes, maximum is 7 days.
Overflow OverflowPolicy How to handle messages when the queue is full.
PoisonMessageDrop EndpointAddress Where do poison (unreadable) messages get sent?
TransportProtection TransportProtectionPolicy sets if a secure connection is required to send to or receive from this queue

There are other properties (some of which appear to be for future use), but these are the ones I wanted to call to your attention today.

Of key interest are MaxMessageAge and PoisonMessageDrop. When you put a message into an Azure Storage queue, it stays there until either the message or the queue is removed. .NSB queues will automatically purge messages that exceed the specified TimeSpan value. And as anyone that has worked with queues will tell you, occasionally messages get “stuck” and can’t be read. So its nice to be able to using PoisonMessageDrop to specify a SOAP endpoint to which these messages can be directed.

Yeah, but how do I send/receive?

Ok, enough blabbering, this is supposed to be a hands-on blog. How about we get to some hands-on already. Any direct interaction with the queue is done via the QueueClient object. So we need to get an instance of that object for our queue before we start doing any real work. To do that we need the QueueManagementClient again.

In my last post we started by crafting our URI and creating TransportClientEndpointBehavior based credentials. We’ll need those same items this time around, but instead of calling the QueueManagementClient’s CreateQueue method with a QueuePolicy object, we’re instead going to call the GetQueue method. Here’s our code snippit:

            // create queue URI
            Uri tmpURI = ServiceBusEnvironment.CreateServiceUri("sb", SolutionName, "/" + textBox1.Text.Trim());

            // authenticate against the queue manager
            TransportClientEndpointBehavior tmpCredentials = new TransportClientEndpointBehavior();
            tmpCredentials.CredentialType = TransportClientCredentialType.UserNamePassword;
            tmpCredentials.Credentials.UserName.UserName = SolutionName;
            tmpCredentials.Credentials.UserName.Password = Password;

            QueueClient tmpQueue = QueueManagementClient.GetQueue(tmpCredentials, tmpURI);

The result is an instance of QueueClient called tmpQueue that we can now use to send/receive messages in our queue.

Sending and Receiving Messages (finally)

Alright, so now we’re ready to start sending and receiving messages. Doing this is pretty simple.

Here’s an example of a send…

            System.ServiceModel.Channels.Message tmpMessage =
                System.ServiceModel.Channels.Message.CreateMessage(MessageVersion.Default,"urn:testsend", "my message");
            tmpQueue.Send(tmpMessage, TimeSpan.FromSeconds(30));

Simple enough. Since I’m using a Windows Forms application as my host, I need to be careful with ambiguous references to the Message class (the Windows.Forms namespace also has such a class). I can also change the MessageVersion to “Default”. But I did some testing and Soap12WSAddressing10 works as well. So depending on your specific scenario, it could get even simpler.

Next up is reading a message…

            System.ServiceModel.Channels.Message tmpReadMsg = tmpQueue.Retrieve();
            MessageBox.Show(tmpReadMsg.GetBody<string>());

Now this is where some additional differences between Azure Storage and .NSB queues start to become apparent. The Retrieve method automatically removes the message from the queue. This differs from Azure Storage where a second call is required to remove it. Additionally, unlike Azure Storage, if we want to retrieve multiple messages, we need to use a different method (RetrieveMulitiple) to get them. However, unlike Azure Storage, the retrieval of multiple items does not appear to be limited to a maximum of 25 messages (can’t find confirmation on this though, so I’ll try to do some testing).

But… but… what about peeking?

Ok, so we want to see what’s in a queue without actually removing it. Simple enough, we just switch to the PeekLock and PeekLockMultiple methods. Notice the “Lock” adjective in both those methods names. Yes, they actually operate more like way messages are read from Azure Storage. After a PeekLock (or PeekLockMultiple), a separate call is needed to DeleteLockedMessage or ReleaseLock methods using the retrieved (or peeked) Message object. If this is not done, the peeked message will be automatically unlocked after 60 seconds. Unfortunately, unlike Azure Storage queues, there doesn’t appear to be a way to vary the timeout period.

Confused yet?

If you’ve worked with Azure Storage queues, you’re likely feeling a bit confused right now. While Azure Storage and .NSB queues both serve a similar purposes, the actual implementations are radically different. .NSB queues offer policy enforcements, access control, and router integration. Azure Storage queues have greater persistence and flexibility in retrieval options. So you’ll need to weigh which option is best suited to your needs.

Next time, we’re going to be kicking things up yet another notch as I start into .NSB routers. Things will get really fun as we start combining queues and routers together to handle how messages get processed.

.NET Service Bus (Part2) – Hands on with Queues

Its been an unforgivably long time since I wrote Part 1 of my series of hands articles on with the .NET Service Bus. I’ve tried to convince myself it was because I was confused by the WCF nature of the service relay. I also told myself to shelve the series while I started working on my “App Fabric” architecture model. Well, yesterday I realized I was just making things too hard. The service relay is just one piece of the .NET Service Bus which in turn is just one component of .NET Services. And while the service relay is an great piece, I was trying to do more with it when I needed too.

So with this epiphany in hand, I’m turning my attention to the another feature of the .NET Service Bus, queues.

I spent much of my playtime with Windows Azure messing with Azure Storage’s queue mechanism. IIMHO, .NSB’s queues are a little more robust and I’m happy about that. It also compliments the relay service nicely. The relay service is great when both the host and subscriber and online. But if either one could be offline, a queue is a great way to relay messages. There are also a series of important differences with how messages are pulled from .NSB queues. However, we’re gonna cover that in my next post.

NOTE: This article presumes you already have a .NET Services solution created and know the solution name and password.

What’s the same and what’s different

As I just mentioned, .NSB’s queues are a little more robust. But it would be helpful to put this in a bit of context by comparing the two.

Both are based on RESTful services that require authorization for access. And with both you can create, delete, and list queues as well as put and retrieve message from them. The .NSB version of Queues however has a fully supported API for .NET access (the StorageClient api for Azure storage is only a sample right now). You can define policies for .NSB queues and control access a bit more granularly. Finally, we have the ability to monitor for queue exceptions (possibly caused by policy violations).

As this weren’t enough, we can also hook these queues up to another .NSB feature, routers. But more on that another day. :)

Creating our first queue

So before we can start working with our queues, we need to actually create them. The process of creating a queue is pretty simple. You’ll define its policy and using that policy, create the queue. So lets get started with our hands on..

Fire up Visual Studio and create a windows form application, drop a text box and button onto the form, and start a “Click” event handler for the button. Next, we need to add references for .NET Service Bus SDK assembly (Microsoft.ServiceBus), System.ServiceModel, and System.RunTime.Serialization. Lastly, put a using clause for Microsoft.ServiceBus into the code-behind to make things easier later on.

We’re going to do the heavy lifting inside our event handler. Create two string values that will store our solution name and password for use in the code (I know, not a best practice, but this is just a demo *shrug*). The remaining work is split into four steps: create our URI, create our authentication credentials, define the queue policy, create the queue.

Define the URI

For creating our URI, we’re going to use ServiceBusEnvironment.CreateServiceUri. This is a solid best practice for working with the service bus.

    Uri tmpURI = ServiceBusEnvironment.CreateServiceUri("sb", SolutionName, "/" + textBox1.Text.Trim());

Notice that we’re using our queue name (from the text box) as the path of our URI. We’ve also specified the protocol as “sb” because we’re addressing the service bus itself, not the queue.

Papers Please (Authentication Credentials)

Our URI specified “sb” as the protocol because we’re going to talk to the service bus. As such, we need to present our credentials. We’ll set up a simple username/password set using the solution credentials.

    TransportClientEndpointBehavior tmpCredentials = new TransportClientEndpointBehavior();
    tmpCredentials.CredentialType = TransportClientCredentialType.UserNamePassword;
    tmpCredentials.Credentials.UserName.UserName = SolutionName;
    tmpCredentials.Credentials.UserName.Password = Password;

Nothing new hear really. Its not all that different then when we were relaying messages through the bus via WCF. The SolutioName and Password values are the strings we created earlier and should be valued appropriately for our .NSB solution.

Queue Policy (this is where things get interesting)

This is were we really get to see a key difference between Azure Storage queues and .NSB queues. To create a .NSB queue, we must define a policy that indicates how the queue will behave. We do this using the QueuePolicy class and its properties. The MSDN documentation for this class lists them all, so for the moment, I’ll just discuss the ones we’re using in my example.

    QueuePolicy tmpPolicy = new QueuePolicy();
    tmpPolicy.Discoverability = DiscoverabilityPolicy.Public;
    tmpPolicy.Authorization = AuthorizationPolicy.NotRequired;
    tmpPolicy.ExpirationInstant = DateTime.Now.AddDays(7);

Discoverability lets us control if this queue will be publically visible. Since I’ve seen this to true, anyone going to my solution’s URI will be able to see the ATOM of my queues. Authorization sets the type of credentials that are needed to access the service. And finally, ExpirationInstant determines when our queues resources can be reclaimed. This last time is an important distinction between Azure Storage and .NSB queues. With Azure Storage, once a queue is created, you need to explicitly remove it. With .NSB, we need to periodically update/renew this value if we want the queue’s existence to continue.

Now, I don’t know why this is the case, I would surmise it is because unlike with Azure Storage, you aren’t paying for the resources required to persist your queue. Given this, its reasonable that steps were taken to allow the .NET Service Bus to reclaim unused resources.

Create the queue. It Lives!

The final step is to create the queue. This is super simple…

    QueueManagementClient.CreateQueue(tmpCredentials, tmpURI, tmpPolicy);

QueueManagementClient is what handles the interaction with the .NSB queue manager. We’re only calling one of several static methods contained in this class. We can also delete a queue, get an instance of QueueClient associated with a specific queue, renew a queue, or get just a queues policy. The only item lacking here that I’d like to see is a way to get a list of all the queues as we could with Azure storage. However, since we can crawl the ATOM feed for our solution and find any public queues, its not something I’m going to lose sleep over.

*ponders an idea for another blog post*

Wrapping up

That’s all I wanted to cover for today (I’m getting tired of my own SUPER long blog posts). Thanks for stopping by. Next time I’m going to dig into the QueueClient and working with the queue contents themselves.

Application Fabric Architecture

So, a couple weeks back I rallied on a bit about the need for health and activity monitoring in cloud computing solutions. I made the argument that solution architects cannot depend on the service providers to meet these needs. However, I didn’t offer any real solutions. Since that time I’ve started putting some time and thought into the creation (or location) of design patterns intended to help address these concerns within the confines of a cloud computing based solution. I wasn’t able to find anything that seemed to echo my own thoughts, so I’d like to give you my preliminary work on what I’m calling the “Application Fabric Architecture”.

Overview

As I started trying to find a solution to my dilemma, I looked for existing solutions. I wanted examples of systems that have to manage application systems spread across multiple instances but yet still be able to maintain them as a cohesive whole. The examples that really leaped out at me were those of the various Cloud Computing providers themselves. The ones I looked at all seemed to have this notion of a fabric. The fabric would contain the individual instances of the application(s) which were managed by a centralized controller. Furthermore, each instance had an agent that was responsible for monitoring the status of the instance and either taking direction from the controller or feeding information to it.

The result looks something like this:

FabricOverview

Pretty straightforward I know. Also a bit of a “well duh” once I started visualizing it.

The Primary Components

The Application Fabric Architecture (if anyone has a better idea of a name, please let me know), is comprised of 4 primary components. The Controller, the Agent, the Application Node, and a Database (some type of persistent storage). The duties of each of these components, as well as how they interact, is what I’ve really been putting my thoughts too.

The Application Node is the simplest (in terms of architecture role) of all the components. The Node is the grunt that has the responsibility for doing the manual labor the application requires. This could be research computing, message processing, or just serving up web pages.  Its not aware of and really doesn’t care about other instances or the architecture components beyond the what it needs to know to do its job.

The Controller is the brains of our architecture. In theory, its responsible for checking the status of all the application nodes and acting on that status. It can also potentially perform such tasks as starting/stopping nodes (if a suitable host provider API is available), serving up configuration data (such as security credentials), or even delegating workloads. In practice, well… I’ll get to that another day.

Since the Node is not directly aware of the Controller, we need a component that handles this communication and feeds information back to the Controller, this is the Agent. The Agent feeds information up to the Controller and in turn takes commands from it. Its responsible for registering the application node with the controller when it starts up, as well as trying to tell the controller when a node stops (as best it can).

Lastly, we need a Configuration Database. This data source does not have to be an actual database, but it does need to be some type of persistent storage (it could be a file, or even another process running elsewhere). The reason we need this is that because of the distributed nature of our application, we won’t always be able to have a direct connection between the Controller and the agents. So the database acts as an intermediary. Both the agents and the controller need to be able to reach it so they can then use it to relay messages.

Of course, this is just the beginning. The Agents and Controller could communicate via service calls, a relay bus, queues, or by dropping files onto a shared folder structure. Additionally, the functionality provided by the cloud computing hosting system will have a significant impact on what type of functionality will be available to the controller and its agents. But regardless of the details, its my belief that these basic component roles will still be present.

Possible Uses

So once this is in place, what are some possible uses for this architecture? Well, this is where my mind starts getting blown. A simple example I quickly came up with is this…

  1. Controller calls host providers and triggers the startup of a new instance
  2. New instance starts and initializes the agent
  3. Agent registers the instance with the controller and requests configuration data
  4. Controller acknowledges the registration and responds with necessary configuration data (security credentials, endpoints, configuration settings, etc…)
  5. Agent receives data and stores it for retrieval by the Node (exposed via properties?)
  6. Node begins performing work

Of course, much of this will depend on the mechanisms for allowing the agents and controller to communicate as well as the options the controller has to give direction to the cloud host. This is also just the beginning of nearly endless possibilities. Possibilities I look forward to exploring over the coming months.

What Next?

I know its not much yet, but its a starting point. In future updates, I’m going to look a bit more in depth at the tasks (command delivery, status updates, registration) and issues (bandwidth consumption, availability, connectivity) that we’ll need to address which this architecture. Over time, this might even expand into how to coordinate multiple controllers running in different geographical locations.

In the meantime, I’d really appreciate any feedback on what I’ve presented here. Its very much in an incubation state, but I think it has potential. The eventual goal is to drive this down to a series of class/object designs and maybe even some implementation templates (something akin to the Enterprise Library possibly). So it will definitely be long road with lots of work before its finalized.

Till next time and I look forward to hearing from you!

Weekly Azure Digest – August 7th, 2009

As promised, I’m gonna keep things updating while I’m working on my Cloud Architecture model/pattern project by sharing a weekly digest newsletter that I send out to my Sogeti Colleagues here in Minneapolis. Below is the edition for August 7th, 2009.
 
Aside from yesterday’s DDOS attacks on Twitter, there’s not much on the general cloud computing front this week. But I do have a couple BIG item for Microsoft Azure.
 
At 2pm today, a semi-formal chat will be held by the Azure product team. They’re looking for feedback and questions on Azure. Expect some of the big names in the Azure evangelistic community to be present. You can attend by going to: http://wazl.cloudapp.net/ (note from the URL, this appears to have been built on Azure)
 
The Twin Cities Cloud Computing User Group has moved their August meeting to the 26th at 8:30am. Dave Chappell of Chappell Associates (not the comedian) is coming to speak.  More details can be found at: http://www.tccloud.com/ The time may not be the best, but I highly recommend making time to attend.
 
And on a personal note, I was interviewed last week by Carl Brooks of SearchCloudComputing.com (an online media site). Our discussion resulted in two separate articles in which I was quoted. One of which Carl didn’t even plan for but arose from our discussions. You can find both these articles at:  http://bit.ly/2emO2S and http://bit.ly/3NH9QM
 
That’s all for this week. Please feel free to forward this on to anyone or let me know if you’d like to be on the regular distribution list.

And now a message from our sponsors…

No, I haven’t stopped the blog and I still very much want to continue my series on .NET Services. The challenge I’m running into is that when we’re talking .NET development, you really need to understand WCF to leverage the relay service. Unfortunately, WCF is not a strong suit for me and despite my best attempts, I continue to struggle with it. So I’ve ordered a nice little book that should help me get up to speed with them and once I’ve digested that, I’ll be back to .NET Services.

Meanwhile, I do also have a new Azure related project that popped into my head yesterday. I’ve been pondering ways to link my post on health/activity monitoring to Azure development in a real way and had this crazy idea for a cloud architecture approach that provides this type of application monitoring. So I’ve started firming up the idea and comparing it against such things and CSLA and MEBA as well as looking for any existing design patterns that parallel it. I don’t want to give too much away until I get it shaped up, but suffice to say I’m exploring architecting a cloud application in much the same way cloud computing PaaS providers seem to provision and manage their solution offerings.

The goal will be to create a series of design patterns intended to help support and potentially manage application deployed into the cloud. Adding greater death to health and activity monitoring as well as delivering mechanisms for configuration management. If I can take things far enough, it may even include sample class libraries to aid in the management of Windows Azure applications (auto-scaling of instances and forced instance restarts). Its a big goal, and I’m sure to be asking for help as things grow. But for now I’m trying to get my basic models sorted out.

In the meantime, in the absence of anything useful to post, I plan to start posting copies of a newsletter style email I’ve been distributing to my Sogeti colleagues. They’re short digests of some of the new highlights I see each week. Its filler, but at least its on-topic filler.

As always, if there’s something you’d care to hear about, please just drop me a line at brent.stineman@us.sogetic.om to let me know. :) I like answering questions.

Follow

Get every new post delivered to your Inbox.

Join 1,148 other followers