Comments 59
наши грабли, спасибо. тоже выбрали GAE, но вот уже подумываем об appscale на AWS — как только выйдем из бесплатных квот, наверное, переметнемся.
А почему вообще думаете о переезде? Вроде как по ценам GAE выглядит лучше — даже если не брать в расчёт бесплатные квоты.
из за ограничений платформы. гугл действует по принципу нипеля (туда дуй, а оттуда — ...)
а нам, как раз оттуда тоже надо бы, чтобы дуло. бесплатные квоты мы перебьем скоро, а по стоимости они идентичны, автор забыл что у AWS есть резервирование (reserved instances), цены там сами посмотрите — aws.amazon.com/ec2/reserved-instances/
а нам, как раз оттуда тоже надо бы, чтобы дуло. бесплатные квоты мы перебьем скоро, а по стоимости они идентичны, автор забыл что у AWS есть резервирование (reserved instances), цены там сами посмотрите — aws.amazon.com/ec2/reserved-instances/
У Гугла они тоже есть. Стоят $9 в месяц, ($0.30 в сутки).
Ограничения — это да. Но тогда вам и AppScale не подходит — или я неправильно понимаю?
Вы странно сравниваете. Аппаратную и софтварную платформу, чуствуете разницу? GAE слишком специфичен.
А смысл? AppScale — исследовательский проект и не особо-то рассчитан на работу в production. Некоторые функции реализованы на базовом уровне, некоторые вообще отстутствуют.
Не лучше ли заточить приложение под App Engine и продолжать использовать на нём? На амазоне сильно дешевле не будет, а головной боли прибавится весьма прилично.
Не лучше ли заточить приложение под App Engine и продолжать использовать на нём? На амазоне сильно дешевле не будет, а головной боли прибавится весьма прилично.
Если у вас есть мысль о том, как можно осуществить аплоад файла размером 20-50 мегабайт с GAE, мы бы были очень признательны. Но пока мы упираемся в таймаут и ничего не можем с этим поделать. Вариант- либо арендовать отдельный сервер, либо менять архитектуру, либо сохранив инстанс на гае, вынести нужный функционал на aws.
Стандартные решения для питона и для явы принимают файлы размером до 2Гб. Чем они не подходят?
AWS это как конструктор на котором собирается все, даже супер компьтер
А AppEngine это именно хостинг приложений с уклонов на масштабируемость так это что сравнение двух непохожих вещей
А AppEngine это именно хостинг приложений с уклонов на масштабируемость так это что сравнение двух непохожих вещей
Да, разные — и в статье даже об этом сказано. Но они вполне могут использоваться для одной и той же цели, и именно в контексте этой цели и проводится сравнение.
да, сравнение некорректно, я бы привел аналогию — сравнение холодного с кислым.
В GAE на сколько я помню, до сих пор нет возможности создавать COMET/LongPooling приложения (или аналоги) а PUSH технология по своей идеологии нагружает хостинг так, что ее бессмысленно использовать.
Но, несомненно, свою нишу GAE уже заняло и благодаря бесплатной квоте и монстра вида google в качестве основы/крыши вполне себя оправдывает.
В GAE на сколько я помню, до сих пор нет возможности создавать COMET/LongPooling приложения (или аналоги) а PUSH технология по своей идеологии нагружает хостинг так, что ее бессмысленно использовать.
Но, несомненно, свою нишу GAE уже заняло и благодаря бесплатной квоте и монстра вида google в качестве основы/крыши вполне себя оправдывает.
А как же Channel API?
Думаю, не очень корректно сравнивать IaaS и PaaS
Старик? Хм… Я на Яве с 96 ого :)
Спасибо за сравнение — увы идеала нет.
Я бы делал на гугле, но persistency layer — выделить, так чтобы при спрыгивании с гугля переписать только его, а API останется тот же
Спасибо за сравнение — увы идеала нет.
Я бы делал на гугле, но persistency layer — выделить, так чтобы при спрыгивании с гугля переписать только его, а API останется тот же
Потребуется выделять на достаточно высоком уровне абстракции, потому что у Google используется не реляционная БД со своими особенностями, что достаточно сильно влияет на логику и даже на архитектуру.
Ну почему же высоком?
Те же сохранение, поиск по каким то критериям и т.д. — все это в API
Те же сохранение, поиск по каким то критериям и т.д. — все это в API
Я очень сильно подозреваю, что модель данных будет отличаться — или будет неоптимальной.
Думаю, что в этом API должны быть классе не зависимые от вида хранения, удобные ослатьному коду бизнес логики.
В крайнем случае, в его имплементации у Вас будет конвертация в другие объекты, подходящие к виду хранения. А эти самые объекты и код конвертации туда-сюда можно генерировать на этапе компиляции. Но это в крайнем случае :)
В крайнем случае, в его имплементации у Вас будет конвертация в другие объекты, подходящие к виду хранения. А эти самые объекты и код конвертации туда-сюда можно генерировать на этапе компиляции. Но это в крайнем случае :)
А я программирую на C, всё, GAE не подходит. Это тоже минус.
В AWS уже тоже есть отправка писем через Amazon Simple Email Service и даже автоматический деплой через AWS Elastic Beanstalk (для Java). Правда пока все это в статусе beta…
А вас не смущают проблемы со стабильностью и перформансом, которые есть у GAE? У меня сложилось впечатление, что GAE только выглядит как silver bullet, а на самом деле весьма сыровата, чтобы ей доверять. Если у кого-то есть опыт хостинга серьезных приложений на GAE, было бы интересно услышать. А то, знаете, этот 1 пункт напрочь убивает нужду сравнивать по других пунктам.
Из минусов для GAE уже можно убрать поддержку реляционных БД — в бете уже реализован SQL Service
Полагаю, что в паблик он выйдет в 1.4.4 версии sdks.
Полагаю, что в паблик он выйдет в 1.4.4 версии sdks.
по ссылке бедный робот не может себя собрать
Вы не поверите, но эта ссылка тоже не работает. Кстати, а какой у вас год? ;-)
PS. Что-то подобное написано здесь — code.google.com/intl/en/appengine/business/, в разделе Hosted SQL, но крайне скупо и без ссылок.
Да, я не подумал, что документация может отдаваться с учетом google.accounts (у меня есть trusted tester account). Извиняюсь
Проще говоря, это обычный sql, который существует как служба в g.APIs; в веб-консоли для апи, вы просто прикрепляете свой AppEngineID к sql-инстансу, далее прозрачно работаете из GAE приложение с sql-базой (для java — через обычный jdbs).
Раз доки закрыты, примеров приводить не буду, хотя там все как для обычного jdbs, за исключением пары строчек для доступа к sql-инстансу.
Проще говоря, это обычный sql, который существует как служба в g.APIs; в веб-консоли для апи, вы просто прикрепляете свой AppEngineID к sql-инстансу, далее прозрачно работаете из GAE приложение с sql-базой (для java — через обычный jdbs).
Раз доки закрыты, примеров приводить не буду, хотя там все как для обычного jdbs, за исключением пары строчек для доступа к sql-инстансу.
У AWS есть Free Tier
Хабр — не личный бложек, %username%.
А что в этой статье вам показалось вопиюще личным?
Отлично сравнение в какой то мере сервисов, служащих одной цели — гибко хостить java приложения.
Отлично сравнение в какой то мере сервисов, служащих одной цели — гибко хостить java приложения.
но кто из них больше мне подойдёт?+ другиеличные требования + 26 «я» + 12 «мне» + стиль изложения.
Так было в оригинальной статье. Не запрещать же теперь перевод подобных статей.
Даже если оставить в стороне то, что это перевод, то я всё равно не понимаю, что плохого в необезличенном стиле изложения. Затрагивается тема, интересная многим? Рассматривается достаточно широко? Ну так и что ещё надо! Что американцы, что европейцы на этот счёт совершенно не комплексуют, у них наоборот считается, что чем больше личного — тем лучше, значит ты пишешь о вещах, которые действительно тебя интересуют.
PS. И спасибо за комплимент, значит не зря старался с переводом, если он воспринимается естественно :-) Хотя всё равно есть несколько мест, которые мне не очень нравятся, но как сказать по другому, чтобы не исказить смысл — не очень понятно.
PS. И спасибо за комплимент, значит не зря старался с переводом, если он воспринимается естественно :-) Хотя всё равно есть несколько мест, которые мне не очень нравятся, но как сказать по другому, чтобы не исказить смысл — не очень понятно.
Да, перевод сделан очень хорошо.
Просто лично я бы перенес его в блог Java, потому что заголовок и содержимое до хабраката не упоминают о Java. *Я например зашел потому что думал что сейчас и про Питон вспомнят :)*
Просто лично я бы перенес его в блог Java, потому что заголовок и содержимое до хабраката не упоминают о Java. *Я например зашел потому что думал что сейчас и про Питон вспомнят :)*
Вот еще какие-то люди вылезли habrahabr.ru/blogs/java/117213/ думаю тоже есть смысл глянуть.
А вы какие проекты делаете? Я просто тоже на java делаю всякие проекты, но одному долго и муторно…
А вы какие проекты делаете? Я просто тоже на java делаю всякие проекты, но одному долго и муторно…
Сравнение цен по CPU/Hr немного неправильное. Малый инстанс на AWS стоит $.085, что все же меньше, чем $0.1 от GAE. Малого инстанса хватает для большинства нужд. Малый инстанс обходится в $80 в месяц. А если купить Reserved Instance за $227, малый инстанс будет стоить $43 в месяц (это полезно делать, когда вы планируете работать с инстансом не меньше года — экономия присутствует).
Также не учтен лимит RAM (которого на GAE пока нет, но в будущем обещают).
Учитывая то, что на Java не программирую, как-то сразу пришлось переходить на AWS. Начать сложно, да. Потом выявляется еще много разных интересных нюансов.
Например:
— IP-адреса амазоновских машин в серых списках спам-листов, так что без тщательной настройки почтовика письма в половине случаев будут попадать в спам.
— У AWS есть лимит на отправку писем для новых клиентов/машин. Его можно снять (одновременно с изменением реверсной зоны) по запросу к техподдержке.
— Серьезно раздражал принцип машин типа AMI. Хорошо, что появились EBS-машины, которые можно выключать, вместо того, чтобы уничтожать.
Зато у AWS простой файлволл. Как раз на тему «не заставляйте меня думать, я не админ».
Также не учтен лимит RAM (которого на GAE пока нет, но в будущем обещают).
Учитывая то, что на Java не программирую, как-то сразу пришлось переходить на AWS. Начать сложно, да. Потом выявляется еще много разных интересных нюансов.
Например:
— IP-адреса амазоновских машин в серых списках спам-листов, так что без тщательной настройки почтовика письма в половине случаев будут попадать в спам.
— У AWS есть лимит на отправку писем для новых клиентов/машин. Его можно снять (одновременно с изменением реверсной зоны) по запросу к техподдержке.
— Серьезно раздражал принцип машин типа AMI. Хорошо, что появились EBS-машины, которые можно выключать, вместо того, чтобы уничтожать.
Зато у AWS простой файлволл. Как раз на тему «не заставляйте меня думать, я не админ».
спасибо. учтем-с…
Сравнение цен по CPU/Hr немного неправильное. Малый инстанс на AWS стоит $.085, что все же меньше, чем $0.1 от GAE. Малого инстанса хватает для большинства нужд. Малый инстанс обходится в $80 в месяц. А если купить Reserved Instance за $227, малый инстанс будет стоить $43 в месяц (это полезно делать, когда вы планируете работать с инстансом не меньше года — экономия присутствует).
Разве корректно сравнивать время работы виртуальной машины с процессорным временем?
Один computing unit примерно равен процессору 1.2ГГц, один час CPU в app engine также считается от этого ориентира. То есть, малый инстанс при 100% нагрузке за сутки выдаёт эквивалент 24-х часов процессорного времени app engine и потребляет $2,04. С учётом 6,5 бесплатных часов гугл за такой же объём вычислений возьмёт $1,75.
А если учесть то, что онлайн-сервисы работают на оборудовании с загрузкой много ниже 100%, то гугловские вычислительные мощности получаются существенно дешевле. Если уж нужен полноценный сервер для большого объёма вычислений за $80/мес, то на мой взгляд, Linode 2048 лучше подходит для таких задач.
Также не учтен лимит RAM (которого на GAE пока нет, но в будущем обещают).
Сейчас есть жёсткий лимит в 200Мб на инстанс, безболезненно же можно потреблять около 60Мб. Не поделитесь ссылкой на обещания?
Обещания пока на уровне комментариев к вопросам. Например, здесь: code.google.com/p/googleappengine/issues/detail?id=1564
Это скорее обещание добавить информации для отладки приложений. Не так давно не показывали даже сколько инстансов запущено, а сейчас можно даже на графике посмотреть и сколько инстансов и сколько памяти они потребляют.
А ограничения были и раньше — надо же было как-то оптимизировать общее потребление и не позволять приложениям с утечками памяти влиять на производительность остальных. Особенность AE в том, что инстанс может взять довольно много памяти для объёмных вычислений. И даже если он возьмёт слишком много, то система даст ему закончить вычисления и остановит только после их завершения.
А ограничения были и раньше — надо же было как-то оптимизировать общее потребление и не позволять приложениям с утечками памяти влиять на производительность остальных. Особенность AE в том, что инстанс может взять довольно много памяти для объёмных вычислений. И даже если он возьмёт слишком много, то система даст ему закончить вычисления и остановит только после их завершения.
По моему, очевидно: Если нужен только веб, то GAE, если что-то большее — aws.
А почему никто не рассматривает гибридные решения?
То, что можно, делаем на GAE, а сложные/невозможные выносим на AWS в виде сервисов например.
Хотя это конечно не на всех проектах возможно.
То, что можно, делаем на GAE, а сложные/невозможные выносим на AWS в виде сервисов например.
Хотя это конечно не на всех проектах возможно.
Мне во всем подошел GAE. Даже полнотекстовый поиск по 100 Мб. текста сделать удалось.
А вот понадобился HTTPS с красивым сертификатом — и приехали. У GAE пока нет такой возможности. Когда будет — не известно. Приходится в спешном порядке все переносить на Amazon BeansTalk.
Разбирался пол дня. Самое сложное было — установить этот самый SSL-сертификат. К серверу по SSH не подключался — нет необходимости.
Главные недостаток Amazon — это их база данных SimpleDB. Google BigTable — намного более продвинутая. Второй недостаток — долго деплоится по сравнению с GAE.
А вот понадобился HTTPS с красивым сертификатом — и приехали. У GAE пока нет такой возможности. Когда будет — не известно. Приходится в спешном порядке все переносить на Amazon BeansTalk.
Разбирался пол дня. Самое сложное было — установить этот самый SSL-сертификат. К серверу по SSH не подключался — нет необходимости.
Главные недостаток Amazon — это их база данных SimpleDB. Google BigTable — намного более продвинутая. Второй недостаток — долго деплоится по сравнению с GAE.
Меня самого постоянно «колбасит» последнее время на тему: как разрабатывать и куда потом деплоить очередной Java проект — на GAE или на AWS.
И каждый раз у меня однозначного ответа нет.
Могу только добавить, что у AWS мне нравится то, что многие (если не все) их сервисы, типа, SimpleDB и т.п. доступны сразу извне.
Т.е. чтобы использовать SimpleDB, например, в качестве кэша данных, как я делаю для одного своего web проекта, мне не нужно иметь никакой самописный «proxy» на их стороне.
Есть клиентские библиотеки для разных языков.
И я напрямую с моего сайта делаю туда к ним идут обращения.
А вот у GAE такое не прокатит. Чтобы юзать их BigTable — надо писать свою «проксю» и класть к ним, а она уже разруливает мои запросы.
И каждый раз у меня однозначного ответа нет.
Могу только добавить, что у AWS мне нравится то, что многие (если не все) их сервисы, типа, SimpleDB и т.п. доступны сразу извне.
Т.е. чтобы использовать SimpleDB, например, в качестве кэша данных, как я делаю для одного своего web проекта, мне не нужно иметь никакой самописный «proxy» на их стороне.
Есть клиентские библиотеки для разных языков.
И я напрямую с моего сайта делаю туда к ним идут обращения.
А вот у GAE такое не прокатит. Чтобы юзать их BigTable — надо писать свою «проксю» и класть к ним, а она уже разруливает мои запросы.
Существенный минус Amazon — отсутствие адекватного суппорта. Платный вариант суппорта от N-й цифры не рассматриваю всерьез — на старте проекта это не целесообразно.
Не раз приходилось на амазоновском форуме писать, чтобы удалили залипшие EBS или инстансы, и надеяться что его кто-то прочитает из суппорта.
Не раз приходилось на амазоновском форуме писать, чтобы удалили залипшие EBS или инстансы, и надеяться что его кто-то прочитает из суппорта.
Подскажите, пожалуйста, а возможно ли использовать AWS или GAE в качестве виртуального сервера? Другими словами, мне не для хостинга сайтов нужен сервер, а полноценный Windows на виртуальном сервере, к которому я могу подключаться с любого компьютера через удаленный допступ?
Сильно не бейте, но уже не знаю, где спросить.
Сильно не бейте, но уже не знаю, где спросить.
Sign up to leave a comment.
Google App Engine (GAE) против Amazon Web Services (AWS)