Webservices with Google Apps Engine or Azure?

Simple problem, actually. I am trying to evaluate the possibilities of Google Apps, using Python as development language. It seems practical to create a web application or web site with it, but how about creating web services?

I am not too interested in solutions to create a SOAP or REST service in Python for Google Apps, since a simple Google search should provide plenty of solutions. I am more interested in experiences and ease of use.

But the real question is: When comparing a web service in Google Apps with web services in the Microsoft Azure environment, which would provide the better performance? The best user experience? I don't care for the actual development languages but need a good comparison of pro's and cons of web services in both the Google App Engine and Microsoft Azure.

Somehow, Azure seems better suited for services while Google seems better for sites. A tough choice...

Would be very interesting to see if both could be combined into a single solution. :-)

Btw, choosing which engine to use also means choosing the proper development environment and programming language. While 开发者_StackOverflow中文版I'm proficient in .NET and Python and many other languages, the choice for the service engine determines my focus for future projects.

When building services in Windows Azure, they'd simply be processes running in your VM (Windows Server 2008 SP2 or R2 SP1). You can host services easily in any of the three role types:

• Web Role (essentially Windows Server with IIS running) - just add a WCF endpoint to IIS or self-host from your own process).
• Worker role (Windows Server with IIS not running) - self-host from your own process
• VM role (your own Windows 2008 Server VM pushed to Windows Azure) - Host with whatever mechanism you install / set up.

Each VM in Windows Azure may expose a total of 5 endpoints. These can be a combination of input (external facing) and internal endpoint, each port supporting tcp, http, or https. You define endpoints in your vm role's properties.

Internal endpoints are only usable by other VMs in your deployment. You can't see them / access them from anywhere else, including other Windows Azure deployments. Input endpoints are accessible by the outside world.

If you want an app running in Google to access your Windows Azure service, simply connect to the endpoint via ip+port. The one thing you'll want to be aware of is bandwidth usage. Because your Google-hosted app will be in one data center and your Windows Azure service in another, you'll pay ingress / egress for data going in and out of your Windows Azure service (and I'm guessing there's an associated bandwidth charge on the Google side, but I'm not sure).

It's actually pretty simple to set up a service. For .NET-based examples, look at the labs in the Windows Azure Platform Training Kit (this also other good examples, such as setting up your first Windows Azure application). For a python service host, you'll need to execute python.exe from your VM role's OnStart() event handler, passing in your script name (and optionally port number to listen on). For a simple example of launching python.exe, look at Steve Marx's blog post here.

EDIT: If you're looking to host multiple services (e.g. multiple ports), you can choose to host them in a single VM role or in separate roles, to optimize for cost (with the known limit of 5 endpoints) or performance (scale each service independently).