Google App Engine

pitrik2

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.

Google App Engine lets you run your web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users.
You can serve your app using a free domain name on the appspot.com domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.
App Engine costs nothing to get started. Sign up for a free account, and you can develop and publish your application for the world to see, at no charge and with no obligation. A free account can use up to 500MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month.
During the preview release of Google App Engine, only free accounts are available. In the near ure, you will be able to purchase additional computing resources.

psihodog

6yrop

о, круто! питон!

Helga87

о, круто! питон!
гугл просто решил раскрутить название "Google App Engine"

amiantos

Dasar

Т.е. в один прекрасный момент гугловская халява может кончится , так что ли получается?... А те фирмы, которые сидят на них будут вынуждены платить деньги, поскольку будет сложно отказаться от использования, т.е. весь бизнес завязан на этом... (я не говорю про почту, я говорю о тех же документах, календарях или "хостинге")

amiantos

Dasar

amiantos

uncle17

или всё-таки платить, например, микрософту за какой-нить Эксченждь и "быть уверенным" в его "надёжности"

pitrik2

Т.е. в один прекрасный момент гугловская халява может кончится , так что ли получается?... А те фирмы, которые сидят на них будут вынуждены платить деньги, поскольку будет сложно отказаться от использования, т.е. весь бизнес завязан на этом...

например, микрософту за какой-нить Эксченждь и "быть уверенным" в его "надёжности"?.......

Dasar

если вдруг ща майкрософт поднимет цены на какой-нибудь эксчейндж раз эдак в 10 или 100?

что гугл может испортиться или вообще изчезнуть однажды, что майкрософт может также исчезнут

shlyumper

Hastya

shlyumper

pilot

pilot

Google App Engine
10.04.08 02:57, категории: Django, Python
Позвольте присоединиться ко всеобщему шуму про Google App Engine со слегка упорядоченным дампом своих мыслей последней пары дней.
Хорошо!
    *
     Питон, Питон, Питон. Само по себе то, что Google сделал массовый специализированный хостинг приложений именно с этим языком — это увесистый такой аргумент для бюрократов, которые не очень любят разбираться в деталях и брать на себя ответственность. Надеюсь теперь начинающим питонистам будет гораздо проще объяснять боссам, почему они пишут на этом “неизвестном” языке.
    *
     Хостинг WSGI-приложений — это очень нужная вещь в принципе. Не обязательно в том виде, в котором это сделано на GAE. Главное, что они, кажется, угадали с тем, что многим питонистам на хостинге не нужна тупая файловая система, где придется вручную писать запускающие скрипты. А нужна просто некая дырка, куда можно скормить свой хендлер. А с путями и прочей инфраструктурой пусть разбирается хостинг сам. Теперь уже как-то даже и странно, что так не делают все…
    *
     Такой реверанс в сторону Джанго — с явной поддержкой, копированием архитектурных решений в БД-библиотеке, использованием шаблонного движка — очень приятен. Хотя не думаю, что это сильно скажется на самом фреймворке. Мне это видится скорее признанием очевидного (sorry, guys!)
    *
     Хороший шанс поработать вживую с BigTable. Я, как давний непоклонник реляционных БД, очень рад, если многие разработчики перестанут автоматически думать про хранение данных в терминах реляционной алгебры и начнут смотреть в другие стороны.
Не особенно хорошо.
    *
     Питонья среда урезана практически до неюзабельности. Повспоминав короткое время, я понял, что практически ни один из моих проектов не смог бы работать на GAE. Где-то PIL был нужен — так оказывается нельзя библиотеки с сишным кодом использовать. В музыкальном сервисе кастомный HTTP-сервер на сокетах тоже реализовать было бы нельзя, потому что нельзя пользоваться собственно сокетами. Форум Cicero — в пролете из-за поиска Sphinx’ом, который хранит индексы в виде файлов… В общем, пока эта среда выглядит пригодной для простеньких чисто HTML’ных и javascript’овых mash-up’ов.
     Впрочем, мне думается, что вот здесь-то большинство зияющих проблем починят. Просто будут со временем добавлять собственные “стерилизованные” для работы в ограниченной среде аналоги стандартных модулей. Сейчас о степени убогости судить, конечно, рано. Потому как это вообще-то бета :-).
    *
     Невозможно отлаживаться на сервере. Чем нетривиальней приложение, тем больше вероятность, что разница между средой на машине разработчика и на сервере начнет как-то сказываться. И тогда захочется влезть на сервер shell’ом, чтобы контроллировать процесс. Пока GAE предлагает только пакетную обработку: закачал, запустил, почитал лог.
    *
     “Вы можете использовать Джанго” — это, мягко говоря, преувличение. Даже если отвлечься от того, что вы не можете использовать половину самого Питона, то и с Джанго тоже полно проблем:
     o
     Отсутствие ORM’а замечают все. И тут же очевидную невозможность использовать админку, авторизацию и много другого contrib’а. А заодно и большу́ю часть сторонних приложений, которые под Джанго пишутся в расчете на то, что там будет родной ORM.
     Эта ситуация, кстати, хорошо иллюстрирует, почему джанговская интегрированность, на которую любят безоглядно ругаться, на самом деле хорошая штука. Не будь ее — у нас бы был вот такой висящий в воздухе фреймворк, как GAE’шный Джанго, под который ничего нельзя надежно написать.
     o
     Из-за отсутствия ORM разработчикам GAE пришлось написать свой портированный вариант newforms. В итоге получается форк, который не будет развиваться за Джанго, и соответственно, еще больше удалять “Django-GAE” от “just Django”.
Пугающе…
    *
     Здравствуй, здравствуй, старый “добрый” vendor lock-in. Пока что по всему выходит, что Гугл хочет, чтобы разработчики разрабатывали приложения не для себя, а для него:
     o проприетарная среда не допускает легко переноса приложений на другие платформы, равно как и портирование существующих приложений к себе
     o вы “легко и непринужденно” можете использовать базу пользователей Гугла, а не свою
     o легкий порог входа привлекает начинающих программистов, что создает у них неосознанный громадный кредит доверия к “доброй маме” Гуглу, что бы тот в последствие ни делал
     Меня это все пугало и раньше, когда вендор назывался на “M”, а платформа на “W”, пугает и сейчас. Закрытая платформа — плохо.
     Еще точно и кратко про это у Тима Брея: Sharecropper Alert
“А я не поехал…”
Ну а мне приятно осознавать, что мне туда, в общем-то, и не зачем. Заведя когда-то собственный домен, я не понимал, зачем мне почта GMail, если у меня есть свой красивый адрес, IMAP и больше места, чем я смогу занять. Так же меня не впечатлил и Google Code, потому что subversion-сервер у меня тоже свой. Так же я пока буду свысока смотреть на GAE, потому что проблем с разворачиванием питоньего кода на softwaremaniacs.org у меня никаких нет. Ни в сложности, ни в деньгах.
Но понаблюдать за тем, во что вся эта идея превратится, конечно, интересно.
Оставьте комментарий или TrackBack с вашего сайта.
 

shlyumper

pilot

AWS vs Google App Engine
I was recently invited to a Google Campfire meet, but unfortunately it’s a long commute from Beijing, so I had to read about their big announcement on a bajillion blogs: Google is now in the application hosting market.
I’m guessing this is related to their purchase of Jotspot a while back, but it’s definitely something I’ve hoped for – as someone who is building an application on the AWS stack, I want to see competition in application hosting.
To be succinct, based on where the Google App Engine is today, I would say AWS still has a strong lead in application hosting, and I would not currently consider writing an application for Google’s current platform.
Sure the AWS stack has a lot of problems, but the core 2 services: S3 and EC2 are time tested and very solid offerings. They don’t always hold your hand, but if you work around some quirks in the system you can get whatever you want done.
Google App Engine as it currently stands has several flaws:
Lockin – you are locked in to their platform. If you build an app on Google, you better be sure what works for you today will work even if your circumstances change, or if Google changes their mind about the profit opportunities in web-hosting.
The page-view limitation is quite low – millions of pageviews come quicker than you think.
I didn’t see memcache on offer – that might be an oversight but I have learned my lesson and will not build another production website without memcache ever again.
No long running pages, or cron jobs – remember even if you don’t need this today, you might tomorrow. Almost all of the web apps i’ve ever written require long running processes or cron jobs of some kind.
Storage size limitation – you never know how popular your site will be. It’s a tragedy when you write yourself into a scalability corner, they don’t offer you very much space.
One language – 1 language does not fit all purposes. I’m hoping they increase the number of languages, I’ve looked at Python and see no compelling reason to switch from PHP 5, although I think both languages are good very choices for web development.
To use your own domain you must use Google Apps
No requests unless they are through Google’s API. This means you can’t do things like host another type of server, or even fetch a remote webpage running on a nonstandard port. You can also not fetch remote webpages that are behind redirects. Also any library you have that includes http fetching technology, such as an RSS library or something, will break and need patching.
That being said: it’s free. To developers, free looks pretty rocking, and I’m sure that many apps will be written on this platform.
Also, it integrates with Google accounts – a very nice feature, it would be nice of Amazon to do the same, particularly when it comes to payment processing.
I would also prefer Google Bigtable to Amazon Simpledb – which currently cannot sort results, although you can get more than 1000 results for a query. GQL also beats simpledb by supporting paging, numbers, and no apparent limitations like 255 values for a row. You can also get back rows from a query, instead of being forced to issue new requests for each row.
The email service also seems like it might be nice, I’ve heard that emails sent from EC2 servers are often marked as spam – I’m hopeful that filters would be kinder to Google ip sent emails, although they might have the same problem.
One thing both Amazon and Google could do to really show they are serious about their platforms is open up their data engines, which are really the core of most web applications – open source bigtable and simpledb. This would really reduce lockin and make development easier, and it might even lead to some help improving their services.

Helga87

karkar

vall

Helga87

vall

Какие технологии Sun ты имеешь ввиду?

Helga87

pitrik2

почти

organziation

Helga87

Lockin – you are locked in to their platform. If you build an app on Google, you better be sure what works for you today will work even if your circumstances change, or if Google changes their mind about the profit opportunities in web-hosting.

Host your App Engine applications on my new site, AppDrop.com, it's lotsa fun, and pretty much works. I didn't build it to scale, or for extra security - but it is open source, so if you are up for it, there are links to the GitHub projects from the App Drop homepage. It should be relatively straightforward to build your own App Engine host.

shlyumper

I really don't understand what was proven here. Thousands of developers ran the SDK on their desktops. Now we prove that the same SDK can run on Amazon. Was that ever in question?
If you have to rewrite substantial parts of your app to leave then that's "lock in".