Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Door Aad Offerman

Freelancer

Google App Engine: gevangen in de cloud

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?

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (33)

Wijzig sortering
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.
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.
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 12 mei 2011 00:59]

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.
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.
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 11 mei 2011 14:12]

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 11 mei 2011 15:37]

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.
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
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 12 mei 2011 00:17]

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 11 mei 2011 10:09]

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 :) .
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.
wat dacht je van facebook dan? ;)
Facebook gebruikt volgens mij geen 'pure' PHP.
Zie https://github.com/facebook
HPHP (hiphop php) wordt gebruikt, dus de scripts worden naar C++ omgezet.
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.
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.
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.
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)
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
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.
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.
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 12 mei 2011 00:11]

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.
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.
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 Anoniem: 112442 op 11 mei 2011 16:18]

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.
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 :)
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
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.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True