Four short links: 7 September 2009

XMPP, Future of Web Frameworks, Infrastructure Stories, Better Email Client

1. App Engine Now Supports XMPP (Jabber) -- messaging servers, whether XMPP or PubSubHubBub, are becoming an increasingly important way to loosely join the small pieces. Google's incorporation of XMPP into GAE reflects this (and the fact that Wave is built on XMPP). (via StPeter on Twitter)
2. Snakes on the Web (Jacob Kaplan-Moss) -- The best way to predict the future of web development, I think, is to keep asking ourselves the question that led to all the past advances: what sucks, and how can we fix it? So: what sucks about web development? An excellent and thought-provoking talk about the possible directions for improvement in web framework design.
3. Ravelry (Tim Bray) -- We’ve got 430,000 registered users, in a month we’ll see 200,000 of those, about 135,000 in a week and about 70,000 in a day. We peak at 3.6 million pageviews per day. That’s registered users only (doesn’t include the very few pages that are Google accessible) and does not include the usual API calls, RSS feeds, AJAX. [...] We have 7 servers running Gentoo Linux and virtualized into a total of 13 virtual servers with Xen. [...]". Interesting technical and business discussion with an unexpected busy site.
4. So's Your Facet: Faceted Global Search for Mozilla Thunderbird -- email clients are LONG overdue for improvement. Encouraging to see an active and open research project to improve it from the folks at Mozilla Messaging.

Four short links: 9 July 2009

1. Ten Rules That Govern Groups -- valuable lessons for all who would create or use social software, each backed up with pointers to the social science study about that lesson. Groups breed competition: While co-operation within group members is generally not so much of a problem, co-operation between groups can be hellish. People may be individually co-operative, but once put in a 'them-and-us' situation, rapidly become remarkably adversarial. (via Mind Hacks)
2. Yahoo! TrafficServer Proposal -- Yahoo! want to open source their TrafficServer product, an HTTP/1.1 caching proxy server. Alpha geeks who worked with it are excited at the prospect. It has a plugin architecture that means it can cache NNTP, RTSP, and other non-HTTP protocols.
3. App Engine Conclusions -- I've reluctantly concluded that I don't like it. I want to like it, since it's a great poster child for Python. And there are some bright spots, like the dirt-simple integration with google accounts. But it's so very very primitive in so many ways. Not just the missing features, or the "you can use any web framework you like, as long as it's django" attitude, but primarily a lot of the existing API is just so very primitive.
4. Microsoft Hohm -- Sign up with Hohm and we'll provide you with a home energy report and energy-saving recommendations tailored to your home. Wesabe for power at the moment, with interesting possibilities ahead should Microsoft partner with smartmetering utility companies the way Google Powermeter does. This is notable because this is a web app launched by Microsoft, with no connection to Windows or other Microsoft properties beyond requiring a "Live ID" to login. For commentary, see Microsoft Hohm Gets Green Light for Launch and PC Mag. (via Freaklabs)

Four short links: 8 July 2009

1. Stop Whining About Facebook's Redesign (Slate) -- How can I be so sure that you'll learn to like the redesign? Because you did the last two times Facebook did it. The conclusion is that sites don't say why they're redesigning, and that causes the resistance.
2. C# and CLI under the Community Promise (Miguel de Icaza) -- Microsoft have announced they won't pursue patents relating to C# or the .NET Common Language Infrastructure (CLI): It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions. You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications. Good news for Mono and other .NET-compatible projects.
3. app-engine-patch -- a patch that lets most of Django work on Google App Engine. (via caseywest on Twitter)
4. Scope -- talk by Matt Webb, given to Reboot 2009. Every ten slides I sigh happily as new mental connections slide into place, as only Matt can make them. Worth it just for finding this Stewart Brand quote, "We are as gods and might as well get good at it." That one sentence could direct a lifetime of action.

Google App Engine Lets Your Web App Grow Up

Google released App Engine less than a year ago (Radar post). It was the first chance for external developers to use the power of Google's servers. The powerful platform supported Python and was free (within limits). It now supports 45,000 apps and those apps get over 100 million page views per month day. Those pageviews were all free, but they had limits.

That's going to change. After today developers can pay to have more storage, more bandwidth, more CPU time and send more email. The costs as of this morning are listed below with a comparison to the AWS equivalent cost.

• 10 cents per cpu core hour (AWS charges $.10/hr for a small, standard Linux instance and up to $1.20/hr for an XL, Hi-CPU Windows instance in EC2)
• $.10 per gigabyte transferred into AE (AWS charges $.10 for all data transferred into S3)
• $.12 per gigabyte transferred out of AE (AWS charges $.17 for the first 10 TB/month transferred out ofS3)
• $.15 per gigabyte stored per month (AWS charges $.15 for the first 50 TB/month stored onS3)
• .0001 dollars per email (AWS does not have an equivalent)

Without running a more advanced cost calculation it seems that App Engine is slightly cheaper for smaller web apps. Pete Koomen, an App Engine Product Manager, would not say if they would add tiered pricing. I can't imagine it happening until after they add background processing for applications.

Developers will only pay after their app surpasses the free limits (and there are several AE apps that already have like buddypoke.com and mentalfloss.com). The existing free quotas will be reduced in 90 days. The new paid quotas do have unpublished limits, so if you need to support more than 500 requests/sec you'll need to contact Google.

Developer will use their Google Checkout account to cover their apps costs. This means that the new features are restricted to the U.S. and U.K. only. Hopefully the Checkout team expands their scope soon. Google Checkout appears to be available almost everywhere, but doesn't have a page that lists all of the countries. You can check the dropdown of the sign-up page to see if your country is supported and thus you can use the Google App Engine features.

This is a significant step for App Engine. By setting a theoretical limit above the dreams of many web apps they are now putting out the call for serious applications. They've already added Google App Engine Apps to Google Apps For Your Domain. I could envision AE becoming the backbone of an Enterprise Dev Marketplace.

AE still has many significant to-do items on their public Roadmap. Not the least of them is the support for more languages (Java is a good bet as it is used a lot internally) and to add support for background processes.

A huge concern with App Engine is platform lock-in. Google provides a lot of powerful, but non-standard APIs and features that make switching platforms difficult. Developers can extract themselves from App Engine via projects like AppDrop, but it is still risky to use their platform without an SLA. Without a guarantee Google could theoretically decide to raise prices unreasonably. Is it likely? No, but it is something that developers need to think about before committing to any platform.

Google I/O already has many sessions listed for App Engine developers. I'll give a free pass to I/O to the person who suggests the best AE app in the comments. Vic Gundotra, who runs the App Engine team, will be at the Web 2.0 Expo SF in April.

Updated: Correct mistakes about the current pageviews and the availability of the new features.

Service Monitoring Dashboards are mandatory for production services!

Google App Engine went down earlier today. GAE is still a developer preview release, and currently lacks a public monitoring dashboard. Unfortunately this means that many people either found out from their app and/or admin consoles being unavailable or from Mike Arrington's post on TechCrunch.

Google has a strong Web Operations culture, and there are numerous internal monitoring tools in use across the company, along with a smaller set available to customers. It's suprising that Google launched a developer platform without providing something beyond an email group, although they are by no means the first to do so.

Service Monitoring Dashboards are mandatory for production services and platforms!

• If you launch a platform that people pay you money for, you need to have a real time service dashboard. Ideally this should be decoupled from the rest of your infrastructure.
• Don't rely on platforms that lack service monitoring dashboards for production.

Many companies are initially reluctant to provide this kind of monitoring to the public, and only do so in reaction to an outage. However, it seems that every company that offers such a dashboard uses it as a source of competitive advantage.

The best example of this is trust.salesforce.com which they launched after series of outages in 2006. Amazon (eventually) launched a status dashboard for AWS, and added RSS feeds for specific services which I think is pretty cool.

Javier Soltero at Hyperic points out

1. The reports of service outages arrive long after anyone who depends on the services can possibly do anything to mitigate their effect.
2. The services themselves seem incapable of providing any visibility into the circumstances that might lead to future outages.

[...]Even TechCrunch points out that the Google Apps blog doesn’t even mention the outage. Other clouds rely on blogs such as this one, this one, or maybe even this one (from our good friends at Mosso). These are all places where outages can be discussed, but not the right means for people to find out whether it their application that crashed, or the cloud that it depends on.

(Updated:Niall Kennedy pointed out that GAE is still a preview release, and I agree that my original wording was wrong. My intent is to emphasize the importance of providing a public service dashboard and so I've edited accordingly.)