Google App Engine

Opublikowane przez Jarosław Zabiełło Sun, 13 Apr 2008 19:12:00 GMT

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.

Tagi , ,  | 10 comments

Comments

  1. Avatar coldpeer powiedział about 1 hour later:

    “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.

  2. Avatar fredd4 powiedział about 2 hours later:

    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.

  3. Avatar Michał Chruszcz powiedział about 3 hours later:

    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ć.

  4. Avatar Maniek powiedział about 22 hours later:

    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.

  5. Avatar Maniek powiedział about 22 hours later:

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

  6. Avatar BlueMan powiedział 3 days later:

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

  7. Avatar smok powiedział 3 days later:

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

  8. Avatar Jarosław Zabiełło powiedział 5 days later:

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

  9. Avatar Maxximilian powiedział about 1 month later:

    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

  10. Avatar rafu powiedział about 1 year later:

    Maxximilian – Dobrze zrobiony Join nie jest bardziej zajezdzający niz dwa zapytania z osobnych tabel

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz