Обратная связь на доступности с Google App Engine

Вы правы: вы не так сильно контролируете, как традиционный хостинг. Тем не менее, мы надеемся, что прибыль перевешивает недостатки. App Engine чрезвычайно масштабируем - он работает на том же оборудовании, что и сам Google. Как часто вы посещали http://google.com , и эта страница или результат поиска не отображались?

Несмотря на то, что вы разрешаете Google запускать свой код, код все равно остается за вами. . С новыми проектами, такими как django-nonrel , вы можете создавать и запускать собственные приложения Django непосредственно поверх App Engine, и, если они не соответствуют вашим потребностям в дальнейшем, довольно легко перенести это приложение на Интернет-провайдер, который размещает приложения Django (а их много). Подробнее об этом проекте ниже.

Вам не нужно беспокоиться об оборудовании, операционных системах, создании образа машины, базах данных, веб-серверах, интерфейсных балансировщиках нагрузки, сетях CDN / пограничном кэшировании, обновлении программного обеспечения / пакетов, лицензионных сборах и т. Д. эти вещи имеют непосредственное отношение к сети или другому приложению, которое у вас есть или которое вы создадите для решения конкретной проблемы. Вся эта дополнительная инфраструктура требуется , нравится вам это или нет; но с App Engine вам нужно думать только о своем приложении / решении и ничего из этого лишнего.

Очевидно, еще одна вещь, которую вы теряете, - это некоторая часть среды выполнения. Чтобы убедиться, что вы хорошо играете со своими соседями по облаку (перегрузка ресурсов, проблемы с безопасностью и т. Д.), Вы должны выполнять в песочнице, то есть ваше приложение не может создавать локальные файлы, открывать сетевые сокеты и т. Д. Однако App Engine предоставляет богатый набор API и функций продукта, так что вы, по крайней мере, можете создавать значимые приложения:

• масштабируемое хранилище данных распределенных объектов (см. ниже)
• Memcache
• URLFetch
• сервис изображений (изменение размера, обрезка и т. д.)
• очереди задач обслуживания / аутентификации пользователей для фоновой обработки
• Веб-шаблоны Django
• хранилище больших двоичных объектов для больших файлов
• черный список отказов в обслуживании
• трансляционные задачи
• курсоры хранилища данных
• отправка (и / или получение) электронной почты
• отправка (и / или получение) чата / мгновенных сообщений / мгновенных сообщений через XMPP

. У вас также есть полная консоль администрирования с панелью управления, которая позволит вам отслеживать использование вашего приложения, ваши настройки выставления счетов и историю, полный дамп использования вашей квоты и даже журналы приложений, которые вы можете просмотреть или скачать.

Чтобы обратиться к «основным болевым точкам» @Anurag:

1a. бесплатные квоты довольно щедры ... их достаточно, чтобы обеспечить работу веб-сайта, который получает 5 миллионов просмотров в месяц. Кроме того, если вы доверяете Google предоставить им вашу кредитную карту, они увеличат уровень бесплатных квот даже на выше . посмотрите на их страницу квот и обратитесь к номерам в столбцах «Бесплатная квота по умолчанию» и «Квота по умолчанию с включенным биллингом» ... вот несколько примеров: a) Количество запросов: 1.3MM по умолчанию, 43MM с включенным биллингом (wBE), b) Вызовы Datastore API: 10MM по умолчанию, 140MM wBE, c) Выборка URL: 657K по умолчанию, 46MM wBE

1b. Максимум 30 секунд для запросов: это больше для вас безопасности, потому что ваше приложение теперь находится на игровой площадке с другими. Google должен гарантировать, что все соседи по облаку хорошо взаимодействуют друг с другом и не загружают процессор. Однако команда App Engine работает над тем, чтобы разрешить более длительное выполнение фоновых задач ... расписания пока нет, но оно включено в общедоступную дорожную карту .

1с. написать чат-сервер на App Engine не только возможно, но и довольно просто. вот один, созданный с использованием XMPP API App Engine - он довольно глупый и просто возвращает отправителю то, что он нам передал (имейте в виду, что вы, должно быть, уже пригласили пользователя в чат):

from google.appengine.api import xmpp
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

class XMPPHandler(webapp.RequestHandler):
    def post(self):
        msg = xmpp.Message(self.request.POST)
        msg.reply("I got your msg: '%s'" % msg.body)

application = webapp.WSGIApplication([
    ('/_ah/xmpp/message/chat/', XMPPHandler),
], debug=True)

def main():
    run_wsgi_app(application)

if __name__ == '__main__':
    main()

1d . еще один пункт в общедоступной дорожной карте - это будущая «[поддержка] коммуникации Browser Push (Comet)», так что это тоже будет.

2а. «не SQL» - одна из самых сильных сторон Google App Engine! реляционные базы данных не масштабируются и в какой-то момент должны быть сегментированы, чтобы реляционная СУБД не вышла из строя. это верно , но это немного сложнее перенести, потому что это нетрадиционно! На основе Google Bigtable хранилище данных App Engine можно рассматривать как масштабируемую базу данных распределенных объектов. App Engine позволяет запрашивать хранилище данных, используя модель объекта запроса , или, если вы настаиваете, они также предоставляют SQL-подобный интерфейс GqlQuery .

2b.с новыми авангардными проектами, такими как django-nonrel , если вы создаете приложение Django и используете его ORM, вы можете взять чистое приложение Django и запустить его непосредственно поверх App Engine. так же,вы можете отключить его от App Engine и перенести непосредственно к более традиционному поставщику услуг Интернета, у которого размещены приложения Django. запросы остаются неизменными, и вам не нужно заботиться о том, выполняет он SQL или нет.

3а. длительные процессы уже рассматриваются в 1b выше. Google осознает эту потребность и работает над этим.

3b. TaskQueue API поддерживает 100 тыс. вызовов, но теперь их количество увеличено до 1MM wBE ... и это происходит ежедневно.

3с. Google настоятельно рекомендует разбивать задачи на несколько подзадач. Считается, что приложения с малой задержкой не «перегружают систему» ​​и обрабатываются лучше, чем те, которые работают медленно и потребляют больше ресурсов у своих соседей по облаку.