Google Apps Engine: все еще слишком экспериментальный

Недавно пришлось таки отказаться от GAE по ряду  причин. Все-таки не стоило насколько легко игнорировать все предупреждения о том, что он имеет пока только экспериментальную поддержку.

Основные причины отказа:

1. Достаточно низкие лимиты на процессорное время, при этом довольно низкая производительность (то что на локальной машине выполняется 1секунду, в “реальном” окружении может выходить за пределы лимита в 30 секунд)
2. Наличие серьезных открытых issues, которые фактически сильно усложняют разработку
   1. Невозможно очистить хранилище (только кодом, но если классы не совместимы, то полная очистка невозможно вообще)
   2. Невозможно удалить приложение (что в совокупности с предидущим пунктом и наличием лимита в 10 приложений дает серьёзную “ложку дёгтя”)
   3. Ошибки при построении индексов и невозможность управлять ими при ошибках (например, если индекс находится в состоянии построения, и возникла ошибка, только работники Гугл могут помочь очистить индексы)
3. Позднее оповещение об неподдерживаемых библиотеках (фактически можно довольно долго разрабатывать локально, задеплоить, и только при какой-то операции получить сообщение что какая-то библиотека юзает “запрещенный” класс, что заставляет фактически полностью переписывать некоторые блоки). Мне кажется, что зная список разрешенных JRE классов, могли бы написать небольшой анализатор, который скажет есть ли использование плохих классов).
4. Отсутствие  агрегационных функций при работе с хранилищем. Конечно, это не проблема для некоторых проектов, но в том, над которым я работал, анализ данных был чуть ли не основной задачей. И если у Амазона есть их Amazon Elastic MapReduce, то у Google нет адекватной альтернативы.

Сейчас прорабатываем вариант перехода на Amazon Web Services. Пока выглядит очень и очень привлекательно.

P.S.: Небольшая анти-статья про Amazon SimpleDB и чуток GAE - тут