К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.

Плюсы

• бесплатен для небольшого проекта, и очень подходит для стартапов, с непостоянной посещаемостью. 2-3 тысячи посетителей в день обошлись в 10 центов, на совершенно не оптимизированном сайте. На нормальном должно держать тысяч 5, хотя зависит от структуры сайта, на каком-то сайте и пара сотен упрется в такой предел
• очень масштабируемо, автоматически. Мо;но не боятся слэшдот/дигг/хабра-эффектов, все выдержит.
• готовая обвязка инструментами и сервисами:
• мониторинг текущей загрузки
• версионность приложения (может работать одновременно несколько версий, можно к примеру тестировать новую версию, пока пользователи видят лишь предыдущую)
• готова вся работа с пользователем (через Google Accounts), не нужно заморачиваться с регистрацией, защитой от ботов, сменой и восстановлением пароля и пр. пользовательских данных,проверкой прав и т.д.
• cron, message queue, отправка писем, работа с графикой и web-ом

Минусы

• хостит только поддомен, т.е. домен второго уровня прицепить не получится. поэтому все сайты в виде www.* Причина в том что GAE распределенн по разным датацентрам, и автоматическую балансировку трафика они могут сделать лишь для поддомена. Не известно будут ли они решать эту проблему, это хоть и всем не нравится, но жить с этим вполне можно.
• нет поиска, что для компании, изначально на это делающей ставку, вообще странно. Мне даже в голову не могло придти что у Google не будет поиска, и ничуть не смутило то что не увидел этого в презентациях, ведь это само собой разумеющееся. Но факт: поиска нет.
• нет нормального админского инструмента для работы с БД. Есть некий GQL, но этого не достаточно, он не поможет если вам нужно быстро найти пару «плохих» записей чтобы поправить вручную. Не заработает, например, потому что скорее всего для вашей ситуации (условия выборки) не будет индекса, а без индекса запрос не выполнится. Нормально пролистать, отсортировать и пр. тоже не получится. В общем чтобы полноценно админить БД придется писать код, с нуля, так как стандартная админка Django не работает
• нет полноценной отладки, не посмотреть логи с ошибкой. К тому же SDK и боевой сервер иногда по разному себя ведут на одном и том же коде, так что это проблема. Спасает лишь то что одновременно могут быть задеплоены несколько версий, одну видят обычные пользователи, вторую вы можете самостоятельно протестировать, не показывая пока не убедитесь что все работает.

Кто нибудь занимается datamining, textmining, ir и прочими делами с большими массивами данных? Вот запустил небольшой сервис: datasetpublisher.com – торрент трекер для коллекций данных. Т.е. чтобы не качать очередные 5G дампа википедии со скоростью 70Kb/s (докачается как раз к моменту когда выложат новый дамп), а скачать с нормальной скоростью через торрент.

Только запустил, поэтому там пока пусто, но будем наполнять. Если есть желание и есть что – то выкладывайте. Я, в свою очередь, постараюсь донести об этом сервисе до всех заинтересованных лиц.

Проект запущен на Google App Engine, что собственно и послужило причиной его появления. Уж очень я в последнее время заинтересовался этой платформой, и решил поэксперементировать. А так как я очень не люблю что-то делать «в корзину», и считаю что подобные эксперименты, помимо исследовательской цели, должны принести конкретный применимый сейчас результат. И вспомнил разговор с Иваном Бегтиным, незадолго до этого, о том что неплохо бы иметь подобный ресурс. Теперь он есть. И с GAE разобрался, на него еще посмотрю как вести себя будет, и напишу свое мнение.

PS: на самом деле для ruby, а точнее Ruby on Rails, все это насчёт рекурсии совсем неважно, но иметь ввиду все же надо.

Гдето чтото не так написал, или не сконвертировал из нужной кодировки в другую нужную, и все, и все полетело Вот тут, в Django, например, чтобы заменить регекспом строку на русском, надо делать так:

#-*- coding: cp1251 -*-

import re
instr = unicode(req.POST['param'], 'utf-8')
pat = re.compile(u'этоубрать', re.U)
instr = re.sub(pat, '_', instr)

а при выплевывании на страницу надо так

messages.append(unicode('Наше сообщение', 'cp1251').encode('utf-8'))

А я все то там, то тут пропускаю, то unicode() то encode() не в том месте, а они все поочереди идут, на выходе непонятно что получается Теперь разобрался вроде.