What good is the cloud, really?

I need to ask you all to once again bear with me. I’m in recovery after a long weekend that involved camping, a friend’s Memorial Day picnic, and a nearly 150+ mile round trip to visit my wife’s ailing grandfather. All were examples of time VERY well spent, but I’m both physically and emotionally drained. But I won’t that stop me from rambling on about a topic I spent considerable time pondering over the weekend. What good is the cloud?

We’ve heard from the platform pundits and technical evangelists. The cloud will save us money. The cloud will be more flexible. Things will get to market faster. Manna will fall from heaven and dogs and cats will play together in fields of flowers. I realized in what goes for an epiphany in my small mind that we’ve heard all these before. And we’ve also be disappointed by these claims time and time again. Over the last few months I’ve spent a non-trivial amount of time reading about what the cloud has to offer. I’ve also invested a great deal of personal time learning how to use Microsoft’s Azure Services to making program code jump through several hoops. But with this epiphany, I realized there was one thing still missing. What would I really use it for.

Much of the available text on cloud computing focuses on new applications and/or products. Even more focuses on the various challenges that face anyone wanting to get into cloud computing. Be this security, privacy, ownership, accessibility, or pricing. What I want to start seeing more of is real problems facing businesses today and how the cloud will solve these problems either better then traditional methods or possibly where no traditional application could.

An example could be how to make portions of an on-premise SharePoint application visible to an application or user outside of your network without compromising it. While this is a problem that could be solved by traditional means, having a firewall friendly, externally accessible service bus as well as options for user authentication could help speed such a solution to delivery. What if you are in a situation where you have two different networks that need to be connected? Maybe you have a business intelligence process that needs to be run and takes awhile. it only has to be run once or twice a year and you’d rather not set aside hardware just for it that could then sit idle the rest of the year.

I think there are a large number of real world challenges businesses are facing. Challenges that Cloud Computing is uniquely poised to bring tremendous added value too. Instead of focusing on big pictures and hard to quantify cost savings, I’d really like to see more examples of situations that exist in today’s organizations that the cloud could help address.

I know these are out there. I’ve tossed up a couple I can think of. I know others have and are finding more of them each day. So its time to start hearing about them. These low hanging fruit will make a compelling arguments to help demonstrate to shrewd decision makers how the cloud can help add value. Without requiring them to make large long-term decisions.


What is Cloud Computing

Last week the National Institute of Standards and Technology released their draft definition of cloud computing. I’ve read several blogs and articles that express their opinions on the matter and realized why should my opinion be any less important. So here I am back on my soap box to give you my two bits on the subject. Ok, so its not a soapbox so much as a cardboard box that promptly collapsed flat when I tried to step on. But I’m still standing on it and you’re here so I’m going to assume you have at least a passing interest in what I have to say.

Why do we care about a definition?

Like every other industry buzz word of the last 30 years, cloud computing has caught on and is being bandied about as the silver bullet for just about everything. Yet nearly everyone is using a different definition. This is only adds to the confusion that many IT managers may be feeling and when they are unsure about a technology, you can bet they won’t want to put their critical business functions on it. At least not without a darn good reason.

So the first reason for a definition is to clear the air a bit and make sure everyone has the same basic foundation.

The second reason is to help establish certain concepts and terminology that can be used to help discuss cloud computing so that we can all talk the same language. Lets say two people get together for a discussion on cloud computing. They both have the same definition but one speaks English while the other speaks only Mandarin Chinese. Having a common definition really isn’t going to help them because their vernacular is completely different.

The NIST’s Definition

Go read the full definition (its only 3 pages) if you like. I’ll just summarize it here:

  • Cloud Computing solutions must provided on-demand self-service, be accessible from anywhere on the internet, provide location independent resources, and exhibit rapid elasticity (aka quickly scalable), and fees should be based on usage (pay per use)
  • the Clouds themselves can exist as a private (dedicated solution), community (think farmer’s co-op), public (EC2), or hybrid infrastructure (combination of other types)

Furthermore, cloud solutions exist as 3 types:

  • Software as a Service (SaaS) – access application services (Google Apps, Yahoo Mail, crm, etc…)
  • Platform as a Service (PaaS) – deploy your application into someone else’s infrastructure
  • Infrastructure as a Service (IaaS) – you manage your portion of the cloud and the bits that are on it

Not a bad first stab actually. I don’t necessarily agree that rapid elasticity MUST be a requirement. For many SaaS offerings, I don’t believe this applies. If you’re Joe average using a hosted email solution, you really don’t care about the ability to rapidly increase capacity. Its more the job of the vendor to make sure they plan for and manage the growth of their service. So they must have the ability to scale, but its not something that has to be quick or that you need to be able to manage yourself.

I also don’t agree with a small note that these solutions need to be accessible via thin clients. Limiting ourselves like this seems kind of pointless.

So how does this help?

Now we’re to the crux of the matter. IMHO, cloud computing isn’t really anything new. Its been around by my account for at least 10-15 years. Its just that today we’re finally getting to the point where the technology is making it more mainstream and easier to consume. IT managers are starting to demand the kind of convenience they’ve been getting from end user applications in their enterprise solutions. By using these terms and putting them in context, we can help address many of the perceptions and fears that are out there. Here’s my short list…

“Cloud computing is too cutting edge, we’re not an industry leader.” – Remember back in the early 90’s when you signed onto Compuserve for your company’s email solution, you were consuming Software as a Service. So this is definitely a road that has been well plowed.

“There’s no money in providing cloud solutions.” There’s a relatively small company in California that would beg to differ this point. They have millions of subscribers, each paying only about $15 a month. They host this highly successful SaaS offering in their private datacenter and provide their users with a custom client to access their data over the internet from anywhere in the world. This product is estimated to generate about $250 million annually. The product is one you’ve heard of but likely never thought of as a cloud solution… the computer game World of Warcraft.

“Why would I let someone else host my applications and/or data” – When was the last time you set foot in your own corporate datacenter? You have a group of network jockeys that keep things up and running. These folks might be your own employees but could just as likely be contractors. Heck, the datacenter itself likely isn’t even in a building you own but instead in a larger center that you simply pay for space in. You’re already consuming PaaS or IaaS in a fashion.

So lets have a seat and start a conversation

Ultimately, what the NIST or any other ‘governing body’ has to say doesn’t really matter all that much (at least to me). The real point is to get folks to start agreeing on what things mean. The terms will change of course (its the nature of language and also an interesting topic itself), but at least these attempts at definition allow us to start the dialog that will eventually enable us to get to the real work of solving problems. And isn’t that what we’re really here for?

Azure Storage – Hands on with Queues, Part 3.5

Two blog posts in one week. Just don’t get used to it. I have a family and a day job. 🙂 Besides, the lilacs are in bloom here in Minnesota and my thoughts are officially turning towards spring and spending more time outdoors. And those outdoor moments will involve clouds in the sky, not on the internet.

That all said, this post is really to just post an update to my QueueDemo solution that combines enhancements I’ve made as a result of my last article on service configuration options. Putting my own words to practice, I have updated the QueueDemo so that it can now be used against either Development or Hosted Storage. The changes are as follows:

  • enhanced constructor to pull account credentials and URI endpoint from configuration
  • enhance URI to check host and create full URI in either path or host style as appropriate

There’s also one odd bug I’m still wrestling with and have in fact reported to Microsoft. It appears that the development fabric will allow the creation of queue’s with upper case letters in the names. According to the Azure Queue API documentation this is not supposed to be the case and indeed is not when using hosted storage. So you may notice the addition of a call to the ToLower method in the AzureQueue class constructor. Time will tell if I’m missing something on my end or if there is indeed a bug in the development SDK. As yet, MS is unable to reproduce the issue on their end. So just keep the queue name rules in mind if you get a “Bad Request” response.

Heard back from Microsoft yesterday and I wasn’t crazy. Turns out that Queuetst would produce the expected “Bad Request” response but something like “tstQueue” wouldn’t. Now that its been reproduced, the bug is being escalated. Woot, I contributed!

In the end though, I was able to get the sample project up and running just fine in either development storage or hosted storage. Simply tweak the service configuration file to change which you want to work with. I’ve uploaded the new zip file for you to play with.

The latest version of the file can be found at: http://cid-61aea8168d26ea6b.skydrive.live.com/self.aspx/.Public/QueueDemo.zip

Quick “thank you”

I would also like thank everyone that’s been coming here. This blog recently surpassed 500 page views. Its a small number I’ll admit. But nice progress given my lack of anything even remotely resembling notoriety and that I’ve only been posting a few months. I am extremely pleased with the rate at which traffic is growing. I still find it a bit surprising that folks are genuinely interested in what I have to say and pleased that it appears my conversational writing style is one visitors are finding comfortable.

So “Thank you” for coming and sharing this blog your friends.

Azure Configuration Options

This article contains now obsolete information. Please refer to my update article that contains details on what to do when using the non-CTP version of Windows Azure.

I’m happy to report that moving forward, my Azure Development VPC image will be using Windows 7! While this won’t really mean any difference to those of you reading this blog, it does make me happy. The new VPC image performs faster than the Vista one and as yet I’m not having any real issues with it (aside from having to figure out where stuff’s at).

Between getting my new VPC up and running and some distracting thoughts regarding how to use the cloud to extend legacy on-premise applications (long story), I have managed to get this next article up. Today I want to briefly discuss configuration options in Windows Azure.

Anyone that’s been doing .NET development is likely used to using the .config files to store configuration settings. With them you can make a quick tweak to your application by just firing up your favorite text editor and making the change. Now in an on-premise application this worked well because you usually had the ability to log into the hosting server and make the change. The downside was that if the application was hosted on multiple servers, you have to log into each server and make the same change. All the while hoping really hard that you didn’t mess one up or miss an instance.

Now lets move this scenario into the cloud. We have multiple instances of our application all running in the cloud, we also don’t have remote access to the server to make the changes ourselves. So now, we have to change our application, rebuild it, publish it to the cloud, deploy it to staging, review it, and then deploy it to production. All this for something as simple as changing a minor configuration option in a text file. The upside is that with one deployment, Azure handles updating all instances of the application for us. But have no fear, there is another option.

If you recall, back in Part 1 of my series on Azure Queues, I talked about adding the Microsoft.ServiceHosting.ServiceRuntime namespace to my class library. At the time I stated I wasn’t sure we needed it and in hindsight we really didn’t (that app would have run as a traditional asp.net application). Until now. You also hopefully recall our discussion about the ServiceConfiguration and ServiceDefinition files from my Hands on with the Azure Web Role. Together, these two items are the solution to our problem. We’ll put our settings into the ServiceConfiguration file then access them with the RoleManager class from the Microsoft.ServiceHosting.ServiceRuntime namespace.

Here we go….

Service Configuration and Definition files

A few weeks back, Ryan Dunn, author and technical Evangelist for Microsoft updated his blog with a post on why Windows Azure uses these files. In a nutshell, these files were created to allow for a configuration option that exists outside of the service deployment packages themselves.

If you’ve read the MSDN article on Understanding a Hosted Service Architecture, you already know that the Service Definition file is bundled with our deployment package. It tells the Azure Fabric what types of roles are in the package as well as what configuration options exist in the Service Configuration file. The definition will be used by the RoleManager class to allow our cloud services to access those configuration properties. These two files, configuration and definition, work hand in hand. So we’ll need to update our service definition file with our custom properties and then update the configuration with the actual values.

I’m going to use my previous QueueDemo project for this, so lets start by altering that solution’s service definition file as follows:


In the image at the right, I’ve highlighted our changes to my services configuration definition file. Inside of the web role node, I’ve added a new ConfigurationSettings node which details the three settings we’ll be adding for this solution: AS_URI, AS_AccountName, AS_SharedKey.

You can see we can create separate configuration settings for both the Web Role and (if it was present), the Worker Role. Unfortunately, at this time there’s no way to create a single configuration setting that is shared by both roles. Personally, I’m hoping I’ve either overlooked something or that this will be added in the future. If someone knows different, please let me know.

Heard back from the Azure team that this is indeed the case currently. No word on if it will change in the future or not.

With this done, now we have to switch to the service configuration file and set the values for our new keys.


I’ve put in false values, so you’ll want to insert your own Azure Storage values into settings. If you want, the local storage credentials will work just fine if you want to use the QueueDemo application as I left it at the end of that series.

Accessing Service Configuration

Creating the service configuration is only half the equation. We now need to use the RoleManager to access these settings. Among other things, the RoleManager class allows us write to the service log, access local storage (not to be confused with the Azure Storage services), and to access our configuration settings.

GetConfigurationSetting is a static method of the RoleManager class. We give this method the name of the setting we want to retrieve the setting for and it returns the value (if it exists). If the requested value does not exist, a RoleException will be thrown.

Here’s my example:

        public AzureQueue(): base()
            myURI = RoleManager.GetConfigurationSetting("AS_URI");

So what does this buy us?

We’ve got a configuration file, and we have accessed it from our application. But the big question now is how does this help us solve our initial problem of updating a simple entry without having to redeploy our application.


The picture to the left is a portion of the Windows Azure cloud service management page. See that “Configure…” button center below the glowey cube, that’s our solution.

Once our cloud service (web or worker, makes no difference) is deployed, we can click that button to directly access the configuration file and make changes. The Azure Fabric then pushes those changes out to all the instances so the changes can take affect.

Hopefully, once the Windows Azure management API is announced, we’ll see the ability to update this via a service. Combine that with various monitors to see how the instances of our services are running and we have a really spiffy way to remotely manage our web applications.  I look forward to revisiting this subject when/if that is possible.

Likes sands through the hourglass

That’s all I have for now. I’m still messing with my QueueDemo sample project to get it working with hosted storage (darn these useless “bad request” exceptions). After that, I plan another ‘hands on’ style session with worker roles. Once I get all that out of the way, I’ll start messing with .NET services. With legacy application integration being at the forefront of my mind lately, I’m especially looking forward to working with the service bus.

Until then, if there’s something you’d like to see me mess with, don’t hesitate to drop me a line at brent@stinemans.org.

Till next time!

App Dev in the cloud. What is the benefit?

Taking a bit of a detour from Azure implementation examples into general cloud concepts territory this time. Don’t worry, I’ll be back in the thick of it soon enough.

Several weeks ago I had a coworker I respect highly ask me what appeared to be a simple question. Why would someone already subscribing to one or more SaaS offerings (such as say Microsoft’s SharePoint Online) want to consider Microsoft’s Azure Services? Seems simple until I really started to try and focus on what the concrete benefits would be to such a decision. How would I talk to that companies EIO’s and make the case for doing app development in the cloud.

Then yesterday I attended a webinar given by RightScale. I joined this webinar because my employer’s parent company, Cap Gemini,  recently signed a partnership agreement with RightScale. With this news I wanted to learn more about what Rightscale was about. The hour long session was worthwhile. The focus was obviously on Amazon’s cloud offering, but there was still plenty of food for thought. In fact, there are two key items I left with that I hadn’t heard put quite so well before.

There are three types of cloud computing infrastructures:

  • Public Clouds – on the internet, built for multi-tenant, subscriber based solution offerings
  • Private Clouds – internal systems, built within an enterprise’s existing datacenters
  • Hybrid Clouds – a mix of the two previous types

The second idea was one I’ve seen before in various Microsoft slide-decks and have even spoken to others about myself. But recently I had let the topic languish a bit as I focused more on learning the ins and outs of Microsoft’s Azure Services. This concept is about the types of cloud offerings:

  • SaaS – software as a service. complete solution offerings delivered via subscription from the cloud
  • PaaS – platform as a service. Putting operating systems in the cloud for you to put your own applications on
  • IaaS – infrastructure as a service. Cloud based management of either an internal or external infrastructure

Course, these two concepts probably fall into the ‘well duh’ category for most folks working in the cloud computing space. However, I know at least from personal experience that its pretty easy to get lost in whichever solution you’re looking at most closely. And understanding what these terms mean and how they relate to your needs can prove to be helpful when sizing up possible solutions.

Back to topic, how does something like Microsoft’s Azure Services (a PaaS) benefit someone that is already consuming one or more SaaS solutions.

Well the obvious answer is that Azure Services are a PaaS and not a SaaS. When consuming a SaaS that resides in a public cloud, you’re consuming a specific product with its (usually limited) options for customization and extension. When you hit those limits, your options for further extension or integration between that off-premise solution and any other item are limited. To extend that offering the service consumer either has to tie it to to their existing infrastructure likely through the implementation of an on-premise custom or packaged solution. The challenge with this is how to maintain the benefits your organization received when it made the decision to use a off-premise SaaS offering. If you moved to the cloud to gain scalability, you need to make sure your on-premise extension is equally scalable.

Another factor to consider is that the decision to consume a SaaS solution may have been driven by a simple desire to reduce the capital expenditure of implementation. Your organization may have been incapable (due to resources or costs) of building out the infrastructure to support the solution themselves. Or perhaps they were simply unwilling to given the cost savings of leveraging an off-premise solution. Regardless of the scenario, building an on-premise extension to the SaaS product will likely pose the same challenges.

So the ideal solution is to try and leverage either a private or public cloud. Unless you’re a sufficiently large organization, you likely do not have the capacity to build and manage your own private cloud. So in the vast majority of cases, you will want to look at leveraging a public cloud offering.

Its possible at this point that there may already be another SaaS offering that you can couple with your existing solution to extend it. There are many complimentary solution offerings available and “mash-ups” like this are becoming more and more common. However, if you’re stuck with having to build your solution and you still want to realize the benefits of the cloud that pushed you there in the first place, you need an application development platform that also resides in the cloud. You want a robust PaaS. Microsoft Azure Services could be that platform.

This is where the arguments we’re used to seeing about which platform is best come into play. I’ve already gone there briefly in the past and its not really the point of this posting. So lets skip that for now. I will say that regardless of which PaaS you select, the goal should be to meet the same business needs of your organization that justified the move to the cloud in the first place. That, IMHO, is why an organization that is already consuming a SaaS offering should really consider what PaaS and IaaS have to offer.