Thursday, September 23, 2010

My Windows Azure Wish List – The Future Cloud I Hope to See by 2012

What will cloud computing be like in a couple of years? I got my first look at Windows Azure 2 years ago, and the rate of progress has been nothing short of amazing--and shows no sign of slowing down. What will the cloud be like in another year or two? Where should it go? Here’s where I’d like to see the cloud go over the next couple of years:

1. Auto-Sizing: Out-of-box Governance

Many people don’t seem to be aware that cloud computing brings with it a new management responsibility. A big selling point for the cloud is its elasticity and subsequent cost efficiency—but you only get that if you monitor activity and manage the size of your assets in the cloud. That is not by any means automatic today, so you must elect to do it yourself or through a third-party, either through automated means or human oversight.

We could debate whether this is the cloud provider’s responsibility or the customer’s, and in fact it needs to be a partnership between the two. Since this is something everyone needs to do, however, it seems fair to expect the cloud provider to more than meet us halfway. In the Future Cloud, I’d like to be able to easily set technical or financial thresholds and have the cloud monitor them for me—notifying me about changes and trends and taking action as per my marching orders.

We may get some of these capabilities as cloud integrations become available to operations monitoring software such as System Center—but that’s not a full realization of this idea. The modern start-up may run 100% in the cloud with no on-premise IT. Those companies need a completely in-cloud way to do governance.
Human beings shouldn’t have to babysit the cloud, at least not beyond an oversight/approval level of involvement. It should watch itself for us, and governance should be an out-of-box cloud service.

2. Auto Shut-off: App and Data Lifetime Management

I don’t know about you, but my house probably would have burned down long ago and my electric bills gone through the roof if it were not for the auto shut-off feature of many household appliances such as irons and coffee-makers. You only have to browse the forums to see the daily postings of people who are in shock because they left the faucet running or didn’t realize other so-called hidden costs of the cloud.

It’s human nature to be forgetful, and in the cloud forgetfulness costs you money. Every application put in the cloud starts a run of monthly charges that will continue perpetually until you step in and remove it someday. Every datum put in the cloud is in the same boat: ongoing charges until you remove it. It’s extremely unwise to do either without thinking about the endgame: when will this application need to come out of the cloud? What is the lifetime for this data? You might think you won’t forget about such things, but think about what it will be like when you are using the cloud regularly and have many applications and data stores online.

What we need to solve this problem is lifetime management for assets in the cloud. In the Future Cloud, I’d like to see lifetime policies you can specify up-front when putting applications and data into the cloud—with automated enforcement. You can imagine this including ‘keep it until I delete it’ and ‘keep until [time]’—similar to the options you get on your DVR at home. Auto delete could be dangerous, of course, so we will want more sophisticated options such as an ‘archive’ option, where we take something offline but don’t lose it altogether. Perhaps the best choice we could be given is a lease option, where the app or data’s expiration period gets renewed whenever they are used. This is how auto-shutoff works for many appliances: the shut-off timer gets reset whenever we use them, and only after a certain period of inactivity does deactivation take place.

As with the previous wish list item, this is something everyone needs and is therefore a valid ask of cloud providers. Let us set lifetime policies for our apps and data when we put them in the cloud, and enforce them for us.

3. Mothballing & Auto-Activation: Dehydrate & Rehydrate Apps and Data

As described in the previous wish list item, an ideal implementation of lifetime management for applications and data would include decommissioning and archiving. That is, apps and data that become inactive should be mothballed automatically where they cost us far less than when they are formally deployed.

Along with mothballing comes the need for reactivation. Here I think we can take an idea from workflow technologies such as WF and BizTalk Server, where long-running workflows are dehydrated so that they do not consume finite resources such as threads and memory. They get persisted, and the workflow engine knows what events to look for in order to rehydrate them back into running, active entities.

In the Future Cloud, I’d like apps and data to be dehydrated when inactive and rehydrated when needed again—with greatly reduced costs during the inactive period. We can thus imagine an app that people start to use less and less, and eventually stop using altogether. An example of this might be a health care plan enrollment portal, only used once or twice a year. As the app moves to an inactive state, an expiration policy would cause the cloud to remove all of the server instances. However, the “light would be on”: a future access to the application would bring it back online. We can similarly imagine account data that moves into archive mode when inactive: kept around, but not at the premium rate.

The best realization of this concept would be that mothballed apps and data cost us nothing until they are re-activated. That might be a little unrealistic since the cloud provider is keeping the light on for us, but a mothballed asset should certainly cost a small fraction of an activated one.

4. Automatic Encryption

Most customers go through a period of considering risks and concerns (real or imagined) before they start using the cloud. A common concern that surfaces is the use of shared resources in the cloud and the specter of your critical data somehow falling into the wrong hands. The best way to feel okay about that is to encrypt all data transmitted and stored by your application. That way, if data does fall into the wrong hands—remote as that may be—it won’t be intelligible to them. In the Future Cloud, I’d like all data I store—database and non-database—to be automatically encrypted.

This is another example of something I believe we will all be doing: encryption of data will become a standard practice for all data we put into the cloud. As previously mentioned, whenever there is something everyone wants to do in the cloud it’s fair to ask the cloud provider to provide a service rather than each of us having to separately implement the capability. Naturally, the customer should remain in control of keys and strong encryption methods should be used.

5. Get Closer to True Consumption-based Pricing

Cloud computing has great appeal because of the consumption-based pricing model and the analogies we can make to electricity and other utilities. However, the implementation of that idea today leaves room for improvement. While we do have consumption-based pricing it’s very coarse-grained.

For example, let’s consider Windows Azure hosting. For each VM you allocate, you are reserving that ‘machine’ and are paying $0.12/hour or more for wall clock time. The actual usage of each VM has nothing to do with your charges. Is this really consumption-based pricing? Yes, but at a coarse level of granularity: you add or remove servers to match your load. Can we imagine something more ideal? Yes, charging for the machine hours used to service actual activity. This would work well in combination with an auto-sizing feature as previously discussed.

We can make the same observation about SQL Azure. Today, you buy a database bucket in a certain size, such as 1GB or 10GB or 50GB. Whether that database is full, half full, or even completely empty does not affect the price you pay. Is this really consumption-based pricing? Yes, but again at a very coarse level. We can imagine a future where the amount of database storage in use drives the price, and we don’t have to choose a size bucket at all.

In the Future Cloud, I’d like to see more granular consumption-based pricing that more naturally lines up with usage and activities the way the customer thinks about them. It’s when the pricing model is at a distance from actual activity that surprises and disappointments come in using the cloud. We’ve already sold the ‘metering’ concept: now we need to give the customer the kind of meter they are expecting and can relate to.

6. Public-Private Portability: Doing Things the Same Way On-Prem or in the Cloud

I’m convinced many, many more businesses would be exploring the cloud right now if they could easily move portable workloads between cloud and on-premise effortlessly. Today, the cloud is a bit of a big step that requires you to change some things about your application. The cloud would be far more approachable if instead of that one big step, an enterprise could take several small, reversible steps.

In the Future Cloud, I’d like to be able to host things the same way in the cloud and on-premise so that I can effortlessly shuttle portable workloads between cloud and on-prem. Portable workloads would be huge. It doesn’t seem realistic that existing enterprise apps are going to just work in the cloud unchanged, because they weren’t designed to take advantage of a cloud environment. What does seem realistic is that you can update your apps to work “the cloud way” but be able to host identical VMs locally or in the cloud, giving you the ability to change your workload split anytime. The advent of private cloud will play a big role in making this possible.

7. Hybrid Clouds: Joining My Network to the Cloud

Today, on-premise and in-cloud are two very separate places separated by big walls. IT assets are either “over here” or “over there”, and special activities are needed to move applications, data, or messages between them. This makes certain scenarios a poor fit for the cloud today. Consider what I call the “Molar” pattern: an application with so many internal integrations that its deep roots make it impractical to extract out of the enterprise and move into the cloud.

In the Future Cloud, I’d like to be able to bridge parts of my local network to my assets in the cloud. The picture of what makes sense in the cloud changes radically if we can make connections between the cloud and our local network. That molar pattern, for example, might now be a suitable thing for the cloud because the in-cloud application now has a direct way to get to the internal systems it needs to talk to.

We know this is coming for Windows Azure. “Project Sydney”, announced at PDC 2009, will provide us with a gateway between our local networks and our assets in the cloud. What we can expect from this is that in addition to the “first wave” of applications that make sense in the cloud now, there will be a second wave.

8. Effortless Data Movement

Moving data to and from the cloud is not particularly hard—if it’s small, and of the type where you have a convenient tool at hand. When working with large amounts of data, your options are reduced and you may find yourself doing a lot of manual work or even creating your own tools out of necessity.

It’s not just moving data into the cloud and out that’s at issue: you may want to copy or move data between projects in the data center; or you may want to copy or move data to a different data center. In the Future Cloud, I’d like to be able to easily move data between on-premise and cloud data centers around the world, regardless of the amount of data.

9. A Simpler Pricing Model

If you look at Azure ROI Calculators and TCO tools, you’ll see that there are many dimensions to the pricing model. As we continue to get more and more services in the cloud, they will only increase. Although there’s something to be said for the transparency of separately accounting for bandwidth, storage, etc. it certainly puts a burden on customers to estimate their costs correctly. It’s very easy to get the wrong idea about costs by overlooking even one dimension of the pricing model. In the Future Cloud, I’d like to see a simpler, more approachable pricing model. This might mean a less itemized version of the pricing model where you consume at a simple rate; with the ability to reduce your costs slightly if you are willing to go the itemized route. This would be similar to tax returns, where you can choose between easy and itemized forms.

10. Provide SaaS Services

Software-as-a-Service providers are ISVs who face a common set of challenges: they need to provide multi-tenancy and engineer their solutions in a way that protect tenants well. This includes protection and isolation of data, and may involve customer-controlled encryption keys. SaaS providers also have to deal with provisioning of new accounts, which they would like to be as automated as possible. Change management is another consideration, where there is a tension between the ability to provide customizations and the use of a common deployment to serve all customers.

In the Future Cloud, I’d like to see services and a framework for SaaS functionality. Microsoft themselves are solving this for SaaS offerings such as SharePoint Online and CRM Online. Why not offer provisioning, multi-tenancy, and data isolation services for SaaS ISVs as a general cloud service?

11. E-Commerce Services in the Cloud

In line with the BizSpark program and other Microsoft initiatives to support emerging business, e-commerce services in the cloud would be highly useful. A cloud-based shopping cart and payment service would an excellent beginning, best implemented perhaps in conjunction with a well-known payment service such as PayPal. For more established businesses, we could imagine a deeper set of services that might include common ERP and commerce engine features. In the Future Cloud, I’d like to see shopping, payment, and commerce services.

12. Basic IT Services in the Cloud

It may be unrealistic to expect enterprises will put everything they have in the cloud, but start-ups are another matter altogether. For many start-ups, all of their IT will be in the cloud. They won’t have any local IT assets whatsoever beyond laptops. That means the basics, such as email, conferencing, Active Directory, domain management, and backup/restore will need to be in the cloud. We have a start on that today with Exchange Online, Office Communications Online, and Live Meeting in BPOS, but more is needed to complete the picture. In the Future Cloud, I’d like to see basic IT services provided by the cloud to support the fully-in-the-cloud customer.

Well, there’s my wish list. What do you think needs to be in the future cloud? Send me your comments.

Friday, September 17, 2010

Stupid Cloud Tricks #1: Hosting a Web Site Completely from Windows Azure Storage

Can you host a web site in Windows Azure without using Windows Azure Compute? Sure you can: you can ‘host’ an entire web site in Windows Azure Storage, 100% of it, if the web site is static. I myself am currently running several web sites using this approach. Whether this is a good idea is a separate discussion. Welcome to “Stupid Cloud Tricks” #1. Articles in this series will share interesting things you can do with the Windows Azure cloud that may be non-obvious and whose value may range from “stupid” to “insightful” depending on the context in which you use them.

If you host a web site in Windows Azure the standard way, you’re making use of Compute Services to host a web role that runs on a server farm of VM instances. It’s not uncommon in this scenario to also make use of Windows Azure blob storage to hold your web site assets such as images or videos. The reason you’re able to do this is that blob storage containers can be marked public or private, and public blobs are accessible as Internet URLs. You can thus have HTML <IMG> tags or Silverlight <Image> tags in your application that reference images in blob storage by specifying their public URLs.

Let’s imagine we put all of the files making up a web site in blob storage, not just media files. The fact that Windows Azure Storage is able to serve up blob content means there is inherent web serving in Windows Azure Storage. And this in turn means you can put your entire web site there—if it’s of the right kind: static or generated web sites that serve up content but don’t require server-side logic. You can however make use of browser-side logic using JavaScript or Ajax or Silverlight.

How does ‘hosting’ a static web site out of Windows Azure Storage compare to hosting it through Windows Azure Compute?
  • With the standard Windows Azure Compute approach, a single VM of the smallest variety @$0.12/hr will cost you about $88/month--and you need at least 2 servers if you want the 3 9's SLA. In addition you’ll pay storage fees for the media files you keep in Windows Azure storage as well as bandwidth fees.
  • If you put your entire site in Windows Azure storage, you avoid the Compute Services charge altogether but you will now have more storage to pay for. As a reminder, storage charges include a charge for the amount of storage @$0.15/GB/month as well as a transaction fee of $0.01 per 10,000 transactions. Bandwidth charges also apply but should be the same in either scenario.
So which costs more? It depends on the size of your web site files. In the Compute Services scenario the biggest chunk of your bill is likely the hosting charges which are a fixed cost. In the storage-hosted scenario you’re converting this aspect of your bill to a charge for storage which is not fixed: it’s based on how much storage you are using. It’s thus possible for your 'Storage-hosted’ web site charges to be higher or lower than the Compute-hosted approach depending on the size of the site. In most cases the storage scenario is going to be less than the Compute Services scenario.

As noted, this is only useful for a limited set of scenarios. It’s not clear what this technique might cost you in terms of SLA or Denial of Service protection for example. Still, it’s interesting to consider the possibilities given that Windows Azure Storage is inherently a web server. The reverse is also true, Windows Azure Compute inherently comes with storage--but that’s another article.