Google App Engine: gevangen in de cloud

Inleiding

In een eerder artikel over cloud computing constateerden we al dat een klein bedrijfje met alleen kantoorwerkers of een startup eenvoudig de overstap naar de cloud kan maken. Voor grotere of complexere ondernemingen zijn er echter een heleboel overwegingen en randvoorwaarden aan een migratie verbonden.

Overstappen naar de cloud blijkt dan geen technische maar vooral een bedrijfsmatige aangelegenheid. Daarom zijn het ook vaak managers die het initiatief nemen. Grote leveranciers en analistenbureaus verkondigen immers al meer dan een jaar dat de cloud gemakkelijker en goedkoper is. Dikke kans dus dat de baas een dezer dagen aan je vraagt of je bestaande of nieuwe applicaties in een cloud wil stoppen.

Met Amazon EC2, Google Apps Engine en Microsoft Azure zijn de drie belangrijkste cloud-platforms van dit moment genoemd. Amazon bespraken we eerder en Azure komt in een volgend verhaal aan bod; in dit artikel gaan we in op de omgeving en op de mogelijkheden en onmogelijkheden die Google zijn cloudgebruikers biedt.

Kanttekening: Enkele uren voor publicatie van dit artikel heeft Google bekendgemaakt een nieuwe versie van App Engine te hebben vrijgegeven, die onder andere nieuwe mogelijkheden aan de cloudomgeving toevoegt. Deze nieuwe mogelijkheden worden in dit artikel niet of niet uitgebreid besproken.

Python en Java

De platforms van Google en Microsoft vallen onder het Platform-as-a-Service-model. Dat betekent dat zij een complete omgeving voor ontwikkeling, deployment en beheer van applicaties bieden. Daarmee richten zij zich met name op programmeurs. Amazon daarentegen biedt zijn resources op het niveau van virtuele machines aan, wat we Infrastructure-as-a-Service noemen. Amazons EC2 is dan ook vooral gericht op systeem- en applicatiebeheerders. Het onderscheid tussen de twee modellen is belangrijk omdat alleen IaaS leveranciersonafhankelijk is.

Gebruikers van de Google App Engine hosten hun toepassingen op de infrastructuur van Google, waarna gebruikers die via het internet kunnen benaderen. Het gaat dus met name om webapplicaties. De dienst is inmiddels drie jaar oud; vorig jaar introduceerde Google de zakelijke variant. De prijs is gebaseerd op de benodigde verwerkingskracht, data-opslag en netwerkverkeer.

Python

Het programmeren voor de GAE gebeurt normaliter in Python, momenteel in versie 2.5.2. Een aardig weetje is wellicht dat Python bij het Nederlandse Centrum Wiskunde & Informatica door Guido van Rossum is ontwikkeld. Daarna is Python met name bij Google heel populair geworden. Van Rossum werkt daar nu ook.

De GAE Software Development Kit voor Python en de bijbehorende plug-in voor Eclipse kunnen van de Google-site worden gehaald. Deze downloads bevatten alle tools voor ontwikkeling en deployment voor de Google-cloud.

WSGI

Ook andere ontwikkelraamwerken kunnen in combinatie met GAE worden gebruikt, zolang ze maar gebruik maken van de Web Server Gateway Interface. Dat is een interface waarmee Python-programma's informatie kunnen uitwisselen met webserver en framework.

Het concept is niet wezenlijk anders dan de manier waarop web-applicaties via (Fast)CGI of een Apache-module worden aangeroepen. PHP- en Perl-programmeurs zullen het systeem direct herkennen: ook in die talen wordt met de aanroep informatie voor web-applicaties beschikbaar gemaakt. Daarnaast zijn er functies voor specifieke web-functionaliteit.

In PHP heb je bijvoorbeeld de voorgedefinieerde server- en request-arrays, waarin respectievelijk server- en aanroepinformatie, en get-, post- en cookie-variabelen zijn opgeslagen. Daarnaast is er een functie om http-headers aan een pagina mee te geven.

Apache, 's werelds meest gebruikte web server, ondersteunt webserver-gateways via de mod_wsgi-module. Met de GAE-sdk wordt Webapp meegeleverd: een eenvoudig framework voor Python. Ook Django, Flask, Pylons, TurboGears, web2py of Zope kunnen echter gebruikt worden.

Java

Sinds 2009 wordt naast Python ook Java door GAE ondersteund. Net als voor Python is er een plug-in voor Eclipse. Daarnaast kun je Googles eigen Web Toolkit voor Java gebruiken. Je kunt echter ook in andere talen programmeren waarvoor een Java Virtual Machine - of beter gezegd: een bytecode-compiler of -interpreter - beschikbaar is, zoals Groovy, JavaScript, Ruby of Scala.

De Java-applicatie heeft de vorm van een servlet, maar je kunt ook Java Server Pages gebruiken. Dat is een andere manier om web-pagina's te genereren, vergelijkbaar met PHP, WSGI en ASP.NET.

Bij het schrijven van de Java-applicaties kan onder andere gebruik worden gemaakt van Struts, een webapplication-framework voor Java Servlets dat onderdeel van de Apache-softwaresuite is. Een mogelijk alternatief is Spring, dat een mvc-framework voor Servlets bevat.

Sinds versie 1.5.0 van App Engine de software ook experimentele ondersteuning voor de Go-programmeertaal, die door Google zelf is ontwikkeld. De programmeertaal zou in ontwikkeling zijn genomen omdat Google-ontwikkelaars tot hun ontevredenheid zouden hebben vastgesteld dat het schrijven van software de afgelopen tien jaar steeds complexer is geworden. Go is door Google-programmeurs intern ontwikkeld, waarbij het werk al in 2005 begon en in een later stadium het project een ontwikkelteam kreeg toegewezen.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Bibliotheken en api's

Software-bibliotheken

De GAE-omgeving bevat een aantal propriëtaire softwarelibrary's. Sommige van deze api's bieden functionaliteit die specifiek voor Google is, andere worden door Google gebruikt om zijn diensten in rekening te kunnen brengen. Een aantal Java- en Python-bibliotheken zijn door Google op een rijtje gezet, maar deze overzichten zijn bepaald niet uitputtend.

Meer API's

Zo is er de Datastore-api om gegevens op te slaan, maar de store is niet georganiseerd als een relationele database: het systeem is gebaseerd op Googles interne BigTable-formaat. Naast de api is er ook een sql-variant voor Python, die natuurlijk Google Query Language heet.

BigTable is geoptimaliseerd voor horizontale schaalbaarheid. Dat wil zeggen dat de prestaties en de capaciteit van het systeem kunnen worden uitgebreid door er simpelweg meer, relatief kleine computers parallel naast te zetten. Net als bij relationele databases spreekt men bij dergelijke systemen wel van gestructureerde opslag, maar omdat slechts een beperkte instructieset beschikbaar is - zo zijn er bijvoorbeeld geen table joins mogelijk - wordt de taal ook wel NoSQL genoemd. Er is ook een high-availability versie van BigTable beschikbaar, maar de kosten daarvan zijn drie maal zo hoog.

Andere, meer beheersmatige api's zijn bijvoorbeeld Capabilities, voor het opvragen van informatie over uitval en gepland onderhoud, en Multitenancy, om aparte namespaces voor verschillende gebruikers te creëren. Dat is met name nuttig voor SaaS-applicaties met meerdere klanten in dezelfde omgeving. Verder zijn er de Channel-api, waarmee bijvoorbeeld in games of chatapplicaties informatie van de server naar de clients kan worden gepusht, en OAuth, waarmee externe applicaties toegang kunnen krijgen, zoals bij Twitter, LinkedIn en Facebook.

Dan is er nog Prospective Search. Deze experimentele Python-api is nu nog gratis, maar gaat te zijner tijd geld kosten; met deze tool kan een abonnement op een search query worden genomen, zodat je alerts kunt versturen naar mensen met een specifieke zoek- of filteropdracht.

De Appstats-api geeft toegang tot prestatie-informatie en statistieken. De Remote-api geeft vanuit elke Java-applicatie toegang tot de Google-functionaliteit. Hiermee kunnen deze diensten ook met lokale toepassingen worden gebruikt.

Met versie 1.4.3 van GAE is ook een testomgeving voor Python beschikbaar gekomen, waarmee applicaties buiten de App Engine-omgeving kunnen worden getest. Dit platform, dat naast het Java Testing Framework beschikbaar is, ondersteunt lokale en platformonafhankelijke tests. Daarbij wordt het principe van unit testing gevolgd, waarbij functies ieder op lokaal niveau worden getest. Pas daarna worden op een hoger niveau integratietests uitgevoerd. Zo houdt men het testen van complexe en gedistribueerde software beheersbaar.

Sinds versie 1.5.0 kan bovendien de prediction-api, waarmee processen patronen kunnen herkennen en op basis daarvan beslissingen kunnen nemen, door iedereen worden gebruikt. Tot nu toe was deze invite-only. Met deze api kunnen bijvoorbeeld spam-mails worden herkend, of kunnen de interesses van een gebruiker in kaart worden gebracht. Onbeperkt gebruik van de prediction-api kost 10 dollar per project per maand. Bij meer dan 10.000 voorspellingen per maand moet bovendien 50 dollarcent per 1000 voorspellingen worden betaald.

Ook voegt 1.5.0 support toe voor langlopende processen. Meer hierover staat op de volgende pagina.

Beperkingen en prijsmodel

Beperkingen

Hoewel zo veel mogelijk standaard-api's voor programmeurs beschikbaar zijn gemaakt, zijn er wel beperkingen aan de GAE-omgeving. Je hebt geen lokale opslag of netwerkverbindingen tot je beschikking: alleen Googles propriëtaire services kunnen gebruikt worden. Dat betekent dat je een foutmelding krijgt zodra je een file of een socket probeert te openen. Hetzelfde geldt voor subprocessen en threads.

Ook native code wordt niet ondersteund. Verder moet een programma, of het nu gaat om een web request, een cronjob of een batch, binnen dertig seconden zijn respons genereren. Ten slotte is er wel een Python-api voor bulk-uploads en -downloads, maar niet voor Java.

Voor mail, http-requests en datastorage kun je in plaats van de Google-aanroepen ook Java's eigen functies gebruiken. Zo worden Java Data Objects en persistente objecten automatisch afgehandeld door de Google-library's. Hiermee kan code zo generiek en onafhankelijk worden gehouden. Maar als je de Google-specifieke aanroepen gebruikt - en voor de meeste api's kan dat niet anders - dan is de code niet portable meer..

Prijsmodel

Het betaalmodel is behoorlijk ingewikkeld. Er zijn maxima voor opslag, inkomend en uitgaand dataverkeer, e-mailberichten en processorbelasting. Volgens Google zou je ongeveer vijf miljoen pagina's per maand gratis moeten kunnen serveren.

Bij een serieuze website zul je hoe dan ook moeten betalen. Afrekenen doe je via Googles betaaldienst Checkout. Je kunt wel dagelijkse quota instellen, zowel voor je budget als voor de resources die je applicatie krijgt toegewezen.

Sinds versie 1.5.0 moeten gebruikers die meer dan 24 instance-hours per dag willen consumeren of meer dan 1 gigabyte data heen en weer willen schuiven, niet alleen op basis van gebruik betalen, maar zullen zij ook een startbedrag van 9 dollar per platform moeten neerleggen. Daar krijgen ze dan wel een sla met een uptimegarantie van 99.95 procent voor terug.

Kosten Google App Engine
Uitgaand dataverkeer	0,12 dollar per GB
Ingaand dataverkeer	0,10 dollar per GB
Processor	0,10 dollar per uur
Data-opslag	0,15 dollar per GB per maand
Gerepliceerde data-opslag	0,45 dollar per GB per maand
Mail	0,0001 dollar per adres
Always-on	0,30 dollar per dag

Het is maar de vraag of deze tabel je helpt bij het bepalen van je kosten. Vanwege de complexiteit van het betaalmodel is het lastig tevoren uit te rekenen wat je elke maand kwijt bent. Het beperken van je dagelijkse uitgaven is ook geen optie. Dat zou bijvoorbeeld kunnen betekenen dat bezoekers na drie uur 's middags niet meer bediend worden.

Tweakers-expert Paul van Assen wijst erop dat deze situatie niet noodzakelijk slechter is dan wanneer je je eigen systemen koopt. De dimensionering daarvan is vaak ook een gok. Voordeel van de cloud is dat je nu niet vastzit aan overcapaciteit, terwijl capaciteitstekorten razendsnel opgelost kunnen worden. Meerdere experts uit ons panel stellen echter dat als je veel volume hebt, het goedkoper is om je eigen hardware te kopen.

Overigens heeft Google sinds versie 1.5.0 van zijn App Engine ook een zogenoemd Backends-component. Volgens Google zou dit ideaal zijn voor ontwikkelaars die een grotere, langdurige of geheugenintensieve infrastructuur willen opzetten. Voorheen draaiden GAE-applicaties op kortlevende dynamische instances, maar daar kleefden voor sommige ontwikkelaars nadelen aan. Backends zijn langlevende door een ontwikkelaar beheerde en benaderbare sets van instances. Deze nieuwe mogelijkheid kent geen beperkingen qua aantallen requests en kunnen tussen de 128MB en 1GB aan geheugen gebruiken. Voor deze Backends, die er in vier gradaties zijn, moet per instance per uur worden afgerekend.

Applicatiebeheer

Behalve dat je alleen betaalt voor je daadwerkelijke verbruik, is ook gemak een belangrijke reden om softwaretoepassingen in een cloudsysteem onder te brengen. Omdat je applicaties bij Google draaien, hoef je zelf geen eigen servers meer te onderhouden, uitrollen is een kwestie van uploaden en om op te schalen hoef je alleen meer processorkracht te bestellen.

De Administration Console is een web-interface om maximaal tien applicaties te installeren, om instances te starten en om de datastore te configureren. Applicaties kunnen vervolgens aan een domeinnaam worden gekoppeld of als subdomein onder appspot.com worden gedraaid. Statistieken over de prestaties van het systeem vind je in het System Status Dashboard.

Wat vinden onze panelexperts?

Tweakers-panelexpert Wouter Westendorp ziet de Datastore als de grootste sta-in-de-weg voor portabiliteit. Dat betekent dat cloud-ontwikkelaars de schaalbaarheid van de opslag en de onafhankelijkheid van het platform tegen elkaar moeten afwegen. In ieder geval wordt aangeraden eigen wrappers te schrijven, zodat je de storage op zijn minst binnen de applicatie kunt abstraheren. Peter Smit is dan weer erg te spreken over de wrappers die Google zelf al voor zijn propriëtaire library's heeft gemaakt. Volgens hem zijn er ook goede oplossingen voor de Datastore. Daarnaast heeft Google aangegeven dat er aan MySQL-ondersteuning wordt gewerkt.

De meeste experts zouden geen applicaties in een andere taal herschrijven als dat alleen is om ze op een cloudplatform te kunnen laten draaien. De panelexperts vinden het alleen zinvol om te onderzoeken of bestaande Java- en Python-applicaties naar GAE kunnen worden overgezet. Met name het snelle schalen zou dan een belangrijk argument kunnen zijn.

Volgens Tweakers.net-developer ACM staat de complexiteit van applicaties een eventuele migratie in de weg. Hij vindt de Google-omgeving te star. Paul van Assen wijst er op dat de cloud-infrastructuur een hele andere manier van denken van de programmeur vraagt: veel werk moet parallel en asynchroon gebeuren. Volgens Peter Smit is dat een veel groter obstakel bij migraties dan de platformafhankelijke library's.

Google werkt op dit moment aan de ondersteuning van andere talen. PHP is dan een voor de hand liggende kandidaat. Maar deze taal speelt volgens Van Assen geen rol in enterprise-architecturen. Ook Westendorp heeft geen hoge pet van PHP op, en Java noemt hij zelfs al legacy-software. Zijn voorkeur gaat uit naar Python met Django, wat volgens hem 'een kwaliteitsframework met een professionele, stabiele en levendige community die voorziet in de ontwikkeling van het framework en gedegen extensies' is. Hans van den Bogert vindt echter ook Python nog niet volwassen genoeg voor zakelijke toepassingen.

PHP-programmeurs zijn volgens ACM makkelijker te vinden dan die voor Python en Java. Westendorp denkt weer dat de overstap van PHP naar Python -'een mix van PHP en JavaScript' - goed te doen is. Zij zijn immers al bekend met html, css, JavaScript, sql en xml. Tom van der Woerdt ziet de populariteit van Python dan ook snel toenemen. Hij schreef tot voor kort in PHP en doet nu alles in Python, in combinatie met een framework. Volgens hem is de overstap in een of twee weken te maken.

Conclusie

Met App Engine biedt Google een cloudomgeving die vooral programmeurs en techneuten zal aanspreken. De keuze voor een overstap is echter vooral een zakelijke aangelegenheid. Dat betekent dat een afweging op kosten en baten moet kunnen worden gemaakt. Googles prijsmodel maakt dat niet gemakkelijk.

Speciaal voor zakelijke gebruikers is er GAE for Business. Daarmee richt Google zich op aspecten als betrouwbaarheid, beschikbaarheid, continuïteit, schaalbaarheid en veiligheid. Zo kan de toegang tot applicaties worden afgeschermd met access control lists, bijvoorbeeld om het gebruik van een toepassing te beperken tot het intranet. Ook kunnen koppelingen met externe databases worden gemaakt en kunnen ssl-verbindingen naar de eigen infrastructuur worden gelegd. De SLA van GAE for Business belooft een beschikbaarheid van 99,9 procent.

GAE for Business gaat uit van het klassieke SaaS-prijsmodel. Google vraagt acht dollar per gebruiker, met een maximum van duizend dollar per maand. Maar deze prijs geldt alleen voor een intranet; de kosten voor openbare toepassingen zijn nog niet bekend. Deze dienst bevindt zich op dit moment dan ook nog in het preview-stadium.

Een laatste aandachtspunt blijft dat een bedrijf zich met de keuze voor het GAE-platform afhankelijk van de leverancier maakt. Zodra de Google-api's worden gebruikt, kunnen applicaties niet meer zomaar ergens anders worden gehost. Een belangrijke vraag is dan ook of het gemak van de cloudomgeving opweegt tegen de nadelen van vendor lock-in. Anders gezegd: wat bieden Java en Python op GAE dat je niet relatief eenvoudig zelf op kunt zetten?

Reacties (33)

[TheGhostInc]

Zonder te persoonlijk te worden, maar ik vind Westendorp wel wat kortzichtig:
Ook Westendorp heeft geen hoge pet van PHP op, en Java noemt hij zelfs al legacy-software.

Ik weet niet of hij dit letterlijk heeft gezegd, maar de laatste keer dat ik keek was Java sowieso een programmeertaal en om het dan als 'software' te labelen is een beetje vreemd. Daarnaast is het succesvolste Smartphone platform van dit moment ook gebaseerd op de taal Java, waarmee het draagvlak weer een stap vergroot is. Dat de drijvende kracht hierachter ook Google is maakt dit nog sterker.

Persoonlijk heb ik meer moeite met Python als ontwikkelomgeving, zowel qua 'volwassenheid' als qua support. Er zijn enorm veel PHP en .NET mannen (en in minder mate vrouwen) te vinden, maar Python specialisten zijn zeldzamer en daarmee ook meteen een stuk duurder.
Vanuit een bedrijf zou ik bij GAE toch adviseren voor de Java variant te gaan, van Java programmeurs kun je nog wel een blik open trekken, Python, Django, ... voor je het weet is de ontwikkelaar van een onderdeel de enigste specialist met kennis van dat gedeelte.

[YopY]

Ergens heeft hij wel een punt - de taal zelf raakt snel outdated, als je kijkt naar zijn tegenstanders, en dan voornamelijk C#.

Echter, de andere onderdelen van Java - de JVM en de krachtige mogelijkheden die daarin verstopt zitten - zijn nog lang niet legacy. Er zijn andere JVM talen dan Java zelf, zoals Scala en Clojure. Vooral Scala lijkt zeer snel aan populariteit te winnen, en als ik me daarin vergis, dan is het sowieso een zeer interresant alternatief voor Java. En het compileert gewoon naar bytecode, dus je kunt binnen 1 applicatie of meerdere modules daarin zowel Scala als Java gebruiken, maar net welke een betere tool is.

[WouZz]

Volgens mij heb ik dat over Java inderdaad niet exact zo gezegd. Wel denk ik dat er in bepaalde omgevingen (financieel, enterprise) veel legacy Java code en implementaties zijn die je niet zomaar kan vervangen. Ook is de taal Java meer "mature", maar begint het langzaamaan ook een beetje bejaard te worden. De ontwikkeling van interpreters voor andere talen op de JVM (Quercus, Jython, JRuby, Scala) die vaak ook "bindings" naar legacy Java code ondersteunen is hier mijns inziens een gevolg van.

[Reactie gewijzigd door WouZz op 22 juli 2024 16:16]

[alex3305]

Voor het opslaan van data gebruiken wij in ons project simpelweg JSON. Dit is een licht formaat om data in op te slaan en ontzettend portable. Er is al een standaard parser aanwezig in Python for GAE en je kunt er dus meteen mee aan de slag.

Daarnaast is het voor 'vreemde' bestandstypen mogelijk de mime-type van de pagina te wijzigen, waardoor je gewoonweg elk type bestand gemakkelijk kan server uit een bytereeks. Zodoende hebben wij momenteel ook nog geen echte limitaties gevonden qua opslag.

Het enige punt waar wij in ons project mee zaten, was het feit dat verbindingen maar 30 seconden open mochten blijven. Wij hadden het liefste persistent connections gezien. Dit komt echter omdat wij een spel aan het ontwikkelen zijn, voor school, waarbij persistent connections uitzonderlijk handig zouden zijn geweest.

Echter hebben we gemerkt dat het pullen van data door de clients geen enkel probleem is, en gewoon mogelijk is.

[YopY]

JSON als opslag? Lijkt mij verre van efficient - immers, voor elke 'rij' moet je daarbij ook nog eens de 'column names' opslaan, die vaak nog meer ruimte inneemt dan de waarde zelf. D'r zullen vast wel compressiealgoritmes voor zijn, maar dan nog denk ik dat het verre van efficient is.

Een alternatief (als je een aversie hebt voor relationele databases, of als die niet 'the right tool for the job' zijn) zou een van de NoSQL oplossingen zijn, zoals MongoDB, CouchDB, Cassandra, en noem zo nog eens een bakkes moderne storage-software.

[Leftblank]

Voor het opslaan van data gebruiken wij in ons project simpelweg JSON.

Jullie schrijven JSON weg naar files? Dat lijkt mij nou niet per se een alternatief voor een volledig dbms, meer iets in het straatje van enkel gegevens opslaan in .ini of XML files. Zoiets werkt prima voor kleinere files maar zal niet direct haalbaar zijn voor grotere applicaties waarbij je veel data hebt waarin je wilt kunnen zoeken e.d..

[Reactie gewijzigd door Leftblank op 22 juli 2024 16:16]

[Stephan Oudmaijer]

Spring wordt genoemd in het geval van Java, maar is niet echt een gelukkige keuze. Bootstrappen van een Spring app duurt vrij lang in AppEngine. Ik gebruik zelf meestal Google Guice icm Wicket en JPA. Start als een rakket. En dan Jersey JAX-RS voor RESTful services.

edit:

Een goed alternatief voor Java is CloudFoundry, is ook wat completer. De AppEngine storage is gebaseerd op BigTable en GFS van Google. Hier is opzich niets mis mee, maar als je op zoek bent naar relationele gegevens opslag dan loop je tegen flinke beperkingen aan in de ORM mapping tools in Java. Deze matchen niet lekker met de AppEngine storage. DataNucleus biedt JPA support voor AppEngine, maar dit is zeer fout gevoelig en bij lange na niet JPA feature complete.

[Reactie gewijzigd door Stephan Oudmaijer op 22 juli 2024 16:16]

[malderhout]

De vergelijking met Amazon EC2 is lastig te maken. Beter is de in januari gelanceerde Amazon Beanstalk mee te nemen als PaaS oplossing. Andere met name Java PaaS aanbieders, zijn CloudBees en CloudFoundry. Al deze aanbieders hebben (in tegenstelling tot Google App Engine) volwaardige support voor Tomcat en MySQL.

[Verwijderd]

Logische wijze zal PHP wel degelijk een kandidaat zijn. Dit omdat de 1/2 wereld hiervan gebruikt maakt en tegen woordig wel degelijk kwaliteits frameworks kent (noem zend maar als voorbeeld). Met name als de cloud geschikt is voor het MKB (zoals genoemd in dit artikel) kom je al gauw uit bij PHP als tool mede omdat er juist een load aan frameworks, apps, communities, kennis en mensen zijn.

Maar goed Westendorp zal wel beter weten denk ik

Daarnaast worden een aantal andere talen niet als kandidaat genoemd die naar mijn idee ook logisch zijn: Ruby?
Zie een vergelijk met Django en Ruby: http://www.youtube.com/watch?v=PLUS00QrYWw

Ruby heeft veel potentie en zou naar m.i. een logische kandidaat zijn

[WouZz]

Westendorp speaking: Deze opmerking had inderdaad nogal wat 'context' die niet in dit artikel is opgenomen. Dat ging onder andere over de status van PHP als de facto standaard. Bottom line: helaas is een standaard technologie niet altijd technisch de beste. Zie ook het vaker genoemde VHS / betamax.

Verder lijkt het me niet meer dan logisch dat men bij Google PHP support overwogen heeft, of er op de achtergrond misschien zelfs al mee aan het experimenteren is. Maar persoonlijk denk ik dat de wijze waarop PHP zelf in elkaar zit, een van de argumenten is om hier nog even mee te wachten totdat men weet hoe een super-schaalbare en vooral veilige ondersteuning aangeboden kan worden.

[Reactie gewijzigd door WouZz op 22 juli 2024 16:16]

[Pete]

Op zich geef je een goede reactie, maar om er nu een flaimbait naar Westendorp in te stoppen... hij geeft ook maar zijn mening.

Juist met dit soort platform kunnen niet alle talen ondersteund worden. Voor zowel Java als Python (en nu Go) heeft Google veel libraries moeten schrijven een aanpassingen moeten maken. Als ik het goed begrijp zijn deze talen als eerste gekozen omdat ze bij Google zelf al gebruikt worden.

PHP zou inderdaad een logische keus zijn voor dit platform, maar ik heb liever dat men blijft focussen op de bestaande talen. Zo is het beschamend dat nog steeds alleen Python2.5 word ondersteund en geen Python2.7 of Python3.

[Reactie gewijzigd door Pete op 22 juli 2024 16:16]

[Montaner]

Niet een heel gekke reactie van spiderglobe richting mr. Westendorp.

Voorbeeldje; bijna alles bij Yahoo is gebouwd in php. De SE zelf in C++, maar dat is niet heel gek .

[Verwijderd]

bijna alles bij Yahoo is gebouwd in php.

Ik wil alleen even melden dat ik een yahoo-mail gebruiker ben en heb moeten vaststellen dat Yahoo echt oer-traag is. Ik geloof best dat de helft van de wereld PHP is, maar yahoo is nou niet het beste verkoop argument voor PHP.

[borft]

wat dacht je van facebook dan?

[CT]

Facebook gebruikt volgens mij geen 'pure' PHP.
Zie https://github.com/facebook
HPHP (hiphop php) wordt gebruikt, dus de scripts worden naar C++ omgezet.

[J-San]

Dat het in de live omgeving niet draait als 'pure' PHP doet er toch niet aan af dat het er wel in geprogrammeerd is. Ze hebben juist HipHop gemaakt omdat ze toch graag in PHP wouden blijven programmeren.

[ronaldmathies]

Facebook is niet alleen gemaakt in PHP, er wordt daar een verscheidenheid aan talen gebruikt waaronder PHP en Java en C++ (en dan bedoel ik niet de PHP->C++ omzetting).


Hier zijn verscheiden fimpjes op youtube over te vinden.

[YopY]

Dit. Bij Facebook hadden ze er ook voor kunnen kiezen om PHP de deur uit te gooien. Maar ik denk dat de keuze om toch een php-naar-C++-compiler te bouwen uiteindelijk voor hun beter uitpakt, dan hoeven ze hun ontwikkelteam (duizenden man? geen idee eigenlijk) ook niet allemaal om te scholen, noch hun bestaande codebase om te bouwen.

[CT]

Het is leuk dat iets potentie heeft maar waar google dit hele product op richt zijn (grote) bedrijven. En die draaien over het algemeent Java based framework (web)apps die (uit eigen ervaring, heb namelijk al een pilot moeten draaien) toch wel met niet al te veel moeite omgezet kunnen worden naar het GAE framework.

De Ruby/php (hobby) mensen kunnen zich natuurlijk al makkelijk op andere platformen manifesteren, daar hoeft google geen clouddienst voor te lanceren. (Al weet ik niet of een liniare scripttaal zich makkelijk in een cloud laat opnemen)

[Verwijderd]

Google richt zich niet primair op grote bedrijven. Hun meeste omzet komt van het MKB af. Ook de verwachting voor de app engine zijn voornamelijk gericht op het MKB

[humbug]

Tweakers-panelexpert Wouter Westendorp ziet de Datastore als de grootste sta-in-de-weg voor portabiliteit.

Deze snap ik niet helemaal. De datastore is vanuit Java via JPA te benaderen. Nu weet ik niet hoe beperkt de implementatie van Google is, maar JPA zou juist geen problemen met portabiliteit met zich mee moeten brengen.

[thies]

In theorie niet al is JPA support redelijk beperkt, van http://code.google.com/ap...tastore/jpa/overview.html

The following features of the JPA interface are not supported by the App Engine implementation:
* Owned many-to-many relationships, and unowned relationships. You can implement unowned relationships using explicit Key values, though type checking is not enforced in the API.
* "Join" queries. You cannot use a field of a child entity in a filter when performing a query on the parent kind. Note that you can test the parent's relationship field directly in a query using a key.
* Aggregation queries (group by, having, sum, avg, max, min)
* Polymorphic queries. You cannot perform a query of a class to get instances of a subclass. Each class is represented by a separate entity kind in the datastore.

[WouZz]

Zoals thies hierboven al aangeeft kan je de datastore niet net als een relationele database benaderen. Het column-based datamodel is essentieel anders en het gebruik daarvan heeft consequenties voor je data laag.

[Reactie gewijzigd door WouZz op 22 juli 2024 16:16]

[Verwijderd]

Ik snap niet dat developers zoveel beperkingen voor lief nemen zoals de Big Table benadering voor opslag. Ik zit zelf bij Rackspace en ben er behoorlijk tevreden over.

[Pete]

Met EC2 (en waarschijnlijk ook Rackspace) moet je zelf nog redelijk wat regelen voor het opzetten van je images en instances. Bij AppEngine heb je misschien minder vrijheid, maar behalve op deploy klikken, heb je er ech geen omkijken naar.

Ook zullen *sommige* applicaties veel goedkoper gehost kunnen worden op AppEngine.

Soms bied AppEngine ook meer services aan, die je niet snel kunt inzetten op EC2, bijvoorbeeld de Prediction API.

Het is maar waar je voor kiest. Je focussen op developpen en de tools gebruiken die er zijn, of een halve system administrator worden en de onderdelen van je applicatie bij elkaar vinden uit alle keus die er is.

[Verwijderd]

Google werkt op dit moment aan de ondersteuning van andere talen. PHP is dan een voor de hand liggende kandidaat. Maar deze taal speelt volgens Van Assen geen rol in enterprise-architecturen. Ook Westendorp heeft geen hoge pet van PHP op, en Java noemt hij zelfs al legacy-software.

Je kunt toch HipHop for PHPgebruiken, dat php omzet naar C++ code.

HipHop for PHP transforms PHP source code into highly optimized C++. It was developed by Facebook and was released as open source in early 2010.

HipHop transforms your PHP source code into highly optimized C++ and then compiles it with g++ to build binary files. You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance.

Facebook sees about a 50% reduction in CPU usage when serving equal amounts of Web traffic when compared to Apache and PHP. Facebook’s API tier can serve twice the traffic using 30% less CPU.

Dat Facebook ook gebruikt en vrijgegeven is als OSS project.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:16]

[YopY]

Omzetten naar C++ is in het geval van Facebook symptoombestrijding en niet de investering willen doen om hun 'core' ontwikkelteam om te scholen. Het maakt niet dat PHP ineens een keuze wordt voor 'enterprise'-architectuen - sterker nog, bijna geeneen scripttaal of loosely-typed taal (hieronder vallen ook python, ruby, etc) worden in de 'enterprise' omgevingen gebruikt, simpelweg omdat 'statically typed' talen (java, C# en kompanen) op een 'officieler' manier gebouwd kunnen worden - minder slordigheidjes, meer voorspelbaarheid, en natuurlijk betere performance.

Daar moet natuurlijk wel de nuance bij dat 'enterprise' aan de andere kant gelijkstaat aan bloated, overdreven moeilijk en officieel, etc. Maar 'enterprise' staat ook voor belangrijke software, zoals die voor financiele en medische instellingen, de luchtvaart, etc. Daar zie ik PHP niet snel voet aan de grond krijgen - op zijn hoogst in een relatief kleine en niet-kritische website of -applicatie.

[arjankoole]

PHP maakt daar ook rap z'n intrede, de aversie is alweer lager dan 2 jaar terug. Banken hebben bijvoorbeeld geleerd dat je best kan eisen dat het actie-siteje van marketing voldoet aan alle eisen die ook gelden voor de internet bankieren applicatie, maar de eerste zal nooit iets met financiele transacties doen.

Er komt nu een shifting, waarbij ze gaan kijken: wat moet dit gaan doen, en vervolgens: wat zijn de eisen hiervoor?

Vaak genoeg kom je dan uit op het kunnen draaien op PHP, omdat dat kosteneffectiever is en sneller ontwikkeld kan worden, en ook op andere gebieden goedkoper is.

Best tool, best job. Ook bij dat soort instellingen

[Mottebelke]

In dit artikel wordt dan wel veel gesproken over vendor lock-in, maar er wordt niet genoemd dat er ook nog AppScale is: een open source platform is waarmee App Engine applicaties gedraaid kunnnen worden op eigen servers of op Amazon EC2

[majoh]

Persoonlijk gebruik ik App Engine voor Java om snel iets op te zetten en te kunnen laten zien. Daarvoor vind ik het heel erg geschikt.

Vooralsnog niet de behoefte gehad om er een commerciële applicatie neer te zetten. Iets wat ik door de beperkingen ook niet echt snel zou doen, en eerder voor EC2 zou kiezen.

Echter lees ik de post van Mottebelke over Appscale en het overzetten van App Engine applicaties naar EC2. Dat zou toch een mooie ontwikkeling zijn. Snel iets opzetten en uitwerken met App Engine, mocht het aanslaan, overzetten naar EC2 voor wat meer inbreng in de inrichting.