Google komt met hostingomgeving voor webapplicaties

Google heeft tijdens de tweede Campfire One-bijeenkomst zijn AppEngine-dienst geïntroduceerd. Met deze nieuwe service haakt het bedrijf in op de huidige trend van cloud computing, waarbij bedrijven hun serverbeheer kunnen uitbesteden.

Google AppEngine maakt het voor ontwikkelaars mogelijk om een webapplicatie op de servers van Google te draaien. Google biedt een volledig functionerende omgeving voor Python-applicaties. Bovendien krijgt de ontwikkelaar de beschikking over api's die authenticatie voor Google-gebruikeraccounts ondersteunen en e-mailfunctionaliteit bieden.

Het is niet mogelijk om files naar het bestandssysteem te schrijven. Voor opslag van gegevens moet namelijk gebruik worden gemaakt van de Google Datastore, ook wel bekend onder de naam BigTable. Dit is een gedistribueerd opslagsysteem dat veel weg heeft van een database, maar kolomgebaseerd is in plaats van regelgebaseerd zoals de meeste relationele databases. Datastore is geoptimaliseerd voor snelheid en zeer grote hoeveelheden data, waarbij Google's eigen bestandssysteem 'GFS' als onderliggend opslagsysteem wordt gebruikt.

De nieuwe omgeving is in principe gratis te gebruiken. Voorlopig verkeert het platform nog in het bètastadium, waarbij enkele beperkingen van kracht zijn. Zo is het niet mogelijk om meer dan 500MB aan data op te slaan, mogen er per dag maximaal 200 miljoen megacycles aan cpu-tijd worden gebruikt en is de hoeveelheid dataverkeer beperkt tot 10GB per dag. In de toekomst zal het mogelijk zijn om deze limieten tegen betaling te overschrijden. Voorlopig zullen maximaal tienduizend gebruikers een account voor Google AppEngine krijgen.

Met de nieuwe service haakt Google in op de cloud-computingtrend die de laatste jaren in gang is gezet. Ontwikkelaars hoeven zich niet meer druk te maken over het onderhoud en het beheer van servers, omdat hun applicaties draaien op serversystemen van gespecialiseerde bedrijven. Ook vormen variaties in dataverkeer geen probleem meer, omdat er dynamisch extra reken- en opslagcapaciteit aan een specifieke applicatie kan worden toegekend. Onder andere Amazon biedt al enige tijd vergelijkbare diensten. De grotere flexibiliteit die Amazon levert door zijn services afzonderlijk aan te bieden, gaat wel weer ten koste van de integratie van de afzonderlijke onderdelen.

Een van de nadelen op dit moment van Google AppEngine is dat alleen Python wordt ondersteund, dat niet de meestgebruikte scriptingtaal voor webapplicaties is. Google is echter actief gebruiker van Python en heeft ook de bedenker van de taal, Guido van Rossum, in dienst. Volgens de documentatie van AppEngine zullen echter op termijn ook andere programmeertalen in de dienst worden opgenomen.

Reacties (34)

Een ander (groter) nadeel is dat je, in iedergeval als online bedrijf, vrijwel alles bij één groot Amerikaans bedrijf neerlegt. Je code, je data, je verkeer. Een flink deel controle ben je dus kwijt, migreren naar een ander bedrijf is verre van triviaal (iig op dit moment) en ook wat privacy betreft is dit geen geweldige oplossing. Technisch, economisch en ook wat milieu betreft is dit een erg mooi systeem. Bedrijfskundig gezien lijkt het me echter een complete ramp

Zolang je niet zelf een eigen server ergens in een rack gaat of wilt hangen en beheren ben je altijd afhankelijk van derden. Ik zie niet in waarom dit vanuit een bedrijfskundig oogpunt een complete ramp is. Juist je niet core business taken inhouse willen houden is een bedrijfskundige ramp lijkt me.

Maar in dit geval kan ik je niet helemaal ongelijk geven. Deze omgeving is zo specifiek dat het inderdaad lastig is om een vervanger te vinden. Dat is voor een LAMP, J2EE of .NET omgeving een stuk makkelijker.

Zolang je niet zelf een eigen server ergens in een rack gaat of wilt hangen en beheren ben je altijd afhankelijk van derden.

Zelfs dan ook nog. Network provider die zijn rekeningen niet heeft betaald. Kapotte switch hier, stroomstoring daar. Of het datacenter dat overgenomen wordt of failliet gaat.

Nee, ik vind dit een superzet van Google en alle voordelen vind ik zeker wel tegen het nadeel van privcacy opwegen. Nu nog wachten op het meer gangbare ASP/PHP etc...

//edit//
@ RutgerM: ik hoef helemaal geen persoonlijk contact met Google! Ik weet gewoon dat bij Google de boel gewoon blijft draaien. Het is me juist een megagrootvoordeel dat ik de boel aan Google kan overlaten, i.p.v. dat ik in het weekend met een NL providertje moet gaan bellen als de boel er voor de zoveelste keer weer is uitgevlogen.

En daarnaast, als ik een vraag heb over Google Apps, Analytics of Adwords dan wordt ik altijd keurig binnen een dag per mail geholpen door een Google medewerker, dus begin niet over het ontbreken van service!

//edit 2//
Haha, jij gaat wel erg lang door. Bij Google ergens op hopen? Tsss, je bent volkomen ongeloofwaardig bezig als je gaat stellen dat het bij Google een zooitje zou zijn. Net of hun Gmail er vaker uitligt dan de mail van een NL providertje...

[Reactie gewijzigd door Anoniem: 237663 op 9 april 2008 01:06]

Alsof je bij Google persoonlijk contact hebt ?

Even bellen in het weekend is er niet bij, SLA's zijn moeilijk af te spreken.

Google doet veel om op dit moment in de markt te blijven, service bieden ze echt niet, kunnen ze ook niet.

@j.meloen: Je weet dus echt niets van applicatiebeheer en "hoopt" maar op service.

Succes met je development, als je namelijk op die manier je klanten moet bedienen... "providertje" ? Zeker nog nooit in een serverruimte van google geweest ? De gemiddelde provider heeft het echt beter op orde, geloof me.

[Reactie gewijzigd door RutgerM op 9 april 2008 00:04]

Ik kan me voorstellen dat wanneer je een betaalde dienst bij google afneemt zoals dat nu ook al mogelijk is dat je wel degelijk support krijgt als bedrijf zijnde...

Zijn ze echt te groot voor, geloof me, kijk naar XS4ALL.... ook een zootje met die internet Guru's.

Vanuit een bedrijfskundig oogpunt zou het bijvoorbeeld een nadeel kunnen zijn dat je de boel niet kan expoteren voor het maken van een backup, of zodat je de data kan importeren in een lokaal programma (Filemaker, Outlook e.d. bijvoorbeeld).

Of het zou een nadeel kunnen zijn dat als Google's service een keer plat ligt, zoals bij sommige mensen met Gmail het geval is/was, dat je gewoon niets kunt. Het is een gratis service, dus echt veel om op terug te vallen heb je dan niet

Verder wel een erg mooie dienst... ben benieuwd of er een soort online versie van Bento komt

Waarom zou je het niet kunnen exporteren? Je kunt toch een webpagina in python schrijven die je een dump van de database levert. Lijkt me niet zo'n probleem. Dump zelf van meerdere websites de mysqldb's via webpagina.

Neem aan dat je de rest van de code al hebt...

Enige probleem zou het type database zijn dat google gebruikt. Maar hier kun je weer abstractie lagen voor schrijven.

Als je code moet gaan schrijven speciaal vanwege de omgeving die Google biedt (databaseondersteuning, gegevensexport) dan wordt het al gauw een stuk kostbaarder.

Mja voor schalen is het ideaal. Je site knalt er dan niet meer uit; de site krijgt de resources die zei nodig heeft via het cluster. (Er van uitgaande dat Google straks verder gaat met Amazon-model; betalen per gebruikte resources)

Je kan dan beter op een 'elastische' externe server draaien dan op een server die plat ligt door overbelasting. Daarnaast omzeil je hoge investeringen: als ik nu een nieuwe profielensite of videosite wil starten dan is het qua (infrastructuur-)investeringen te doen terwijl je anders behoorlijk in de buidel moet tasten. (Als je Digg-achtige pieken wilt overleven)

[Reactie gewijzigd door Frash op 8 april 2008 14:18]

Aan de andere kant hoef je ook veel minder mensen in dienst te hebben die het allemaal draaiend moeten houden en kan er ook bespaard worden op allerlei dure servers en serverruimten.

Aan de andere kant hoef je ook veel minder mensen in dienst te hebben die het allemaal draaiend moeten houden en kan er ook bespaard worden op allerlei dure servers en serverruimten.

een van de grootste fouten die je als bedrijf kunt maken is denken dat iedere vorm van besparen 'goed' is. Ik kan me een klein beetje voorstellen dat je als bedrijf vind dat IT kosten zo laag mogelijk zouden moeten zijn. Maar houdt dat in dat je al je kennis en belangrijke zaken buiten de deur moet leggen? Wie bewaakt je data, kun je naar een andere partij, kun je nog terug, ben je beschermd tegen data-diefstal? Allemaal zaken waarbij ik zeg dat je die beter binnen je eigen organisatie kunt beleggen, zodat er beter overzicht en controle is te houden. Daarnaast kent je interne IT afdeling het bedrijf van voor naar achter (althans, dat zou moeten), die kunnen dus beter inspringen op de behoeften, omdat ze dagelijks mensen zien en spreken. Je moet eens weten hoeveel belangrijke zaken besproken worden, om nog maar te zwijgen van doorgehakte knopen, in informele gesprekken tijdens een rookpauze buiten.

Bovendien is outsourcing bijvoorbeeld, verre van succesvol gebleken. Zolang je binnen je eigen landsgrenzen blijft valt dat wel te overzien, maar naar het buitenland levert meer problemen en extra kosten op dan er baten zijn. (een enkele uitzondering daargelaten). Cost overruns zijn om eng van te worden, wegens problemen in het overbrengen van de wensen door taal en culturele barrières. Dan laat ik het kwaliteit aspect nog even buiten beschouwing, want dat is soms helemaal dramatisch.

Besparen op je eigen kennis economie, ook of juist binnen de muren van je bedrijf, kan erg nadelig zijn, en nog nadeliger voor de economie van het land waar je je bevind. Er is altijd een prijs, en de meeste bedrijven zien die prijs niet, laat staan dat ze hem fatsoenlijk incalculeren. Zie het zo: iedere euro die je buiten de landsgrenzen spendeert, zie je waarschijnlijk niet meer terug. Iedere euro die je spendeert binnen je landsgrenzen zal je economie (en uiteindelijk je eigen inkomen) ondersteunen.

Moet je je tegen kunnen verzekeren denk ik

Google kennende blijft dit nog zeer lang in beta statium, wat dus maakt dat men op elk moment van de dag de stekker uit het project mag trekken zonder ook maar 1 persoon te verwittigen.
Uit bedrijfsoogpunt is Google toch maar een klein kind, ze zouden eens hun diensten volwassen laten worden door meer zekerheid te kunnen aanbieden. Momenteel zie ik alleen nog maar hobbyisten gebruik maken van bijvoorbeeld Google docs, agenda, ... en nu dit. Ook hun niet echt transparante EUL baart volgens mij veel zorgen bij bedrijven.

Een dienst zoals Gmail dat zo lang in Beta blijft, is toch wel verwonderlijk.

Ach, het ligt aan de policy die het bedrijf hanteert. Ik ken software die in mijn ogen werkt als beta. En ik ken software waarvan gezegd wordt dat het klaar is, als het klaar is.

Wat ook zou kunnen, is dat Google beta erbij zet zodat er 2 groepen mensen ontstaan; Mensen die het niet aandurven en die het wel aandurven. En op die manier komt er geen rush, en als Google genoeg gegevens heeft verzameld kunnen ze het alsnog uit beta halen.

En zoals vgroenewold al zegt. Ze zullen behoorlijk aan gezichtsverlies lijden als ze op hun plaat gaan. Want dan kunnen ze wel zeggen dat het een beta is, maar none-tweakers weten vaak niet wat dat is.

Goed punt, men kan de stekker eruit trekken of een crash de schuld geven van de status beta. Zo zal het vast bedacht zijn, echter, Google is zo groot en populair geworden...stel dat dit soort diensten falen...dan hebben ze een veel groter imago-probleem. Dus ik zie dat niet zo snel gebeuren.

De producten vind ik in principe geweldig. Goed over nagedacht, innovatief (klinkt als een ander merk), alleen zou men Docs e.d. veel meer moeten pushen...zonde als dit soort initiatieven langzaam verdwijnen.

Aan de documentatie te zien (heb het zelf nog niet getest) kan je de ontwikkelde websites ook gewoon op je eigen computers draaien. Bovendien kan je gebruik maken van bijna elk Python webframework, dus ik denk dat je zonder al teveel aanpassingen je bestaande code moet kunnen verplaatsen tussen "thuis" en google.

Er mooi dat het op Python gebaseerd is, maar ik vraag me af hoe ze dit alles hebben beveiligd. Elke gebruiker een eigen XEN host, een chroot jail, een nieuwe Python vm?
Wat houd me tegen om een webapp te oploaden die dit doet: print open("/etc/passwd", "r").readlines() ?

Stiekem hoop ik dat dit gebaseerd is op een nieuwe feature die in Python 3k uitkomt, maar ik hoop waarschijnlijk veel te veel.

[update]
Het lijkt om een soort sandbox te gaan:

An App Engine application cannot:

* write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from the filesystem is allowed, and all application files uploaded with the application are available. (Files uploaded as "static" files are not kept on the filesystem.)
* open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
* spawn a sub-process or thread. A web request to an application must be handled in a single process within a few seconds. Processes that take a very long time to respond are terminated to avoid overloading the web server.
* make other kinds of system calls, such as signals.

Wel Jammer dat je geen treads kan opstarten. Ik gok aan de hand van het soort beperkingen dat alles ten miste met systrace beveiligd is.
[/update]

[Reactie gewijzigd door Floort op 8 april 2008 17:49]

Google for president, de mogelijkheden lijken oneindig

* Het motto; "Voor niets gaat alleen de zon op" kan in de toekomst ook wel de prullenbak in --> "Voor niets kun je alleen Google gebruiken" *

Voor niets gaat Google ook niet op, die worden gefinancierd door advertentieinkomsten. Dat geld komt bij bedrijven weg. Bedrijven berekenen hun marketingkosten mee in de producten die ze verkopen door aan de klant. Wie er dus uiteindelijk voor opdraait is de klant. Het enige is dat je niet direct aan google zelf moet betalen.

ja, en die klant krijgt weer salaris van de werkgever... Dat heet economie.

Holy shit, als dit zo doorgaat dan kan elke provider wel inpakken eerdaags.

Voor een aantal klanten en mijn eigen bedrijf ben ik al overgestapt op Google Apps. Alleen de www staat nog bij de oude provider. Zodra Google ook met een beetje goede wehostingomgeving komt, dan kan alles over.

Qua privacy zal het mijzelf niet kunnen boeien. En ik weet dat het merendeel van mijn klanten daar ook geen enkel probleem mee zal hebben. Ik voorzie alleen maar verbeteringen. Zoals stabiliteit en schaalbaarheid. Sinds ik overgestapt ben op Google Apps heb ik geen enkele mailhapering meer gehad. Dat was wel anders toen ik nog mailservers van de betreffende .nl providers gebruikte.

Precies. Gewoon de MX records naar google laten verwijzen en nooit meer problemen met de mail

Snelheid, stabiliteit en betrouwbaarheid kan bijna niemand tegenop. Bovendien is het nog gratis ook

True. Heb ik ook gedaan voor een klantje van me. Ze had maar 10MB ruimte voor zowel mail, als database, als webruimte. Nu gaat alle mail lekker richting google. Ideaal!

Yupz, volledig mee eens! Gratis met maarliefst 6,5GB ruimte en mailen vanaf waar je maar wilt...

Volgens de documentatie van AppEngine zullen echter op termijn ook andere programmeertalen in de dienst worden opgenomen.
Hopelijk zit hier ook J2EE bij? Want daar ontbreekt het echt aan in de markt: betaalbare J2EE hosting. Alleen PHP/ASP-meuk wordt betaalbaar aangeboden

Dat zat ik me ook al af te vragen.

Als er meerdere talen worden ondersteund, lijkt het me dat die talen naar een intern soort bytecode worden gecompileerd. Waarom dan niet al bestaande oplossingen als Java of .Net daarvoor gebruiken/aanpassen.

Microsoft zal misschien niet zo snel samenwerken met hun grootste concurrent op internetgebied, maar volgens mij doet Sun meteen mee. Java is toch al voor een groot deel open source?

Als je een eigen (virtuele) server hebt, kun je dat toch gewoon installeren?

Ik zit bij eApps, vind ik nog wel betaalbaar. Zeker met deze $ koersen.

Privacy? Denk je dat google je informatie op het internet gaat zetten alsof het een stukje uit de krant is?

Ik vind dit een hele goede verbetering en ga het ook zeker gebruiken.

Interessante inzichten hier:

http://blogs.zdnet.com/microsoft/?p=1320
en:
http://www.news.com/8301-...bj=news&tag=2547-1_3-0-20

Als webhoster / webdeveloper voel ik mij nu zwaar bedreigt ... ipv mee op hun trein te springen moet ik nu mijn hosting afstaan aan hun ...

Voor jou als developer is er gewoon een nieuw platform bijgekomen. Het is spiksplinternieuw, dus er zijn absoluut nog geen specialisten. Je hierin specialiseren is dus precies wat je kan doen om op hun trein te springen.

Uiteraard is het een gok, je kan je ook vast blijven houden aan vertrouwde technieken. Maar goed, dat is ondernemen.

Er is niets nieuws aan hoor. Python bestaat al langer dan vandaag, en een database aanspreken is ook niets nieuws, even afgezien van het type database.