Google App-Engine and Top-Down Cloud Computing

Many people are comparing Google's App Engine to Amazon S3. There's certainly some relation - both offer the ability to build an application and run it 'in the cloud' - in someone else's infrastructure, with seemingly limitless expansion room (well, Google's offer has a strict quota, but one assumes there'll be pay plans beyond that point in the future).

But Amazon's approach has been bottom-up - web services that allow you to control the bits and bobs of infrastructure you might use to create your own cloud-computing application (e.g. EC2 instances and S3 storage). This gives you a fair amount of flexibility while still being simpler and more cost-effective (in some cases, anyway) than building your own grid infrastructure. For instance, EC3 can allow you to scale to handle peak loads while still keeping your costs low when there's less traffic.

On the other hand, Google's top-down approach isn't really about giving you options, it's about creating a model for applications that run in the cloud and restricting you to that model, so that you can focus on building an application and trust that the limitations Google has placed on you will allow Google to scale it up and down as necessary to meet demand.

The former has a lot more control and sometimes that'll be very necessary for applications that are difficult to build in Google App Engine (for instance, there's only language support for Python at the moment). On the other hand, the latter offers a very simple model for creating applications at scale without needing to really know that much about how to scale an application.

It'll be interesting to see, with time, if development for the cloud is closer to Amazon's (full control, skill required) or Google's (restricted choice, with simplicity). I'd probably bet on the latter for most applications.

I'll have more to say on this later -- I'll be doing something more comprehensive for InfoQ.

Disposable

I guess I've never been a big fan of the idea of disposable razors. It seems like regular razors are pretty convenient, and I'm not sure there's much convenience to be added by throwing away the handle. I guess it never really seemed to make a lot of sense to me. Even if you want a razor just for travelling -- go buy a second razor, I guess.

It also seemed pretty wasteful. So I guess when the Yonge and Bloor stations in Toronto were papered over with "Mach 3 Disposable: Enough Said" ads, it really struck a nerve. Enough of a nerve to spend some time in Photoshop to translate their ads into the subtext, as read by me:
I wasn't sure how much one could get away with without dealing with cease-and-desist letters, so I decided not to pull in the Gilette name or the Mach3 specialized writing, just to try and calm down the possiblity of legal storm. That said, either nobody ever really notices and neither will Gillette, or perhaps this'll attract enough attention to bring Gillette, at which point I hope this has reached a large enough audience, by then, that the value of issuing letters to have me remove this will be significantly reduced.

Maven Web Project Gotcha: Overlays

In order to prepare for some integration testing of a multi-WAR service layer, I included one WAR into the project dependencies of a Maven web project. If I had time to do this in 'the maven way', I'd probably pull this into an integration test subproject, but, sadly, I don't have time for that in this instance.

Unfortunately, this leads directly to Maven's principle of 'most surprise'. Turns out, if your web project depends on a WAR, the contents of that WAR will be overlaid over your web project, unless you explicitly tell it otherwise. Since I hadn't read about overlays this was actively damaging to my project, and very confusing. This cryptic build output helped me understand what was going on:

OverlayPackagingTask performPackaging overlay.getTargetPath() null

I hope that my mentioning this will save some of you future grief.

JAX-RS Momentum

It's great to see JAX-RS picking up momentum. I've done work in Restlet, and I'd like to spend some time in Jersey, so it's great to see that I'll have more choices next time.

Next comes tool support, integration, and then ... the world. Although, to be honest, I'd be happier with web services and remoting if I felt that they were consistently being used appropriately. I still find that people consider remoting when they don't need it -- too busy looking for the long-term flexibility and not enough time actually building the immediately necessary functionality.