Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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
А что в этой статье вам показалось вопиюще личным?
Отлично сравнение в какой то мере сервисов, служащих одной цели — гибко хостить java приложения.
Отлично сравнение в какой то мере сервисов, служащих одной цели — гибко хостить java приложения.
Так было в оригинальной статье. Не запрещать же теперь перевод подобных статей.
Даже если оставить в стороне то, что это перевод, то я всё равно не понимаю, что плохого в необезличенном стиле изложения. Затрагивается тема, интересная многим? Рассматривается достаточно широко? Ну так и что ещё надо! Что американцы, что европейцы на этот счёт совершенно не комплексуют, у них наоборот считается, что чем больше личного — тем лучше, значит ты пишешь о вещах, которые действительно тебя интересуют.
PS. И спасибо за комплимент, значит не зря старался с переводом, если он воспринимается естественно :-) Хотя всё равно есть несколько мест, которые мне не очень нравятся, но как сказать по другому, чтобы не исказить смысл — не очень понятно.
PS. И спасибо за комплимент, значит не зря старался с переводом, если он воспринимается естественно :-) Хотя всё равно есть несколько мест, которые мне не очень нравятся, но как сказать по другому, чтобы не исказить смысл — не очень понятно.
Вот еще какие-то люди вылезли 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 на виртуальном сервере, к которому я могу подключаться с любого компьютера через удаленный допступ?
Сильно не бейте, но уже не знаю, где спросить.
Сильно не бейте, но уже не знаю, где спросить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google App Engine (GAE) против Amazon Web Services (AWS)