On a flight Honolulu-Seattle; vacation is over, and I'm back to sharing with you my wild thoughts (ok, not ALL of my wild thoughts :-)).

Have you noticed how people tend to react when they learn about some of the cloud "limitations"? Like "what do you mean, no atomic transactions?" or again: "no principals? Where do I manage my principals?". Well, weeell. The point is, guys, that cloud is not classic hosting; it is designed to solve different problems, and it is equipped with different weapons. I don't have a killer app to use for making my point here, this is all way too new, hence I'll try to use one of my signature metaphors (already used at TechEd EMEA& OreDev). I will argue that deploying a solution on-premises is a bit like owning a car, taking advantage of hosting service is like renting a car, and that using cloud computing is a different thing altogether: it's like taking a train, going-from-A-to-B capability as pure as it can get.

On premises solutions ~= driving your own car

As somebody who walked every day a good 3 Km from age 12 to age 27, I can tell you that having your own car is just great. You can go wherever you want with it, whenever you want: if while going from A to B you want to do a detour to the memorabilia shop and buy a hideous spoon for your mom, you certainly can. You can customize your car at will, from the canoe holder to the flames finish on the doors; and if you scratch it on a fence, you can decide when (or if) to fix it. Of course, with great power comes great responsibility: the car needs to bought, the insurance paid, and if you run over the foot of a bystander there are consequences.

The parallel with a solution on premises is obvious: you have as much control as you can get, but you pay for it.
You pay for the sheer hardware, but you can choose everything in details; you pay for the platform maintenance, patching and the like, but you get to choose exactly what you want (say an old OS); you pay for the software, licenses-development costs-maintenance, but you get quintessential control on whatever your solution looks like.

I don't know why the hype works the way it does. Once a technology rises to the public attention, there's a tendency of overstretching the range of situations in which it will be used (often "in the future") and only after some time the pendulum finally swings back to reason. Don't fall for that trap with the cloud. There are plenty, PLENTY of reasons for which you may want to have a solution on premises: maybe you have a production line, and you want to keep the computation close to the actuators; or more commonly, you may have a heavy investment in various systems that work and you expect to get ROI for a long time to come. If you have 5 kids and you live 5 Kms from the nearest town, it still makes sense to own a car.

Hosting ~= renting a car

I like to think of hosting as something akin to renting a car. You still have a good degree of control, though less than when you own: decent choice over the car model you want to pick, complete control over the itinerary and so on. You pay an amount that is proportional to the days of actual use, but in general if you need a car every day of the year you'd end up paying more than if you'd own. You still have responsibilities: running over the foot of the bystander can still cost your license, if you want to go from A to B you better make sure you know which roads will get you there, and so on. Furthermore, you now have obligations such as treating the vehicle with some care.
Dealing with a hoster or a co-locator is similar to the above in many ways. You don't have to buy the hardware, and you don't have to provide the air conditioning or the electric power for the rooms where it sits. You pay for a period of time of use, as opposed to the capex you'd put down for your own data center (the costs are a point where the metaphor may be less accurate). On the other hand, your choices are not boundless anymore: which web server products are available, which databases or SDKs, which virtualization technology? And, above all, you still retain a level of responsibility. Do you have a series of VMs? When a zero-day patch comes out, it is your responsibility to apply it to your VMs. Do you want users from a partner org to have access to your app?  It's up to you to install suitable software and set up a federation. And naturally, since you are expected to deal with every aspect of your app you are still free to mess up things: if you do I/O in the wrong places in the pipeline of your web services, the performance of your app will suck regardless of how many VM instances you buy. Note: all this holds even if your hoster happens to be an internal hoster, that is to say another division within your company offering services such as virtualization/server consolidation to internal customers: the biz model does not change much the architectural constraints (thanks Ryan for the discussion that made me understand that this should be explicitly called out).
Hosting is awesome. I love hosting. You have an old solution that requires hardware no longer meeting your standards? Set up few virtual machines, your application can ascend and the old machines decommissioned. You need to expose pages on the internet, but you don't have the structure for doing so? Buy some internet space on a web server, and that's it. Does that remind you of a company that leases, instead of buying, the car fleet for its sales force? (no pun intended).
Those are classes of problems in which renting infrastructure has a clear advantage over the approach in which you own everything: however there are other classes of problems where neither approaches are effective.

Say that your startup owns a web application which produces revenues mainly by selling ads, and say that for some reason you end up on top of Digg: for that day, you'll experience a surge in requests. If you own your own datacenter, chances are that you sized it for handling much less traffic and you won't keep up: that means missed revenues. If you deployed your app in a series of VMs at some hoster you may end up not keeping up anyway. Here I am talking about an application, not just a page server, hence scaling may require not only firing up a new VM instance: should you add a new DB role machine or a new web frontend role? Maybe is the backend that is choking performances? And once you fire the new instance, how do you configure the rest of the solution to use it properly? No, simply not owning the hardware won't help you here: you need a different solution.

Think that this is confined to web2.0 scenarios? Think again. Say that you are a business ISV, selling subscription based apps to many tenants. You need to ensure that every tenant can access your app in a secure way, but you also want to make it easy; and you want it easy, yes, but also expressive enough to allow fine grained authorization. If your business customers are in the THOUSANDS, you *need* to find ways of streamlining the process: self provisioning or similar tricks would be of use here. Now tell me, does hosting your app in some third-party VM system help for this? A little: at least you don't need to worry too much about handling bandwidth and ports. But that's not the point: the resource given to you, a VM, is still too raw, it still requires too much work and know-how specific to building distributed & highly scalable solutions. No, we don't need just more of the same but something qualitatively different: what you need for this this classes of apps are capabilities that are closer to the result you want to obtain. Sometimes you just want to go from A to B, and focus on other things instead of remembering to check the fuel level or wondering if you're holding the map upside down.

Cloud solutions ~= taking the train

Above I said I've walked 3 Km every day for 15 years straight: did I do it because I'm a fitness nut? Unfortunately my oversized belly shows how preposterous that idea is. I walked because I was going from home to the train station and back.

The train is some kind of magic. You boa