Building Cloud Applications: Windows Azure vs.

Google App Engine

I’ve used Windows Azure to host a few apps and Google App Engine to host one small
app. Clearly this qualifies me to make a definitive post comparing the two. I’m leaving
Amazon out of my cloud app comparison because a) Azure and App Engine seem like
more direct competitors and b) I have almost zero practical knowledge of Amazon’s
offerings – It’s all theoretical.

In general, I’m excited about cloud computing and I like the options that are out there.
For small departmental LOB apps it’s nice to have a quick place to deploy to without
requiring new server environments. For something like a Facebook app that might need
enormous scale quickly, Azure or GAE makes this really easy. I think Microsoft did a
great job of creating a product to ease people from stand alone windows servers to a
cloud environment with hosted services, azure and the ability to mix on and off premise
pieces of an application.

Here are some reasons to use Google App Engine (GAE) and advantages of the platform
compared to Azure

• Want to write code in Java, Python/Django or any language that runs on the JVM
• Need integrated mail functionality
o Azure requires your own SMTP server outside of the cloud environment
• Need integrated XMPP messaging
o Again, Azure would need an external server.
• Need scheduled processing jobs
o You can be creative and write something with queues and/or worker roles
or perhaps a service running elsewhere to ping your web server on a
schedule to run a job.
• Need distributed caching via memcahe
o There has been some talk of adding Velocity to Azure which would be
comparable to memcache. Otherwise, if you only have one web instance
you can use ASP.NET caching. If you have multiple web instances, then
you need a way to invalidate the other server’s cache. Inter-role
communication is coming soon which would make this possible. In the
mean time you could use .NET service bus to communicate between web
role instances (in theory it seems like this would work)
• Want mostly free hosting for small applications – GAE has a free quota
o Azure is free up to a limit in the CTP, but once live nothing is free. I’d
really like to see Microsoft keep some free version for developers to
experiment with or include CTP-like free quotas to BizSpark members.
Developers like to tinker and release small apps. If App Engine is free,
they are going to chose that and will probably be less likely to chose
Azure once comfortable with GAE. It seems like a good approach to
provide some level of free support until an app becomes large enough
 where a developer can afford to pay (or it’s too costly to provide them free
service)
• GAE has a ridiculously fast deployment time. One click in GAE launcher or a
console command and the application deploys in less than a minute
o Azure deployment is just brutally slow. Make a sandwich, grab a good
book – it’s going to be awhile. This is especially an issue when you
consider the next bullet point. Every time you deploy to Azure it’s
provisioning a new virtual machine unlike GAE which is just copying
files. I’m sure there are good reasons why this needs to be done, but I
really wish it had some quick deploy / file copy option. There is nothing
more gut wrenching then waiting 30 mins to finish deploying and you
forgot to to change one line of code. Now you are stuck waiting another
30-45 mins to delete the current instance and redeploy.
• If it runs locally in GAE, chances are very high it will run the same in GAE once
deployed
o Some things I do that work fine locally in Azure don’t work in the cloud.
99% of the time it’s my fault so I’m not blaming Azure, but it seems to
happen to me somewhat regularly. Unfortunately I don’t have specific
examples, but I’ll Twitter them as they come up. This wouldn’t really be
an issue for me if I could quickly view logs and redeploy on Azure.
• GAE has excellent utilities for CRUD operations on your data store
o Once you deploy to the cloud in Azure you can’t easily
view/delete/edit/add entities to the storage systems. I wrote my own utility
which I’ll post soon to do that and there are some others out there with
various levels of functionality. It’s still kind of a pain though and the
ability to do this would help debugging.
• GAE is fast to change code. For most code changes you can just change the line
and refresh the browser.
o In Azure this can be a real pain. First it’s managed code so you need to
compile. Second, debugging Azure deploys itself to the local dev fabric. If
you make a change to one line of CSS or JS or HTML in Visual Studio,
then you have to stop debugging, change the line and re-run which takes a
min. or two. When you are making small changes like a line of Javascript
this is super tedious. It almost made me cry. I had to make a 2nd web app
in my project, move the js/css into there and change the links to reference
those in the web role. That way I could make changes without having to
stop my local development server. This can’t be right. It’s awful. Clearly
I’m an idiot and am doing something wrong. I really don’t understand how
people are building complex UIs in a web app if this is the case.
• GAE lets you view logs in real-time
o Viewing logs in GAE can be done through the apps dashboard. In Azure I
need to go to the portal, click to copy the logs to the Blob store which
takes some time. Then I have to compile the Drive Mount powershell
script, configure with my credentials, run it, mount the drive, browse to
the log dir on the blob store, copy them locally and view. Granted once
you have the script compiled and the drive mounted you only need to click
 copy on the portal and copy them via the command line and view. Still it’s
slow and cumbersome. For a CTP it’s mildly acceptable, but Microsoft
really needs to add some sort of online log viewer if I’m going to be
paying for this. The only way to troubleshoot what’s wrong when you
deploy to the cloud is via the logs and Azure makes this somewhat painful.
• Simple API for accessing GAE data store
o Part of this is just comparing python to C#, but it’s a lot fewer lines of
code to define a model and do any CRUD operations on it in GAE
• Some useful data store functionality
o GAE supports list properties and referencing other entities. In Azure you
could just serialize a list or convert to JSON to store multiple values, but
not as convenient. The references property also makes transitioning from a
relational store to a flat table storage easier. Azure it’s a little more of a
pain to get referenced entities and it’s all manual.
o Secondly you don’t have to worry about creating unique row keys in
GAE. In Azure each entity needs to specify a row key and partition key.
They also have to be named RowKey and ParitionKey which seems odd
when you can specify the attribute: [DataServiceKey("PartitionKey",
"RowKey")] Then I need to add some comments and remember my row
key is really my username or something.
o Indexes. In GAE you can add indexes to some columns with some
restriction. For now Azure doesn’t support indexes on any columns
besides the key
o GAE supports transactions which is helpful when changing multiple
dependent entities
• No hassle config – you basically have an app that scales without worrying about
partitioning data or adding instances.
o In GAE the app automatically scales. In Azure you need to change the
config to add new web or worker role instances. This requires more
monitoring and it’s also harder to write worker roles that balance
effectively especially since in code you can’t tell how many are running.
You also have to think more about partitioning your data, but I suppose
that might let you you do more performance tuning.
• Development environment on Linux/OSX/Windows
o Azure development requires Windows.

Here are some reasons to use Windows Azure and advantages of the platform compared
to GAE:

• Want to write code in PHP or .NET (C#, F#, VB.NET).

o It’s interesting how between the two they support most languages but
there isn’t much overlap unless you try to do something crazy like run
PHP on the JVM or IronPython on Azure.
• Want interactive debugging while developing locally. Some people log
extensively, but I like to live by the breakpoint.
 o Actually this is probably possible in Eclipse for GAE, but I haven’t tried
that out.
• Need background processing. In Azure you can have a worker role running 24/7.
o In GAE you need to specify a cron job to run on a schedule. The cron job
needs to ping a url which executes a task, but that task is limited by the
request timeout. Basically you have 30 seconds to finish processing while
Azure can run for hours on a single task.
• Need flexible queue storage. In Azure, queues work like I’d expect a queue to
work. I put data in, something gets it out. You can specify time to live and the
visibility time when some process grabs a message off the queue
o In GAE the queues work a little differently. It’s nice that you enqueue data
with the function to call, but you are still limited by the 30 second time
limit to execute that work. The support is also still experimental
• More robust blob storage. In Azure there are great methods are dividing up large
files into blocks and retrying failed blocks. This makes uploading large blobs
easier.
o GAE blobs are stored in the regular data store and are limited to 1MB.
Azure supports 50GB blobs.
• Staging environment. While deployment to staging is slow in Azure, it only takes
a second to switch from staging to deployment. This is great for cutting over new
builds.
o In GAE you’d have to manually create a 2nd staging site and manage that
process. You could probably write some scripts to do all this, but it’s built
in and easy in Azure
• Relational and Table Storage
o If the thought of using a non-relational store makes you cower in fear then
Microsoft also provides SQL Azure – the same relational db running
locally available in new cloud friendly form. Personally I prefer one giant
table, but the option is nice.
• .NET service bus integration. If you have Active directory you can somewhat
easily integrate authentication between your apps on Azure. Although most of
the .NET service bus infrastructure is REST-based so you could probably use
some of those features in GAE with a little bit of work. You could also do things
like host your data store locally in SQL server behind your firewall, but host the
web front-end in Azure. This lets you gradually migrate to full on cloud apps or
keep sensitive data in house or reuse some existing non-cloud services.

Between the two I think you have good options depending on the type of apps to build.
The development time on GAE feels faster to me because of deployment, log viewing,
and probably just less code in Python vs. C# The cost of GAE makes it a little cheaper to
launch new applications. In some cases background processing or relational storage are a
must and Azure is a better choice. Or if you need to leverage some onsite data or
services, then Azure is great. If you are porting an existing app then your choice is most
likely made by which language the current app is written.
While I really do like Azure, the previously mentioned development time issues
combined with my Visual Studio not being able to make CSS/JS/HTML changes on the
fly make me hesitant to use Azure for casual projects. I probably spent around 30 hrs to
code all of TwtMyCard on Azure. In App Engine I maybe could have saved a few hours
because of writing a little less code in Django/Python and the GAE data store. But on top
of the 30 hrs in Azure I easily wasted 10-15 hrs with deployment, tracking down issues in
the cloud, getting the logs and fixing HTML/CSS/JS.

If Azure added web viewable logs, fixed the VS issue, supported Velocity, supported
indexes and added inter-role communication, I’d be so happy.

Regardless of hosting choice, I love not having to mess around with web server or
database configuration to deploy an application that scales reasonably well (in theory –
still waiting for Silverlight Draw or TwtMyCard to reach 1 million users to verify).

In the future I’ll update this post as I use them both more or people tell me I’m wrong
about some things or the products evolve.