Google finally got into the cloud infrastructure game, announcing their Google AppEngine. As rumored, AppEngine opens parts of Google's legendary scalable infrastructure for hosted applications. AppEngine is in beta, with only 10,000 accounts available. They're already long gone, but you can download the SDK and run a local container. Here are some quick pros and cons: Pro Dynamically scalableGood lifecycle managementQuota-based management for cost containmentCon Python apps onlyYou deploy code, not virtual machinesWeb apps onlyAt this point, I'm a bit underwhelmed.

Over the last six months, I've grown thoroughly dependent on OmniFocus. It's a "Getting Things Done" application that lets me juggle more projects, personal and professional, than I ever thought I could. Now, Omni says they're going to bring OmniFocus to the iPhone. So far, the iPhone hasn't compelled me, but I think that will be the trigger.

It's an honor and a thrill for me to report that Release It received a Jolt Productivity award!  

Or: On my way to San Jose. On waking, I reach for my blackberry. It tells me what city I'm in; the hotel rooms offer no clues. Every Courtyard by Marriott is interchangeable.  Many doors into the same house. From the size of my suitcase, I can recall the length of my stay: one or two days, the small bag.  Three or four, the large. Two bags means more than a week.

I spend most of my time dealing with large sites. They're always hungry for more horsepower, especially if they can serve more visitors with the same power draw. Power goes up much faster with more chassis than with more CPU core. Not to mention, administrative overhead tends to scale with the number of hosts, not the number of cores. For them, multicore is a dream come true. I ran into an interesting situation the other day, on the other end of the spectrum.

As I was writing my last post, I somehow missed the news that Sun is building their own cloud platform, called Project Caroline. There's a PDF about it. It appears to be a presentation for JavaOne.  It may be locked down at any minute, so the link might not work by the time you read this. Caroline looks a lot like Amazon EC2, but with some very nice control over VLANs (I suppose they would be Virtual VLANs?

The trajectory of many high-tech products looks like this: Very expensive. Only a few exist in the world. They are heavily time-shared, and usually oversubscribed.Within the reach of institutions and corporations, but not individuals. The organization wants to maximize utilization. Corporations own many, as productivity enhancers, some wealthy or forward-looking individuals own one. Families time share theirs. Virtually everyone has one. To lack one is to fall behind. No longer a competitive advantage, the lack of the technology puts one at a disadvantage.

Agile developers measure their velocity. Most teams define velocity as the number of story points delivered per iteration. Since the size of a "story point" and the length of an iteration vary from team to team, there's not much use in comparing velocity from one team to the next. Instead, the team tracks its own velocity from iteration to iteration. Tracking velocity has two purposes. The first is estimation. If you know how many story points are left for this release, and you know how many points you complete per iteration, then you know how long it will be until you can release.

Anyone who's addicted to a Blackberry already knows about Monday's four-hour outage. For some of us, the Blackberry isn't just an electronic leash, it's part of our business operations. Like cell phones, Blackberries have a huge, hidden infrastructure behind them. Corporate Blackberry Event Servers (BES) relay email, calendar, and contact information through RIM's infrastructure, out through the wireless carriers. It was RIM's own infrastructure that suffered from intermittent failures during the outage.