Navigate the cloud computing labyrinth

Sky-Tiger

Aren't you limiting and misrepresenting Azure?

So before you go misrepresenting Azure—or claiming that I have—you should realize that by no means is Azure limited to the Windows platform, either as a starting or ending point. You can access Azure-based apps from any platform, and you can develop using languages other than C#; Python and Perl are welcome, for example. And part of the beauty of the cloud, of course, is that the language and server technologies are, well, in the cloud. In other words, they're transparent to most users.

Still, to presume that a Python developer targeting Mac OS X systems would use Windows Azure is, at best, a bit silly. Realistically and pragmatically, it's just even not that smart. If you were comparing the power of polish of Azure to, say, some unknown upstart, then Azure's pure professionalism might sway you to use non-Microsoft technologies in a Microsoft-centric cloud-based universe. But that's not the case; you have to compare Azure to equally mature (which is to say, fairly, still maturing) offerings from Google and Amazon. In those cases, you'll almost certainly be better served to use platforms that are equally powerful in many respects, yet are by their very nature more open to multiple platforms and non-Microsoft technologies. Figure 3 makes this same point a little more visually.


Figure 3. Are you a PC? You'll like Azure


But I don't want to use Azure!

The converse is equally true: Microsoft developers targeting Microsoft platforms don't have to use Azure. You could easily go for the flexibility and power of Amazon EC2 or the sheer "cool" factor of Google App Engine. As noted previously, both Amazon and Google offer some terribly impressive features. That said, "Why?" Unless you're just out to learn new technologies—which is certainly fun and often worthwhile—you'd be hard pressed to identify a good reason to build an all-Microsoft solution and then drop it into a non-Microsoft cloud... when there's a happy Microsoft cloud waiting as well. It's just adding work and effort when that work would probably be better off polishing your app, or building another one.

Sky-Tiger

How many resources do you need? How much cash do you have?

For most of the initial months of Google App Engine's life, it was distinguished from Amazon EC2 in two key ways:

Google App Engine was free to use as a platform; Amazon EC2 was not.
Google App Engine had quote limits; Amazon EC2 did not (at least, not in any practical sense).
In late February, though, Google retained its free status for use in getting started, but added the ability to grow beyond the free resource sizing for pay. This is a huge win for Google, and actually moves them from resource-limited to resource-interesting.

Sky-Tiger

I'm using the term "resource-interesting" to suggest that a model like Google's—free up to a point, and then for-pay after that—has some huge advantages over almost any other model. First, getting started with Google App Engine is free. This means that you can try out App Engine, get things running, even deploy your apps publicly, all without spending a dime. So there's huge upside in that "free to start" approach.

But where things get interesting is that with this model, you can actually gauge your bandwidth as you go. Then you can grow your app beyond the free quotas. Amazon EC2 allows you to expand resources as needed, too, so once you're into the pay-for model, there's not a lot of cost difference between Amazon's and Google's offerings.

If billing is usage-based, what's so great about Google?

Google's free-to-start approach offers one nice advantage over Amazon: You can do some tuning and resource rearrangement before you start getting billed. Every serious programmer knows that the first version of an app usually has two sets of issues:

Functionality bugs. Things don't work, or work correctly, and need to be fixed.
Resource bugs. Connections aren't being closed, or pooling isn't in use, or something else that clogs up your app is going on and needs to be fixed.
The beauty of Google's approach is you can track these sorts of resource bugs down before you start paying for your mistakes—literally.

The result here? A slight edge for Google, but probably nothing that's going to make any decisions for you.

How does billing with Windows Azure work?

Like App Engine and EC2, Azure is priced based on consumption. The more people use Azure services, the greater the cost. Also like App Engine and EC2, Azure bases pricing on compute time (CPU usage), bandwidth (to and from), and storage. It also charges based on transactions (GETs and PUTs, for example).

Of course, this pricing hasn't been released yet (as of early March 2009), so everyone's still waiting to see exactly how it stacks up. Honestly, though, expect it to be slightly more than Google App Engine and Amazon EC2, but still in the same ballpark. Again, pricing will probably not be your deciding factor on Windows Azure, any more than it is with Google or Amazon.

Sky-Tiger

Conclusion: Simplify but don't over-simplify

It's easy to drop in a one-statement-fits-all here. You might, for example, assume that if you like Python and are a newbie, go with Google; if you're a guru, choose Amazon EC2; if you're a Microsoft person, use Azure. There's a lot of truth to putting it in that simplistic of a statement. Ultimately, though, you'd be disappointed if that was all that informed your decisions. Amazon does offer a ton of power, but for getting a solution up quickly, you can't beat Google. It takes very little time, and not a lot can go wrong.

Amazon is going to require you to know what you're doing. You might need a few books popped open, and ironically, you'll probably be using Google a lot to figure everything out (the search engine, not App Engine). But the extra work gives you more power, and virtually unlimited resources.

Azure, simply put, is brilliant for Windows platforms. Even with some rough spots, it's intuitive for the Microsoft programmer, and it's going to feel comfortable from a platform standpoint for your app users.

So what do you do? What a good programmer always does: Learn every tool you can, and use them when they're the right tool. It beats a magic 8-ball every time. Start with Google App Engine, and then take on deploying your same app to Amazon EC2 once you're comfortable digging in a bit. Break open Visual Studio and see what you can do with C#, and then deploy your app to Azure. Get experience with all three of the major platforms, and you'll benefit when you've got a particular app that has particular needs.

Sky-Tiger

Resources

Learn

developerWorks' cloud computing space is your starting point for the latest IBM, developerWorks, and general industry information on cloud computing.


You'll want to bookmark the Google App Engine blog, which has great information on and insight from the Google team, and of course App Engine in particular.


Find out about all things Amazon and Web services, from EC2 to their SimpleDB and S3 storage service, at the home page for all Amazon's Web services.


For more on Microsoft's complete cloud computing tools, check out the MSDN page for Microsoft cloud computing.



Get products and technologies

You can sign up for an App Engine key, download the SDK, and get cranking with App Engine at Google's App Engine home page.


Sign up for Amazon's Elastic Compute Cloud (EC2) on Amazon's Web services Web site.


Windows Azure is the Microsoft flavor of cloud computing, and Microsoft's documentation is well-done, extensive, and easy to manage.



Discuss

developerWorks has a forum for SOA and Web Services where you can discuss cloud computing in your particular context.


developerWorks blogs: Get involved in the developerWorks community.