Хм. Врядли сервис останется бесплатным, поэтому врядли будет сильно популярным среди простых девелоперов. Будут пользоваться только те, кто готов платить.
Да и поддержку языков я думаю добавят, Amazon не будет сидеть сложа руки...
Да, меня гонит тенденция рынка. Запуская сейчас социальный сервис стоит задуматься, а не использовать ли API вконтакта, как небольшую часть своей системы. Так и google. Да я могу сам поднять couchdb сервер на erlang'е, стелать ставку на развивающуюся strokedb (ruby) или написать свою обертку над mysql используя tcl и c#, но это стоит времени, а его мало. Если нет стандартного решения, на место которого претендует google, то создавая тупой web проект свою долю fun'а можно найти в подобном велосипедостроении, оправдоваясь отсутствием стандарта перед начальством. А кроме fun'а этот велосипед принесет и ценные знания, полученные своей кровью и своим потом.
Нет, я не против этого события, просто мы наблюдаем еще один шаг от ремесла к промышленному производству, когда на вопрос как это работает, можно получить ответ не знаю, это просто работает. Кто-нибудь может рассказать ребенку, как работает сотовая связь или почему аспирин помогает от головы?
Радует.
А наши компьютеры неуклонно стремяться к роли "тонких клиентов".
Зачем нам сервера для приложений и сложных расчетов, зачем нам офисные машины... зачем нам nVidia 890... ну это я поспешил) ?
Думаю времени для воплощения концепта от Phoenix в роли компьютера с браузером в биосе, осталось совсем не много.
не знаю кто вам минус поставил, но видимо вы правы, а я нет. Я думал у них там все более гибко и интересно.
Compute Usage (in Instance Hours consumed):
The number of instances multiplied by the numbers of hours (uptime) in a month. For example, if you have 3 instances running for 24 hours/day and 2 instances running for 5 hours/day, the instances hours will be 3 * 24 * 31 (days) + 2 * 5 * 31 (days) = 2,542 Instance hours
Т.е. самый минимум — Small Instance — это 10 центов за 732 часа. т.е. 75 баксов. Не дешево, вы правы.
При чем здесь "подстраиваться". =)) Все не задумываясь юзают MS Office и подстраиваются под visual basic. А здесь другая ситуация.. Гугл дает стимул для изучения гибкого высокоуровневого языка. К тому же будут доступны и другие языки. :P
Да вы правы. У них application server на питоне написан, я не вдавался в детали. Очень хороший перевод статьи по архитектуре youtube'a можно найти aздесь. Статья, правда, немного старая, но основывается на реальных событиях, по докладу одного из разработчиков (Cuong Do) из core team.
Как-то оно не понятно сколько же это :)? На странице App Engine явно написано: "...bandwidth and CPU for 5 million monthly page views." т.е. бесплатно дают полосу и процессор достаточные для обработки 5 миллионов просмотра страниц в день.
:) Думаю, при трафике выше 5 миллионов просмотров в день, можно на самой рекламе окупать хостинг проекта и ездить на космическом корабле.
На самом деле пока ничего не произошло. Посмотрел немного док
Если убрать воду, то мы видим хостинг, который не ноет что его грузят, и не занимается ограничением ресурсов клиенту, а решает его сам проблему производительности.
Только за решение такой проблемы быдет брать дополнительную плату.
Давно ожидаемое решение. Вот только остальные не могли его осилить технически.
У них есть существенные ограничения: с сетью нельзя напрямую работать, процессы сторонние нельзя запускать.
Сделать OpenID можно, да и пользователей своих, вроде, тоже (придётся правда самому делать модель и всё остальное).
А я скачал их кроссплатформенный SDK (http://code.google.com/appengine/downloa…), попробовал написать Hello World и думаю, что создать сайт без пивязки к Google реально. В их SDK входит все: работа с BigTable, GQL, Developer Server (как в Django) и прочие специфичные вещи. Все юзается как модули Python.
Пробую ставить это на своем хостинге WebFaction.
9 языков - это приманка для работодателя (во всяком случае у меня). Реально же хорошо знать можно 3-4, а остальные поверхностно (трогал, ваял для себя).
Если BigTable - аналог Мемкеша в плане запросов, то сделать шардинг для mysql с такими ограничениями ну уж совсем не проблема. Вынести пару шардов на отдельный VPS не такая уж проблема.
Про цену - у Амазона цены их виртуальных почасовых машинок дороже чем, на аналогочный помесячный VPS, на котором делай что хочешь. Гугл конечно цены слегка уронит, но не думаю что настолько. Хотя плюс наверно есть - цены на VPS возможно тоже упадут.
Фиг знает конечно, но я ненавижу трахаться с тем, с чем можно не трахаться. Например с серверами. Будет у них нормальный апсервер - отлично, глядишь и другие подтянутся.
я тут видео посмотрел наконец с презентацией: именно на это они и напирают - не надо платить админу (или тратить своё время), не надо беспокоится об обслуживании оборудования и разруливании проблем с хостёрами.
"сделать не проблема" vs "не делать вообще" - это две большие разницы.
"не такая уж проблема" vs "вообще не проблема, ибо гугл сделает всё сам" - тоже две большие разницы.
Крмое того я больше верю в надёжность гугла чем в большинство самостоятельных решений.
Там есть другие ограничения и минусы, типа отсутствия какого-либо аналога cron'у, жестоеому ограничению на время выполнения скрипта и прочих радостей таких вот узко специализированных решений... но они же не предлагают там делать тяжеловесные приложения, требующие большой закулисной работы с данными, они предлагают услугу прежде всего для несложных по логике проектов.
ждёмс когда они дадут простым смертным доступ к map_reduce...
...Люди, которые проектировали систему, не были достаточно знакомы с PHP, чтобы реализовать его, или они - фанатики питона (что объясняет первое). Кажется, что у людей, которые используют Python, развивают комплекс превосходства, который делает их неспособными рассмотреть что-нибудь кроме питона...
Отлично начался день =)
посмотрите geting started http://www.youtube.com/swf/l.swf?video_id=bfgO-LXGpTM&rel=1
там сотрудник гугла юзает темплейты джанго(!) =)
Отсюда:
In addition to the Python standard library and the App Engine libraries, the runtime environment includes the following third-party libraries:
* Django 0.96.1
угу, там темплейтный движок джанговский в комплекте. И вообще, по идее джанго-приложение, если оно написано грамотно, можно сравнительно легко запустить на гугле. Корёжить по большому счету придется только работу с файлами и БД. Если оно хорошо абстрагировано, то больших проблем не будет.
имхо. Все кому не лень и есть определенный скилл пойдут писать веб приложения у них на сервисе. Как никак есть потенциальная возможность продать это приложение гуглу.
Unfortunately, space is limited during Google App Engine's preview release. As we expand, we'll invite more developers, but for now you'll have to wait.
Would you like to be notified by email when space becomes available?
Since App Engine does not support Django models, leave all DATABASE_* settings set to an empty string. The authentication and admin middleware and apps should be disabled since they require Django models. The functionality these provide is covered by the App Engine Users API and Admin Console respectively. Sessions also depend on Django models and must be disabled as well. Finally, you need to set the path to your template directory dynamically.
кстати, одному мне кажется, что зря они сделали такой низкий порог вхождения? Идеальная документация + довольно понятный python + вся лишняя работа делается гуглом... Не ломанутся-ли сейчас толпы юных и бестолковых разработчиков в сторону питона и гугла и не дескредитирует ли это язык и сервис в глазах масс, как сиё случилось в своё время с PHP по аналогичным причинам.
Google запустил Google App Engine