Google App Engine

Погоняв Google App Engine пару месяцев расскажу о впечатлениях от него.
Платформа несомненно интересная, и будет очень полезна startup'ам, т.к. позволяет сосредоточится на решении своих конкретных задач, отдав все что не является конкурентым преимущество на откуп платформе и её сервисам.

К сожалению прям вот взять любой сайт и запустить его на 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 и боевой сервер иногда по разному себя ведут на одном и том же коде, так что это проблема. Спасает лишь то что одновременно могут быть задеплоены несколько версий, одну видят обычные пользователи, вторую вы можете самостоятельно протестировать, не показывая пока не убедитесь что все работает.
  • http:// Эдуард

    Почему нельзя посмотреть логи? Есть же интерфейс для этого. А вот про домены ,я не знал. Огорчает.

  • http://artamonov.ru splix

    Есть лог запросов, но при поиске причин возникшей ошибки этого не достаточно 🙁

    Я наверное не так написал, нужен стектрейс, место куда приложение может скидывать отладочные сообщения и дампы при ошибке. Обычно это файл настроенный в log4j, а вот как тут сделать я не знаю, похоже писать в БД.

  • http:// Андрей

    Спасибо за заметку.

    Поясните, пожалуйста, минус по поводу поиска — не понял о каком идёт речь (но явно не о Большом поисковике — ведь ему никто не мешает искать снаружи).

  • http://artamonov.ru splix

    Речь о поиске по сайту, локальном. Который организуют через Lucene, Sphinx и пр.

    Я думал что в случае гугла можно будет использовать его, оказалось что нет, все равно на отдельном сервере нужно разворачивать Lucene и подключать к сайту.

  • http:// xeye

    Самое главное ограничение там — нереляционная база данных, в итоге, не важно, работаешь ты с ней напрямую или через JDO/JPA — всё равно ты сильно ограничен по сравнению с нормальным SQL серваком. Есть очень узкий круг задач, для которых именно гуглевая key-value база рулит.

    Еще жаль, что там нельзя картинки обрабатывать 🙁 java.awt отсутствует

  • http:// Pavel Drobushevich

    Здравствуйте,

    Спасибо за заметку.

    Я только присматриваюсь к этому сервису, и тестил на их домене, но в самом начале видел вот такую доку в фоицальном хелпе

    How do I use Google App Engine with Google Apps

    Там рассказывается как прикрутить домен второго уровня к енжину через аппсы.

    Сам ещё не пробовал, но очень надеялся, что это действительно возможно, но Вы пишете:

    > хостит только поддомен, т.е. домен второго уровня прицепить не получится

    не могли бы Вы всё таки больше пояснить этот момент.

  • http:// Pavel Drobushevich

    > xeye

    > Еще жаль, что там нельзя картинки обрабатывать java.awt отсутствует

    Ну у них есть собственный костыль для работы с изображениями.

  • http://artamonov.ru splix

    @Pavel Drobushevich

    Да свой домен можно привязать (к Google Apps), но далее нужно указать на какой поддомен к нему прикрутить само приложение. Т.е. приложение уже хоть как получается на третьем уровне (если свой домен второго уровня).

  • http:// ishe

    и еще нет бэкапа

  • http:// Alex Ryabov

    Отладочные логи тоже есть: все debug/info/warn/error-сообщения складываются в лог запросов, что логично — так как обратиться к коду на App Engine можно только HTTP-запросом, то все сообщения в логе привязаны к своим запросам.

  • http:// xeye

    Pavel Drobushevich сказал:

    января 29, 2010 в 22:06

    >> Еще жаль, что там нельзя картинки обрабатывать java.awt отсутствует

    >Ну у них есть собственный костыль для работы с >изображениями.

    угу. обрезок жалкий 🙂 например, мне нужно сделать простейшее наложение пары изображений и вывести картинку в поток — уже не умеет.

  • http://artamonov.ru splix

    @Alex Ryabov

    я вот тоже подумал было про эти логи, было бы удобно, но не понял пока как туда складывать. надо будет внимательней покопаться.

    @xeye

    а не встречал никакой библиотеки, для генерации изображений, работающей напрямую с бинарными данными, без всяких awt и пр.?

  • http:// xeye

    2splix: неа, как ни странно до сих пор никто не осилил такое написать. есть только некоторые узкие, ограниченные реализации для работы со специфическими графическими форматами, но они все на awt так или иначе завязаны. отдельные куски того, что нужно можно найти по разным либам, типа pdf/svg генераторов, но цельного решения не нашел

  • http:// Pavel Drobushevich

    @splix

    > Да свой домен можно привязать (к Google Apps), но далее нужно указать на какой поддомен к нему прикрутить само приложение. Т.е. приложение уже хоть как получается на третьем уровне (если свой домен второго уровня).

    Месяц назад привязывал. Вообщем почитал рекомендации гугла на эту тему, всё очень просто, в качестве домена третьего уровня указывается www. А у dns провайдера настраивается dns redirect с example.com на www.example.com.

  • http:// foror

    Думаю вот такая штука много интересней AppEngine selectel.ru/cloud/ — 10 руб. на счету, а ресурсы масштабируются в зависимости от нагрузки и платите в зависимости от нагрузки.

    Возможен рост до 48Гб памяти и что-то до 8 ядерных ксеонов... Думаю это вполне хватит, для начинающего стартапа 🙂

    P.S. На Java говорят проблемы, я еще не проверял. Видимо связано с тем, что нужно задавать -Xmx по памяти...

  • http:// splix

    Да, таких полно, тогда уж брать Linode или EC2. Если совсем близко то Оверсан-Скалакси. То что апгрейдится «без остановки виртуальной машины» это на практике не имеет смысла, т.к. БД, JVM и прочие приложения нужно все равно перезапускать с новыми настройками. Плюс это лишь вертикально масштабирование.

    Тут кардинально иной подход, облако как PaaS, которое заставляет писать горизонтально масшабируемое приложение.