How to design applications for cloud computing where multiple clouds may be involved

I just finished looking at this question: https://stackoverflow.com/questions/753122/which-cloud-computing-platform-should-i-choose

But, I am not certain what I should do in designing an application for safety engineers, so a high uptime is important.

So, if my application is written in ASP.NET, using SQL Se开发者_开发知识库rver, it would seem that my best bet is to design for Azure, but would Amazon's solution be a good choice? How would I decide if I should just have everything on the same system or have the data on Amazon's cloud and the ASP.NET on Azure?

I have another application that I am working on that deals with utility information, for water and electricity, so there is usage and billing info, and it was written in PHP using SQL Server. Would this be a possibly good application for cloud computing? It would seem that Amazon's solution would be the best solution for PHP, so my only option, but, how do you decide which parts of their offerings to use?

Basically my question is on the application architecture. Designing for hosting is easy but cloud computing adds new challenges.

My main concern is purely on the design of my application.

If I decide on the language, does that lock me into a cloud solution?

When would I want the database to be in a different cloud than the application?

If I want to use the LIFT framework (written in Scala) would any of them allow me to install whatever I need?

We run a fairly large financial services SaaS on Amazon AWS.

There are two general issues at play here: Application Architecture and Cloud Platform Services.

I have found that our application architecture is essentially the same as it would be if we were deploying to in-house virtual machines or real hardware. We created a fairly standard n-Tier application using mostly open source tools (Java, Spring, Hibernate, MySQL, Terracotta, ...). There are some considerations when it comes to a high-available / error tolerant database (since hardware-based options are not available) but other than that we don't really "target" a particular cloud implementation.

The Cloud Platform Services is another matter entirely. By that, I mean things like:

• Starting / Stopping / Monitoring / Managing / Scaling instances
• Availability / Redundancy (e.g. Amazon has Availability Zones)
• Deploying / Initializing / Configuring instances
• File backup / recovery
• Security (e.g. firewall control)

There is little if any standardization in that area, though that is an area of active interest.

In broad terms, you will probably want to architect your application in a cloud-neutral manner, but will create operational procedures that are very specific.

With regard to splitting the presentation and DB between different providers, I would not suggest that because:

• If either provider goes down, you are down
• Data transfer across the internet is slower, more expensive, and less secure than data transfer within one cloud provider.

A better use of multiple cloud providers would be to deploy entire copies of your application to two or more, balancing load across the two or possibly having one on hot standby in case the primary went down. If you capture transactional data, though, you would need a strategy to reconcile data captured in the standby environment. That may or may not be viable, depending on the nature of your application.

You can generally install whatever software you like in your virtual servers, though I don't have specific experience with Azure. If you use AWS or similar services, installing LIFT will not be a problem.

Deciding on a language does not lock you into a provider; however, designing to run on Windows does. Windows virtualization is a much narrower market than Linux virtualization; Xen, the technology Linode, Slicehost, and so forth use, will not virtualize Windows more than once.

With your applications targeted for Windows, your choices are decidedly thinner. In my market, I know that Amazon caters for Windows (as does Azure, obviously). However, more cost-effective solutions like ours and Slicehost's will not -- Windows will cost you a premium.

As for cloud segregation: the primary reason to segment your application in multiple "clouds" is to provide application reliability. Clouds do go down -- admittedly, rarely -- and having all of your eggs in one basket will cost you for an application that requires high availability. With your database in a separate cloud from your application, however, you are going to suffer latency for doing SQL over the Internet (plus require some architecture for protecting that traffic, like a SSH tunnel, or protocol-level encryption that SQL Server might offer [not really sure, I'm a PostgreSQL guy]).

Don't fall into the trap of thinking that cloud hosting is all that different from hosting. In fact, they're very nearly the same. At my company we have the opinion that cloud hosting is just a new way of thinking about the same 'ole hosting. It's nothing magic.

To design for cloud hosting, your application just needs to have sharding capabilities and be aware that nodes might be added or removed at any time. That's not terribly hard to account for depending on how you architect it; usually, only a load balancing application is even aware of the cloud-specific semantics.

It is the dawn of "Cloud Computing" and like with any such arising, the contestants are laying their "mouse traps" hoping to catch as many as possible. It will take some time before the players come to defining a common ground (i.e. standards of some form or another) and until then, their weapons of "differentiation" will force us to choose sides.

I guess this is too "business oriented" and it will get voted down.. but hey, I think about the business aspects before the technology/language. At the end of the day, it comes down to making money.

If anybody thinks about not being locked to a Cloud Computing vendor (the SaaS/PaaS types whereas the IaaS type vendors are further along) this early in the game, well, you are in for some big surprises. Fire away!

DISCLAIMER: I am not representing a Cloud Computing vendor of any type (SaaS, PaaS, IaaS). Would the people who voted me down care to identify their allegiance?