10 Years In The Cloud: A Retrospective

I am celebrating 10 years of cloud computing work. This post looks back on a decade of cloud activity and where it has led.

2008-2009: Cloud Computing, the New Thing 

In late 2008, working at Microsoft Partner Neudesic, our CTO Tim Marshall and I were invited to a Microsoft feedback session in Redmond about "Project Red Dog". Red Dog, it turns out, was about this new thing called Cloud Computing. Amazon had been doing this for a few years, and Microsoft was going to also enter the market. This "cloud computing" was a new idea and a new way of doing things—but it sounded exciting. A few months later, "Windows Azure" was released. As Neudesic is a consulting company, we started learning it and looking for early prospects.

When Microsoft introduces a new product or service, a lot of work goes into evangelism and education and finding early adopters. As a Microsoft partner, we did a lot of joint work with Microsoft: visits to prospects, proof-of-concept projects, training sessions, code camps.

Tim had his own ideas about developing the market, and one of those was starting Azure user groups in the ten or so locations we had across the United States. I and other colleagues (including Mickey Williams and Chris Rolon) started sponsoring monthly meetings, sometimes held at Microsoft field locations. Since this was all new, meeting attendance could just as easily be 5 or 20 or 50 people, depending. But we kept at it, and we got the word out there, and interest started growing. At meetings we would cover new cloud services that had just become available, or show off things we had built, or discussed useful patterns for applications. It was fun, and there was pizza.

We learned things about the cloud: the infrastructure was really advanced, but the individual hardware components could fail: you had to plan for redundancy and recovery. The economics of the cloud were different: you had to consider lifetime of the data and resources you allocated, else you would "leave the faucet running". Almost everyone who was an early adopter had an Unexpectedly Large Cloud Bill story. Developers giggled with pleasure at the ease of self-deployment; but sometimes you'd hear a horror tale where someone lost important data all because they weren't careful enough when clicking in the management portal. We started reinforcing the importance of separating Production accounts from Development accounts.

2010-2014 : Azure Evangelism and Early Adopters

As Windows Azure was evangelized, prospects started to line up. I participated in a great deal of proof-of-concept project work, sometimes arranged by and paid for by Microsoft. One that stands out was going to Coca Cola headquarters in Atlanta to show how readily existing web sites could be migrated to Windows Azure. The first web site we migrated was in ASP.NET/SQL Server, which was a slam-dunk and just took a handful of days. The second site used Java Server Pages and Oracle—definitely not in my wheelhouse—but in two weeks' time we had migrated it as well.

I wrote The Windows Azure Handbook in 2010, which I believe was the first book out for Azure. The book contained Microsoft messaging from the time: Platform-as-a-Service (PaaS) is better than Infrastructure-as-a-Service (IaaS) and so on. Today Azure is equally well-suited for PaaS and IaaS and the message has changed. We've learned that there are those who value the cloud for innovative new ways of doing things (the PaaS people); but also those who value the ability to leverage existing skills and don't want their world rocked (the IaaS people).

I also released through Neudesic an Azure ROI calculator, long before there was a comprehensive one available from Microsoft. You can see from this screenshot how few cloud services there were in those early years. The number of cloud services available today is vast and ever-expanding.

There were real cloud projects happening too by this time. At first, there had been a lot of interest but prospects seemed hesitant to actually take the plunge. There was for example a great fear of vendor lock-in. Eventually, and with increasing rapidity, adoption started happening. The vast majority of these projects were web site & database migration for established companies; but start-ups had a different mentality, they wanted to do everything in the cloud from Day L.

As head of the Custom App Dev practice at Neudesic, I made sure we had Azure-trained consultants in every region. As new cloud services appeared, this interested our other practices. SQL Azure database and (later on) Power BI interested the SQL / Business Intelligence practice. Service Bus interested the Connected Systems practice.

Badges Awarded to Consulants Who Completed Cloud Training

Microsoft started a Windows Azure category of their Most Valuable Professional program, and I was honored to be a Microsoft MVP from 2010-2014. I met some great MVPs on my visits to Microsoft (and hired one, Michael Collier), along with the Windows Azure product team.

Although activity was intense, Windows Azure wasn't perfect. For three years in a row, Azure went down during the annual MVP summit, usually for reasons like somone having forgotten to renew a security certificate. We MVPs were initially amused, but in later years it meant customers were affected. AWS also seemed to have a hiccup as well once or twice a year. We started educating customers about what dependency on a cloud platform meant for reliability, and fallback plans for when the a region or entire platform was unavailable. Both platforms have improved in reliability since then.

In 2011 Microsoft asked me to teach Azure training sessions in Amsterdam and Germany. This was a fun trip—except for the blistering winter snowstorm—and I met some MVPs including Kris van der Mast and Christian Weyer. This helped me realize that cloud computing was a worldwide phenomenon, and also that different regions had different problems to address: in Europe, for example, there were laws about where clients' data had to be stored, and that didn't always align well with existing data centers.

My Azure class in Munich, Germany

As the years went by, Azure added more and more services and would occasionally drop support for a service (never popular). New data centers were continually added around the world.

Azure Storage Explorer

I created a free storage tool named Azure Storage Explorer and placed it on CodePlex, which turned out to be a hit. Over the next few years, Azure Storage Explorer had over 280,000 downloads! I would do a handful of updates a year to ASE, usually because Microsoft had added a new feature or because the Storage API had changed.

Eventually, there was one breaking API change too many and I stopped maintaining it--but made the source available on CodePlex. A second reason for not working on it is simply how busy I was on cloud projects.

A few years later, Microsoft finally came out with their own tool, with nearly the same name: Microsoft Azure Storage Explorer. You can also now manage storage through the Azure Portal. It's about time!

Recently I've had some thoughts about creating some new, updated cloud tools. See the end of this post for more.

2015-2019: The Maturing Cloud Becomes Essential

Cloud has exploded and is no longer something reserved for brazen early adopters or just a few specialists. At Neudesic, we consult widely on multiple cloud platforms: Microsoft Azure, Amazon Web Services, and now Google Cloud Platform.

New cloud services continue to arrive. There are services for Mobile and APIs and Non-Relational Databases and Distributed Memory Cache and Machine Learning. We now have Serverless Computing (AWS Lambda or Azure Functions), where you don't even have to allocate a server: just upload your function code and the platform takes it from there.

Names were changed. Windows Azure became Microsoft Azure, so the branding wouldn't be focused on one operating system. SQL Azure became SQL Database. Azure Web Sites became Azure App Services. Even Visual Studio Team Services / TFS Online was rebranded as Azure DevOps.

Software-as-a-Service (SaaS)

About 4 years ago I joined a product team to work on creating a Software-as-a-Service offering out of a legacy HR product named HRadvocate. It was a major amount of work to update the architecture and user interface, but eventually we had something deployed to Windows Azure with a reliable SaaS architecture that kept clients' data isolated from each other in separate databases.

SaaS Architecture on Azure

Authentication was initially through Azure Active Directory, with the idea that enterpises could use Microsoft's ADConnect to link their enterprise AD to AAD. It turned out that clients were demanding Active Directory Federation Services (ADFS) integration, so we added support for that. Later we added SAML support so products like PingFederate can be used to authenticate. Now our SaaS product could authenticate each client differently.

An Azure customer required a hybrid architecture, where Azure-hosted HRadvocate needed to integrate with multiple other systems--all of which were local to the enterprise. These systems connected to the former HR system via database integration, a structure that had to be maintained. To fit into this arrangement, I developed SQL Connector, a set of SQL Server functions written in C# that allow enterprise databases to query data in the cloud. This allowed the cloud data to be synced locally. Now, the local systems could continue to use their existing database integration, even though our SaaS was now part of the mix.

Amazon Web Services

I'd obviously been very focused on Microsoft Azure up until now, but that was about to change. Client requirements for HRadvocate led to a decision that we had to be able to run on Amazon Web Services as well as Azure. This led to several years of work on AWS and I am now proficient in it. Getting our solution to work on both Azure and AWS—while keeping a common source code base—was a lot of work but was also very educational. Azure's Cloud Service, SQL Database, Blob Storage, and Redis Cache mapped in a straightforward way to AWS's Elastic Beanstalk/EC2, RDS SQL Server, S3, and ElastiCache. About the only thing we couldn't transition was Azure Active Directory, but that's fine since we offer multiple ways of authentication.

SaaS Architecture on AWS

We also targeted Amazon's Commercial Cloud Services (C2S). To support this we added to the product the ability to run air-gapped (without Internet); this required locating and replacing any code (including from open source libraries) that was taking availability of the web for granted. Chart libraries like Google Charts had to replaced with Highcharts which could be local to the application. We added support for the FIPS 140-2 standard, using only algorithms and code for encryption that been certified to be compliant.

During this time, we continued supporting our product on Azure as well. Being able to run on two cloud platforms provided a lot of insight about what is the same and what is different between leading cloud platforms. There certainly seems to be a lot of copying going on between mainstream cloud platforms: when one provider comes out with a useful cloud service, it's not long before the competition has a very similar service. For example, Amazon has AWS Lambda for serverless-computing while Azure has Azure Functions. For those still worried about vendor lock-in, this keeping-up-with-the-Joneses activity should be comforting. The principles for building a good solution in the cloud transcend any one platform.

The Cloud in 2019

Ten years have gone by, and Cloud has certainly come into the mainstream. Just about all of us now use cloud computing every day, whether we realize it or not. Doing a web search? Streaming a movie? Using a social network? Making an online purchase? Cloud computing is an integral part of that.

Ten years ago, some big tech companies had cloud infrastructure but no one was providing cloud computing services to the public except Amazon. Now, there are clouds by Microsoft, Google, IBM, Oracle, SalesForce, SAP, VMWare, ...the list goes on and on. As for Microsoft, Azure is now also a leading cloud platform: it does PaaS and IaaS; half its VMs are reportedly running Linux; and there are a whopping 54 data centers worldwide. The growth has been phenomenal.

Cloud computing is no longer considered a speculative idea or a novelty for organizations: now, it's a common assumption that you'll be leveraging a cloud in anything new you develop. Ten years ago there was a lot of indecision about whether to go cloud or not; today, going to the cloud is a given, and the discussion is about which platform and which services to use. It's no longer a discussion of IaaS vs. PaaS; the debate now is about whether to leverage the newer cloud native architectures, NoSQL databases, serverless functions, and microservices vs. more traditional architectures. Serverless in particular is a major phenomenon that has opened cloud development to a broader number of people.

Some of my Neudesic colleagues from the early days have gone on to work at Microsoft or Amazon.

Cloud platforms seem to have improved uptime from 10 years ago, but there are still those moments when something goes wrong and a substantial number of clients are affected. You can still be in for a long wait when a cloud platform is recovering from an issue and each customer account has to be restored.

It's been a really interesting decade of cloud work, and there is plenty more to come. The do-it-yourself nature of the cloud is inherently satisfying, as is being able to change your mind and alter your deployment as will. Services that handle the details and let you focus on your application are a joy to use. You still need to know what you're doing architecturally and keep the cloud's different economic model in mind, but things like auto-scale and recovery are increasingly included in new cloud services. New services like Machine Learning are opening up new vistas for developers, and there's never been a more fun time to experiment—for just pennies.

Presentation: The Modern Web, Part 4: Cloud Computing

Here's the presentation from Part 4 of our Modern Web webcast series, which discusses the importance of Cloud Computing in modern web solutions. You can find the recordings of our webcasts at neudesic.com.

The Modern Web, Part 1: Mobility
The Modern Web, Part 2: HTML5
The Modern Web, Part 3: Social Networking
The Modern Web, Part 4: Cloud Computing

The Modern Web Part 4: Cloud Computing

View more presentations from David Pallmann.

Picking a Lane in Cloud Computing

Because cloud computing is big and varied, there are lots of ways to apply it—which requires you to ultimately make some important decisions. In this post we’ll explore what some of those decisions are, first with cloud computing generally, then specifically with the Windows Azure platform. This is an excerpt from my upcoming book, The Azure Handbook.

Choice is good, right? Yes and no: it’s good to have options but it also raises the specter that a wrong choice will take you to some place you don’t want to go. You might even be unaware that you have a choice in some area or that a decision needs to be made. While there’s some value in experimenting, you eventually need to make some rather binding decisions. Failure to get those decisions right early on could cost you wasted time, effort, and expense.

SaaS, IaaS or PaaS?

The first choice to make is the one that’s most talked about (talked about to death, perhaps): whether you’re going to run Software-as-a-Service, Platform-as-a-Service, or Infrastructure-as-a-Service. What’s at issue here is the level at which you use cloud computing.

SaaS: Someone else’s software in the cloud. If you’re simply going to use someone else’s cloud-hosted application (such as Salesforce.com or Microsoft Exchange in the cloud), decision made: you’ll be using SaaS. If that’s you, read no further. The rest of this article is for those who want to run their own software applications in the cloud (to be sure, your SaaS software provider is using IaaS or PaaS themselves but that’s their worry, not yours.)

PaaS: Your Cloud Applications. This means running applications in the cloud that conform to your cloud provider’s platform model. In other words, they do things the cloud’s way (which is often different from in the enterprise). There are many benefits to running at this level, among them superb scale, availability, elasticity, and management. There’s a spectrum here that ranges from minimal conformance all the way to applications designed from the ground up to strongly leverage the cloud.

IaaS: Traditional Applications in the Cloud. This means running traditional applications in the cloud. Not all applications can run in the cloud, and you’re not leveraging the cloud very strongly by running at this level. If your application and data aren’t protected with redundancy there are some real dangers you could lose availability or data (in PaaS, the platform has these protections built into its services). IaaS appeals to some people because it’s more similar to traditional hosting and thus somewhat more familiar, or because they prefer to take control themselves.

Not sure which way to go? For running your own applications in the cloud, PaaS is the best choice for nearly everybody.

Public, Private, or Hybrid Cloud?

Public Cloud: Full Cloud Computing. Cloud computing in its fullest sense is provided by large technology providers such as Amazon, Google, and Microsoft who have both the infrastructure and the experience to support large communities well with dynamic scale and high reliability. We call this “public cloud”. When you use public cloud, you get the most benefits: no up-front costs, consumption-based pricing, capacity on tap, high availability, elasticity, and no requirement to make commitments.

Private Cloud: Under Your Control. And then there’s private cloud, not quite as firmly defined yet but very much on everyone's mind. Ever since cloud computing became a category there’s been ongoing demand in the market for “private clouds”. There’s more than one interpretation of just what this means or how it can be delivered; the general idea is to benefit from the cloud computing way of doing things but with a strong degree of privacy and direct control as compared to public clouds, where you are in a shared environment. Here are some of the ways private cloud is interpreted:

1) Hardware private cloud: a local cloud computing hardware appliance for your data center.
2) Software private cloud: a software emulation you run locally.
3) Dedicated private cloud: leasing a dedicated area of a cloud computing data center not shared with other tenants.
4) Network private cloud: ability to exercise network control over assets in the cloud such as joining them to your domain and making them subject to your policies. This last idea more properly belongs in our next category, Hybrid Cloud.

Hybrid Cloud. If you’re making use of public cloud, it often makes sense to connect your cloud and on-premise assets. Using VPN technology some cloud platforms allow you to link your virtual machines running in the cloud with local on-premise machines. You might do this for example if you had a cloud-hosted web site that needed to talk to an on-premise database server. If you want to be on more intimate terms, your cloud assets can become members of your domain.

In the Windows Azure platform, all 3 forms of cloud are available: public cloud, hardware private cloud, and hybrid cloud.

Not sure what you need? Public cloud is the best starting point for most organizations, it doesn’t commit you. Whether and when you look into private cloud or hybrid cloud is something best decided once you’ve tested the public cloud waters.

Which Cloud Computing Platform to use?

If you’ve decided to go with PaaS or IaaS, you need to choose a vendor and platform. The big players are Amazon, Microsoft, and Google.

Amazon Web Services offers an extensive set of cloud services. I think of them as mostly focused on IaaS but they also provide a growing set of PaaS services.

Microsoft’s Windows Azure Platform also offers an extensive set of cloud services. Windows Azure is very focused on PaaS but also offers some IaaS capability. One distinguishing feature of Windows Azure is the symmetry Microsoft offers between its enterprise technology stack and its cloud services.

Google provides some interesting cloud services such as AppEngine that are very automatic in how they scale, but they limit you to a smaller set of languages and application scenarios.

Here’s a comparison I recently put together on the services offered by these vendors. Keep in mind, the platforms advance rapidly and I’m only an authority on Windows Azure; so you should definitely research this decision carefully and make sure you’re using up-to-date information.



Not sure where to go? Figure out what's important to you and compare. I have my favorite, and it's Windows Azure.

Services: Hosted Compute vs. Consuming Services

Even after selecting a cloud computing platform and provider you have plenty of decisions left to make! Cloud computing providers provide oodles of services such as those listed in the previous section. Which ones will you use and for what purpose? Not everyone uses the cloud in the same way. Some organizations run public web sites, customer applications, or internal departmental applications in the cloud. Some use the cloud for data archiving, backup, or disaster recovery. Some use the cloud for overflow to back up their primary data center. Some use the cloud to federate security or communication across multiple organizations. Some start-ups and newer companies put all their IT in the cloud.

We can divide the services you might use from a cloud computing provider into 2 big categories: Hosted Compute and Everything Else.

Consuming Services: Using the Cloud from a Distance. Most cloud services are consumed: that is, your programs (wherever they reside) access them by making Internet calls. Cloud services for storage, database, security, and communication work this way. Since just about any platform can issue web calls, you’re free to make use of cloud services from any operating system and any category of software application (including desktop and mobile applications).

Hosted Compute: Running your Application in the Cloud. Then there’s Hosted Compute, where your software actually runs within the cloud computing data center. That’s different, because you live there and have to conform to the requirements of the environment.

It’s not that you have to pick one category over the other: most likely you’ll be using a combination of services. However, be aware that with Hosted Compute you’re using cloud computing at a much more intimate level and it puts more constraints on the design of your application.

Design to Minimize or Maximize Use of the Cloud?

You have some choice about how strongly your applications are designed for the cloud platform. There are various reasons why you might favor doing as little as possible or as much as possible in this area.

Driver: Expense. If you are migrating an existing application to the cloud and are sensitive to development costs you might choose to change as little as possible. You can change your application just enough to achieve minimal conformance to the cloud platform.

Driver: Portability. If you have concerns about being locked into a platform, you might choose to stress portability and write your software in such a way that it can run in the enterprise or in the cloud. This means limiting yourself to the “common ground” features that are the same between the enterprise and the cloud.

Driver: Feature Need. There may be a specific feature in the cloud that you need and can’t find elsewhere, such as a federated security service. In this scenario you might change your application design to accommodate this one feature need.

Driver: Commitment. You may have committed to cloud computing as a style of computing you want to embrace for strategic or cultural reasons. Here you will want to do everything the cloud way, including designing your applications to strongly leverage cloud services.

Identity: Internet, Domain, or Custom?

When your applications run in the enterprise, the default identity model may be obvious such as securing employee applications to your domain. When you put an application in the cloud, you have to decide which security model you want to use for identity. You have many choices in identity these days.

Internet Identities. Many people today have one or more Internet identities such as Facebook, Google, Yahoo, Windows Live, or Open ID.

Domain Identities. Even if your application is in the cloud you can still secure it to your domain. There are multiple approaches for this. One is to establish a hybrid cloud virtual network connection to your domain controller. Another is putting a federated identity server in your enterprises DMZ such as ADFS.

Custom Identities. You could maintain a custom membership database. However, consider that by supporting an existing identity scheme you eliminate the need for someone to create and remember yet another identity for your application.

Federated Identity. Federated identity allows you to support multiple identities simultaneously and to add new ones over time. Windows Azure provides the AppFabric Access Control Service for federated identity. Your program only needs to talk security one way and the service takes care of communicating with multiple identity providers.

The best way to handle security today is to use claims-based security and to decouple security implementation from your code. In the Windows Azure platform, technologies used in this area include Windows Identity Foundation, ADFS, and the Access Control Service.

Data Storage: Relational or Cheap?

In the enterprise, the king of storage is the relational database, augmented by other types of storage such as queues and file servers. In the cloud, you also have these facilities but the dynamics and costs are such that you may want to change out the equation. For example, in the Windows Azure Platform relational database capability is 66 times more expensive than basic table storage. If your data needs are not sophisticated, table storage may make sense.

Relational Database. A cloud-based relational database is going to give you the rich features you are used to having, which will make development or migration easier. But you may have size or scalability limits or it may be more expensive than other options.

Table Storage. Some cloud platforms offer cheap, big table storage at a fraction of the cost of a relational database and without its limits. In exchange for the lessened cost developers must do a lot more work themselves and live without advanced features like stored procedures, SQL, joins and user security. Not all developers are cut out for this.

Not sure where to go? Come up with a simple data task and have it implemented both ways, then compare notes.

Master Data Management: Here or There?

Great, you’ve got your application and data running in the cloud—but where is the master system of record for your data, in the cloud or back in the enterprise?

Master Data in the Cloud. If your data’s master copy will be in the cloud, you need to ensure you are using a trustworthy means of storage that will protect your data. For example, in Windows Azure there is the Windows Azure Storage Service and the SQL Azure Database service, both of which protect your data through redundancy.

Master Data on Premise. If the master copy of data is on-premise, you need to think about how your cloud applications get to it: do they access it directly (through a web service or VPN connection) or do they have their own copy of the data in the cloud? If the latter, then some sort of synchronization is going to be necessary, either ongoing or periodic. Your cloud platform may provide synchronization services or you may need to adapt or create tools, scripts, or programs for this purpose.

Service Access: REST or Platform Libraries?

Now you’re consuming cloud services, which most often use the REST protocol for access; this means your applications issue web requests to use the service. In addition to the usual development platform choices you have about language and tools, your platform may let you choose between REST web calls vs. using a provided library. For example, in Windows Azure Storage you can access the service with REST or a .NET storage library.

REST Interface. Using REST is very popular today, and has the benefit that just about any operating system and development platform can be used since the only requirement is the ability to make web calls. However, REST also requires you to work at the web I/O level, where you need to implement creating web requests, encoding and encrypting data, interpreting web responses, handling errors and performing retries. It can be quite a bit of work.

Platform Library. A platform library in contrast is easy to work with, and if one is available for your favorite development environment and language (such as C#/.NET and Visual Studio, or Java and Eclipse) you may find a radical improvement in productivity using this approach. It may provide built-in error handling and retry logic. However, this approach does limit you to a particular platform and you are trusting the library (usually a wrapper around a native REST interface) that you may not have source code to.

Here’s an example of the difference. A call to Windows Azure Storage service to store data looks like this, and you can use REST or a .NET library to generate it.

PUT http://myproject.blob.core.windows.net/mycontainer/myblob HTTP/1.1

Request Headers:
x-ms-version: 2010-09-19
x-ms-date: Sun, 2 Jan 2011 22:00:35 GMT
Content-Type: text/plain; charset=UTF-8
x-ms-blob-type: BlockBlob
x-ms-meta-m1: v1
x-ms-meta-m2: v2
Authorization: SharedKey myaccount: 4rvSHg2S6LhRuGn713bqFXRM3E08QDGbPWOhOdWO2V+DoLhbmvc2rSwIO/wwMqzxlZUh0C+Wwy0LoDj1da4wQB==
Content-Length: 13

Request Body:
Hello, Cloud!

If you used your own code to generate this REST request in C#, it would look something like this (not shown: additional code to sign and send the request):

// Create or update a blob.
// Return true on success, false if not found, throw exception on error.

public bool PutBlob(string container, string blob, string content)
{
    HttpWebResponse response;

    try
    {
        SortedList headers = new SortedList();
        headers.Add("x-ms-blob-type", "BlockBlob");

        response = CreateRESTRequest("PUT", container + "/" + blob, content, headers)
            .GetResponse() as HttpWebResponse;
        response.Close();
        return true;
    }
    catch (WebException ex)
    {
        if (ex.Status == WebExceptionStatus.ProtocolError &&
            ex.Response != null &&
            (int)(ex.Response as HttpWebResponse).StatusCode == 409)
            return false;

        throw;
    }
}

For comparison, here’s how this is done using the .NET StorageClient library, also using C# code:

// Put (create or update) a blob.
// Return true on success, false if unable to create, throw exception on error.

public bool PutBlob(string containerName, string blobName, string content)
{
    try
    {
        CloudBlobContainer container = BlobClient.GetContainerReference(containerName);
        CloudBlob blob = container.GetBlobReference(blobName);
        blob.UploadText(content);
        return true;
    }
    catch (StorageClientException ex)
    {
        if ((int)ex.StatusCode == 404)
        {
            return false;
        }

        throw;
    }
}

Not sure which way to go? Your developers likely have strong opinions--or will after a little bit of experimentation.

Closing Thoughts

Well, there you have it. These are some of the decisions you’ll need to make on your journey into cloud computing. For some of these decisions the right way to go for your organization may be obvious. When it isn’t, do some experimentation and read up on the experiences of others.

A good way to be sure you’re making the right decisions is to get help from a knowledgeable consulting company who knows what to look for and the right questions to ask. At Neudesic we’ve teamed up with Microsoft to provide free cloud computing assessments. And of course this is yet another decision.☺

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.

Threat Modeling the Cloud

If there’s one issue in cloud computing you have to revisit regularly, it’s security. Security concerns, real or imagined, must be squarely addressed in order to convince an organization to use cloud computing. One highly useful technique for analyzing security issues and designing defenses is threat modeling, a security analysis technique long used at Microsoft. Threat modeling is useful in any software context, but is particularly valuable in cloud computing due to the widespread preoccupation with security. It’s also useful because technical and non-technical people alike can follow the diagrams easily. Michael Howard provides a very good walk-through of threat modeling here. At some level this modeling is useful for general cloud scenarios, but as you start to get specific you will need to have your cloud platform in view, which in my case is Windows Azure.

To illustrate how threat modeling works in a cloud computing context, let’s address a specific threat. A common concern is that the use of shared resources in the cloud might compromise the security of your data by allowing it to fall into the wrong hands—what we call Data Isolation Failure. A data isolation failure is one of the primary risks organizations considering cloud computing worry about.

To create our threat model, we’ll start with the end result we’re trying to avoid: data in the wrong hands.


Next we need to think about what can lead to this end result that we don’t want. How could data of yours in the cloud end up in the wrong hands? It seems this could happen deliberately or by accident. We can draw two nodes, one for deliberate compromise and one for accidental compromise; we number the nodes so that we can reference them in discussions. Either one of these conditions is sufficient to cause data to be in the wrong hands, so this is an OR condition. We’ll see later on how to show an AND condition.

Let’s identify the causes of accidental data compromise (1.1). One would be human failure to set the proper restrictions in the first place: for example, leaving a commonly used or easily-guessed database password in place. Another might be a failure on the part of the cloud infrastructure to enforce security properly. Yet another cause might be hardware failure, where a failed drive is taken out of the data center for repair. These and other causes are added to the tree, which now looks like this:


We can now do the same for the deliberately compromised branch (1.2). Some causes include an inside job, which could happen within your business but could also happen at the cloud provider. Another deliberate compromise would be a hacker observing data in transmission. These and other causes could be developed further, but we’ll stop here for now.


If we consider these causes sufficiently developed, we can explore mitigations to the root causes, the bottom leaves of the tree. These mitigations are shown in circles in the diagram below (no mitigation is shown for the “data in transmission observed” node because it needs to be developed further). For cloud threat modeling I like to color code my mitigations to show the responsible party: green for the business, yellow for the cloud provider, red for a third party.


You should not start to identify mitigations until your threat tree is fully developed, or you’ll go down rabbit trails thinking about mitigations rather than threats. Stay focused on the threats. I have deliberately violated this rule just now in order to show why it’s important. At the start of this article we identified the threat we were trying to model as “data in the wrong hands”. That was an insufficiently described threat, and we left out an important consideration: is the data intelligible to the party that obtains it? While we don’t want data falling into the wrong hands under any circumstances, we certainly feel better off if the data is unintelligible to the recipient. The threat tree we have just developed, then, is really a subtree of a threat we can state more completely as: Other parties obtain intelligible data in cloud. The top of our tree now looks like this, with 2 conditions that must both be true. The arc connecting the branches indicates an AND relationship.


The addition of this second condition is crucial, for two reasons. First, failing to consider all of the aspects in a threat model may give you a false sense of security when you haven’t examined all of the angles. More importantly, though, this second condition is something we can easily do something about by having our application encrypt the data it stores and transmits. In contrast we didn't have direct control over all of the first branch's mitigations. Let’s develop the data intelligible side of the tree a bit more. For brevity reasons we’ll just go to one more level, then stop and add mitigations.

Mitigation is much easier in this subtree because data encryption is in the control of the business. The business merely needs to decide to encrypt, do it well, and protect and rotate its keys. Whenever you can directly mitigate rather than depending on another party to do the right thing you’re in a much better position. The full tree that we've developed so far now looks like this.


Since the data intelligible and data in the wrong hands conditions must both be true for this threat to be material, mitigating just one of the branches mitigates the entire threat. That doesn’t mean you should ignore the other branch, but it does mean one of the branches is likely superior in terms of your ability to defend against it. This may enable you to identify a branch and its mitigation(s) as the critical mitigation path to focus on.

While this example is not completely developed I hope it illustrates the spirit of the technique and you can find plenty of reference materials for threat modeling on MSDN. Cloud security will continue to be a hot topic, and the best way to make some headway is to get specific about concerns and defenses. Threat modeling is a good way to do exactly that.

Should IT Fear the Cloud or Embrace It?

Cloud computing’s arrival on the scene certainly can’t be ignored, especially given the boost it has received from the recent economic climate. The cloud has a compelling business story that appeals to business owners and a compelling technology story that appears to developers. But then we have IT, charged with enabling the business with technology while simultaneously protecting and managing the use of that technology. How should IT feel about the cloud?

There are more than a few reasons why an IT department’s initial reaction to cloud computing could be less than enthusiastic. First off, it’s something new and therefore to be viewed with suspicion. Taking programs and data off-site and having less direct control over them also raises a red flag. And then there’s the self-service aspect of cloud computing, where any department or individual in the company can do what they want without going through channels. Security becomes a huge concern: might someone put sensitive data in the cloud on their own and not secure it properly? Last but not least, if your business takes cloud computing seriously might that not lead to a reduction in IT staffing?

While all of these are valid concerns, they are addressable. More importantly, they miss the key point about cloud computing, which is that it’s coming upon all of us whether or not everyone likes it. We’re already hearing stories where some individual in a company became a hero by taking matters into their own hands through cloud computing and a credit card and saved the day. This isn’t the first time new technology has caused control and security concerns in the enterprise: when wireless PDAs starting showing up within the business walls, many IT departments were nervous about the potential security concern they represented and weren’t sure how to deal with them at first. Similarly, self-service computing in the cloud is now a reality that anyone in your organization might be tempted to take advantage of. You can embrace cloud computing or you can fight it, but you certainly cannot afford to ignore it.

The right thing for IT departments and CIOs to do about cloud computing is to lead the way in their company’s use of it, a far better alternative to letting it happen all around them, uncontrolled and uncoordinated. IT should be championing the business benefits of cloud computing to executive management, putting company-wide policies in place about when and where cloud computing is appropriate, and coordinating its use across the company. It’s in this IT-supportive context that cloud computing can best deliver its benefits without risking unintended consequences.

Cloud computing brings with it the democratization of IT, where common tasks such as installing software, configuring a server, or deploying applications become routine and easy enough that anybody can do it. Smart IT departments will not see this as a threat to their jobs, but rather an opportunity to operate at a higher level. Freed from many mundane tasks, IT personnel can take things up a notch and focus on the strategic use of technology in their organization, which is in fact their mission.

Channel 9 video - Impact of Cloud Computing

There's a new Channel 9 video out on ARCast.tv where Mickey Williams and I are talking about the impact of Azure Cloud Computing on developers.

ARCast.TV - Mickey Williams and David Pallmann of Neudesic on the Impact of Cloud Computing

Is Cloud Computing Just Hosting?

I recently had a chance to chat with some I.T. people who had been noticing all this cloud computing buzz but didn't see what all the excitement was. Cloud computing seemed like a new word for an old thing: hosting. They knew all about hosting and had been using it for years.

Is cloud computing just hosting, re-branded? The answer is no. And yes. Really, it's hosting++. Let's dig in and see how cloud computing is like and unlike hosting.

• Automatic Provisioning and Deployment. Like standard hosting, cloud computing gives you a place to run your applications and store your data in a managed data center. Unlike standard hosting, you aren't required to remotely connect to a specific set of machines and configure them yourself. Instead, you provide the data center with your code and metadata about what its needs are. The data center takes care of virtualization, provisioning, deployment, and load balancing for you--completely automatically. You never get involved in installing software or configuring servers. In Windows Azure, this is all controlled through a well-designed portal at Azure.com.
• On-Demand Scaling. Like standard hosting, your cloud computing code and data is maintained on servers and storage devices. Unlike standard hosting, the scale-out of your code and data happens automatically, on-demand. If traffic levels increase, so does the instancing. If traffic levels drop, the number of active instances goes down. You can grow anytime, without having to requisition new hardware. Azure never wastes your money or the data center's hardware.
• No Long Term Commitments. Like standard hosting, cloud computing costs something. In the case of Azure at least, you aren't required to make a long term commitment or sign a contract for a specified period of time such as one or more years. You pay for what you use, and you can stop anytime without penalty. It's computing done right.
• Pay as You Go. Standard hosting often charges you for keeping machines and storage available regardless of the extent to which they are actually used. In Windows Azure cloud computing, you only pay for what you use. If you use more, you pay more. If you use less, you pay less. Just like how your electric or water bill works.
• Additional Services. Standard hosting doesn't generally provide any new software capabilities, it's just an alternative place to run code and store data. Windows Azure does provide new software capabilities, and they are both numerous and compelling. Live Services allows you to tap into the Windows Live identity and contacts services. Geneva technology allows you to support enterprise customers and let them use their native security system; and you can even federate a mix of enterprises and security mechanisms simultaneously. SQL Services provides database services with new scalability options not available in the enterprise. .NET Services gives you a service bus, which allows for business-to-business publish/subscribe communication that is firewall friendly. .NET Services also lets you run workflow in the cloud. Windows Azure really is an operating system for the cloud, and Azure Services really provide applications with a fresh set of capabilities that are also easy to get at and combine.
• Available, Scalable, Reliable. In the enterprise, some of the hardest things to do well are high availability, dynamic scalability, and high reliability. These things come "for free" with the cloud any time you use it.

Hosting is to cloud computing like radio is to color TV. There's nothing wrong with hosting, but the next generation is upon us.

Overcoming Fear of Cloud Storage

Dr. McCloud here once again with another installment of Overcoming Fear of the Cloud. This time we're looking at the fear of cloud storage.

Concern about storing data in the cloud is one of the first objections to cloud computing that is raised by some who work in the enterprise. Usually the expression of concern is followed by a gentle but firm explanation of how vital, proprietary, and utterly irreplaceable this information is. The message is clear: the data is critical to the operation of the business; the data must be protected; and maintaining its integrity and availability is paramount. The enterprise goes to great lengths to ensure this.

The first thing I will say about this is, you may be right in some cases. Some data does belong in the enterprise, depending on the nature of the data and the organization and the regulations it is subject to. But that's a far cry from saying no enterprise data should ever go into the cloud. That's why I think Microsoft's vision, called Software + Services, makes a great deal of sense for the enterprise. S + S is all about recognizing that some software and data is best kept local, while other software and data is best placed in the cloud. Rather than dictating what the split should be, S + S says you are in the best spot to make that determination. Dr. McCloud likes to call this writing your own prescription.

We can use the existence of the hosting industry to demonstrate the idea of putting your data "out there" can work for businesses. The idea is neither new or unproven and is used successfully today by businesses of all sizes. For sure, you need to have a strong comfort level about the vendor, the storage practices, the fail-safes, the data protection policies, the service level commitment, the security arrangements, and the degree of control you have. Dr. McCloud prefers sound methods of treatment and so do his patients.

Learning more about how the cloud infrastructure handles storage should also encourage you. Let's look at Windows Azure specifically. When you store something in the cloud, it gets simultaneously written to several different places, each in a different fault domain. SQL Services and cloud blob/queue/table storage are designed to scale supremely and automatically. Many things that are commonly needed in the enterprise are also very difficult, expensive, and time-consuming to get right, such as high availability, sufficient scalability, disaster recovery, and dynamic adjustments to changes in traffic levels. These things come "for free" with the cloud platform every time you use it.

One last point, putting data in the cloud does not necessarily mean it vanishes from the enterprise. We'll likely be seeing some interesting patterns develop for synchronizing and safeguarding data that lives in more than one place.

Cloud storage is a good thing, and you don't have to feel like you're taking some tremendous risk to try it out as long as you exercise a little common sense. Dr. McCloud thinks this makes for an excellent prognosis.

Fear of the Cloud

Let's talk about fear of the cloud. Cloud computing is both new and big. This generates reactions ranging fear to doubt to outright skepticism in some people. This is natural as people struggle to get a handle on just what it is and what it means. How many big ideas of the past that we now take for granted in our everyday lives were initially greeted with skepticism or even outright mockery? Quite a few.

"Fear of clouds" existed before cloud computing ever came on the scene, and is known as nephophobia. Interestingly, there are quite a few parallels between this real-world phobia, the fear of clouds, and its newer cousin, the fear of cloud computing:

• In nephophobia, the patient can experience breathlessness, excessive sweating, nausea, dry mouth, feeling sick, shaking, heart palpitations, the inability to speak or think clearly, a fear of dying or losing control, a sensation of detachment from reality or a full blown anxiety attack. A select few seem to exhibit many of the same symptoms when confronted with cloud computing.
• In nephophobia, the patient has to come to grips that they are fearful of something that poses no actual danger. The same is true of cloud computing: whatever area you're concerned about (data, security, reliability, management) is potentially done better in the cloud computing environment, and with less personal headache to you and your organization. Granted, some of this is true today and some of it will come as cloud computing platforms mature.
• Treatment for nephophobia centers around "reality therapy", finding false constructs in the patient's mind and dealing with them, in effect reprogramming the subconscious. Likewise, a reality adjustment is a good treatment for fear of cloud computing: the more you understand about what it really is and how it works, the higher your comfort level is likely to be.

Fear of the cloud can take many forms, including fear of cloud storage, fear of cloud security, and fear of cloud reliability. In future posts we'll look at these aspects individually.

Dr. McCloud is here to put you at ease. Now sit back and relax so I can examine you with my nephoscope... aha, there's your problem!

What's Holding Back Cloud Computing

I saw this interesting Gartner slide in a blog posting entitled "What's Holding Cloud Computing Back?" Since I didn't realize cloud computing was being "held back" :) I paid some attention to it. Here's what Gartner listed as reasons, verbatim:

• Service Management - technologies immature
• Scalability - parallel processing, no problem; sequential processing, different story
• Costs - economies of scale only go so far, unless customer is willing to trade data or advertising views for services
• Culture - trust, chargeback, sharing
• Connection - only as good as the Internet, unless you pay to harden your connection
• High Availability - for workloads that are stateless, no problem; for stateful workloads, same issue as enterprises
• Customization - difficult - at least with monolithic applications

Gartner is of course talking about the state of cloud computing generally as they see it. I thought it would be interesting to analyze whether these points ring true or not--and how deeply--with Windows Azure specifically in mind. Here's my take on it:

• Service Management - technologies immature. It's true many of the technologies are immature, this is just the start of a big wave with many implications. A good example is SQL Services compared to SQL Server in the enterprise, the enterprise version is far more capable today. However, in the case of Windows Azure not everything is immature. Microsoft has been doing online for some time now, growing in the scale and variety and reliability of what they offer--and some of these properties have been using the data center infrastructure. In other words, the cloud platform Microsoft is offering is also used by Microsoft itself.
• Scalability - strong parallel processing story, poor sequential processing story. This may be true of cloud computing offerings in general but here I think Azure has a very good story. One of the .NET Services in the platform is the Workflow Service. That would seem to address any kind of processing you have in mind, whether sequential, parallel, or a mix.
• Costs - economies of scale go only so far. I'm not sure what they're getting at here, they might mean that there's only so much cost savings to be realized. Well, so what? It's still a refreshing set of new choices, and no one's taking the traditional choices away. Cloud computing--at least in the Microsoft vision of Software + Services, is not about abandoning the enterprise and traditional ways of doing things. The whole idea is have some software local and some software in the cloud. The beauty of the S+S approach is that each organization is free to make their own determination about what makes sense local and what makes sense in the cloud. Obviously, cloud computing going to have a stronger appeal for some more than others.
• Culture - trust, chargeback, sharing. I do hear from some folks that they think the whole idea of putting software or data in the cloud is unrealistic, at least for their organizations. I guess my answer to that is threefold: 1. You may well be right, in your individual case. Some things just belong in the enterprise. 2. Secondly, the existence of a hosting industry testifies that some organizations are perfectly willing to put software and data "out there" as long as they can be satisfied about the security arrangements. 3. You might well change your mind down the road. Similar to web services, there are going to be the pioneers and the settlers in this new space. Not everyone's gong to be a pioneer, but the wave will likely hit everyone eventually one way or another.
• Connection - only as good as the Internet. True enough. But in case no one's noticed, we're all becoming very dependent on the Internet. That includes how customers interact with your business.
• High Availability - applications must be stateless. Well, that's true. The load balanced, virtualized, automatically provisioned nature of the platform needs stateless software to do well. But stateless has been a recognized best practice for some time now, especially in SOA, so this doesn't seem like a terrible restriction to me. And there are ways to pass state around even in nominally stateless applications.
• Customization - difficult - at least with monolithic applications. Once again I'm a little unclear as to what's being said here. In the case of Azure, I can't think of any customization restrictions the platform forces on you as compared to using .NET on premise. There are, in fact, some very nice customization capabilities in the platform including the ability to simultaneous support different security systems through federated security.

Putting it all together, I think Azure stacks up quite well against where the rest of the industry is in cloud computing. No one's pretending platform maturity, but what does exist is already compelling and competitive.