Jarosław Zabiełło - BLOG: Google App Engine

Google App Engine

Jarosław Zabiełło — Sun, 13 Apr 2008 21:12:00 +0200

Od niedawna Google oferuje dosyć atrakcyjną możliwość pisania aplikacji webowych wykorzystujących potęgę ich infrastruktury – Google App Engine. Usługa jest darmowa i jeszcze testowa. Można stworzyć do 3 aplikacji z których każda może używać do 500MB danych trzymanych w BigTable i Google obiecuje że bez problemu będzie można uzyskać do 5 mln odsłon miesięcznie i niezły traffic 10 TB/m-c.

W tej chwili jedynym językiem dostępnym jest Python ale mają przybyć kolejne. Wykorzystywany jest WSGI. Dostępny jest też okrojony framework Django (nie można używać djangowego ORM’a ani wszystkich możliwości jakie dają djangowe szablony).

To co się bardzo zmienia, to podejście do bazy danych. Baza kolumnowa BigTable nie jest bazą relacyjną (nie istnieje tam pojęcie joinów). Trzeba więc trochę inaczej przemyśleć sposób tworzenia swoich danych. Pewnym problemem może być nie tylko uzależnienie od infrastruktury Google ale też trudność z późniejszym przeniesienia tak składowanych danych na inną platformę (choć istnieje z drugiej strony open-source’owy odpowiednik BigTable – HBase). W zamian jednak użycie platformy Google daje bardzo wysoką wydajność i odporność na błędy (jak padnie jeden serwer to jego pracę przejmuje automatycznie inny). Trochę nie jest dla mnie jeszcze jasne jak składować i usuwać dane z plikami statycznymi (obrazki, style kaskadowe, flash itp) skoro Google nie daje dostępu do systemu plików. Zablokowane są też sockety, wątki, używanie modułów napisanych w C, możliwość odpalania podprocesów, możliwości używania innych baz niż BigTable.

" Google App Engine" by Maxximilian

Sat, 24 May 2008 15:46:29 +0200

Join to komenda, która przy dużych tabelach zajeżdża mysql – może w tym właśni braku relatywności bigtable tkwi przepustowość googla

" Google App Engine" by Jarosław Zabiełło

Sat, 19 Apr 2008 06:48:49 +0200

Fajnie, że Pylons też może działać w App Engine.

" Google App Engine" by smok

Thu, 17 Apr 2008 09:49:15 +0200

Brakuje procesów cron-owych. Trzeba by to symulować z zewnątrz… Jak dla mnie stopper.

" Google App Engine" by BlueMan

Thu, 17 Apr 2008 08:52:30 +0200

Nie umieściłbym tam strony,kiedy nie mam możliwości migracji i przeniesienia na inny serwer

" Google App Engine" by Maniek

Mon, 14 Apr 2008 19:35:48 +0200

Czyzby konkurencja? http://aws.typepad.com/aws/2008/04/block-to-the-fu.html

" Google App Engine" by Maniek

Mon, 14 Apr 2008 19:06:11 +0200

Jestem ciekaw jaka jest licencja. Zeby sie potem nie okazalo, ze Google ma jakies prawa do nie swojej aplikacji. Jesli chodzi o niezawodnosc to w erlangu mechnizmy przenoszenia danych na inny serwer itp. sa praktycznie wbudowane w biblioteke standardowa. Hosting Google jest moze i dobry ale dla nie komercyjnych projektow.

" Google App Engine" by Michał Chruszcz

Sun, 13 Apr 2008 23:48:38 +0200

Ta wiadomość wzbudza we mnie nad wyraz ambiwalentne odczucia – z jednej strony pociągające wydaje się korzystanie z tych samych zasobów, na których działają serwisy Google’a, lecz specyfika tego środowiska sprawia, że praktycznie nie istnieje możliwość późniejszego przeniesienia się do innego dostawcy. Sądzę, że firmy nie zdecydują się na prowadzenie strategicznych projektów na tej platformie, gdyż oznaczałoby to pełne zdanie się na Google’a – zarówno pod względem jakości oferowanych usług, co bardzo im plusuje, jak i cen, które mogą przecież dowolnie się zmieniać.

" Google App Engine" by fredd4

Sun, 13 Apr 2008 23:37:18 +0200

Wszelakie pliki statyczne wysyłasz za pomocą dostarczonego przez googla skryptu. Z poziomu działającej aplikacji nie możesz nic modyfikować w systemie plików, ale takie rzeczy jak zdjęcia po prostu wrzucasz do bazy danych. Jest to rozwiązanie zalecane i nawet wygodne.

" Google App Engine" by coldpeer

Sun, 13 Apr 2008 22:27:25 +0200

“ani wszystkich możliwości jakie dają djangowe szablony).”

Hmm? Przecież szablony Django zostały, nawet Google ich używa w swoim mini frameworku webapp.

Natomiast nie ma djangowych modeli, panelu admina.