If you watch technology news, you've probably heard Steve Ballmer talk about how Microsoft is "all in" for "the cloud." Combined with media outlets that further dilute the meaning of the term, most people don't know what the hell it means. But in a broad sense, "the cloud" is simply "stuff" that runs on that Internet, blurring the lines of computer and network topography. If you've used a Web-based e-mail app, I'd say that qualifies as a cloud service. We just scored a big contract for the USDA or something to have hosted Exchange e-mail and calendaring stuff, so they don't have to own servers or maintain software and what not. The promise of cloud services is that businesses (and consumers, to some degree), don't have to own servers or update software or install things on their computers. It's not a new concept, but for most of the last decade, there wasn't enough bandwidth or cost efficiency for IT folk to consider it (plus, I think they wanted to preserve their own jobs).
For my sub-team, we're working on a new system that is entirely cloud-based. Our company offers the Azure platform, which includes Windows Azure, essentially a one-off instance to host an application, storage accounts for no-SQL table storage, SQL Azure which is basically a hosted database and some related stuff (including full-blown VM's). What's particularly neat about it is that you can add new instances very quickly, and the load balancing happens automagically. Heck, we even deploy with a button push at this point.
You could actually run the entire thing on one server, in theory, but doing something with a high transaction volume is not ideal like that. The biggest problem is that if you outgrow the single server, then what? If a queue or service goes down, what happens to the other things that depend on the system? Then there's the issue of having operations folks who need to patch the servers, deploy when you make a change, etc. For a big system like this, using actual servers we own would be probably about the same cost right now, but undoubtedly will go down sooner than later.
Our system is very distributed, with three worker process instances, a couple of queues, a SQL database and two Web instances (one's a REST-based API, the other a Web admin app). We don't know for sure just how big it has to scale, but the cool thing is that it won't curl up and die if any particular piece goes down for any reason. It's pretty exciting to build something like that.
It has been kind of quirky, because the Azure products are not that well documented, and a bit of a moving target. As much as I'd like to criticize the company for that, really it beats the big bang release stuff that most of the company does (see: Windows and Office), and I love that they're iterating relatively quickly. I can see how there is definite cost savings for distributed systems, even if the learning curve is a little rough up front.
Part of the satisfaction comes from building something totally new, which is pretty rare in any software development job. But it's also fun because of all this new tech. My own involvement has been pretty deep too in the overall architecture, something I really enjoy thinking about. I love to whiteboard that kind of crap!
I think it will probably be awhile before the cost comes down to a point where it makes sense to host my own sites on this stuff, but I can definitely see it getting there. I love the idea of not having to maintain a server, and just paying for each individual app as needed.
As for what we're working on, I don't know if I can talk about it yet, but I think in January we'll launch a beta. It may or may not sound like something cool at that point. :)