views:

436

answers:

3

I just finished looking at this question: http://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 Server, 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?

A: 

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?

jldupont
How does this remotely answer the question?
Jed Smith
He voted mine down, too, because I asked. I actually work *in* cloud computing, and I know that it's been around for a while, albeit in various forms. This sort of FUD about cloud is ridiculous, and I really hope he catches on and just deletes the answer.
Jed Smith
Guys - I guess it depends on your definition of Cloud Computing: it is ill defined at the moment. For the Saas/PaaS segments, I am sorry **but** the ground isn't set yet and the companies will inevitably differentiate from one another and leave the customers in difficult positions. I know that the vendors of such platforms will voted me down on this but I sure hope the customers on the other side will see the message.
jldupont
I worked with windows azure and live mesh applications for a year now. And still plan on continuing our next module on azure just for the features... but u know wat, I still dont get the point or even know wat cloud computing is.
Shawn Mclean
Cloud Computing is a marketing term: it comes down to market segmentation: please read on your favorite site more about SaaS, PaaS, IaaS.
jldupont
+1  A: 

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.

Jed Smith
+2  A: 

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.

Eric J.
What you are referring to here is IaaS: Infrastructure As A Service. This is but one market segment generally viewed as being part of the overarching category "Cloud Computing".
jldupont
We are a SaaS provider. I'm discussing architecture of SaaS applications deployed in a virtual environment as well as the supporting services to operate them. IaaS is often understood to mean "servers, network equipment, memory, CPU, disk space, data center facilities." EC2 also provides services on top of that infrastructure which provide the basis of a platform to operate applications. I guess at this point though in the (early) development of cloud computing there will be a lot of opinions about definitions of terms.
Eric J.
Of course you are a SaaS provider but you are using services from an IaaS vendors. Yes there will be opinions about the definition of terms but in general I try to stick to ones "marketed" by analysts firms (for better or worse).
jldupont
As the question is very "open ended", I believe it is worth putting some things in perspective: at the bottom of the value chain (IaaS) one can expect to install pretty much everything **because** that's what the **service** IaaS providers offer. At the middle of the spectrum (PaaS), the providers offer you a *platform* with some of the concerns abstracted out in return of some money (and less control of course). And so on so forth.
jldupont