Les nouveautés App Engine
Depuis 2009 App Engine met les serveurs de Google à la disposition de ses utilisateurs, afin d’y héberger leurs sites web.
Cette solution permet de libérer les développeurs des problématiques de déploiement et de scalabilité.
Ces dernières sont gérées entièrement par Google, la mise à l’échelle se faisant par la création automatique de nouvelles instances.
Le modèle, qui permet aux usagers de la plateforme de payer proportionnellement aux capacités utilisées dans l’infrastructure, a déjà séduit beaucoup d’entreprises. Mais le service met surtout à disposition une plateforme de développement. Quatre langages d’exécution sont disponibles (Java, Python, Go, PHP), et de nombreux services sont accessibles : inutile par exemple de maintenir son propre serveur mail ou de base de données, App Engine fournit ces services et bien d’autres.
Les fonctionnalités les plus récentes d’App Engine vont plus loin dans la philosophie du paiement à l’utilisation, en permettant par exemple de rendre des portions d’applications scalables. De nouvelles API sont également développées pour étendre les possibilités d’App Engine et le SDK supporte plusieurs langages (Python, Java, PHP et Go) et frameworks (Django, Drupal). La version 1.9.6 d’App Engine, sortie début juin 2014 apporte d’ailleurs des améliorations au SDK Python, avec une mise à jour vers les versions 1.4.13 et 1.5.8 du framework Django. Enfin, la plateforme offre maintenant plus de liberté sur les VMs utilisées pour héberger ses applications. Jusqu’à présent, App Engine permettait de faire tourner des applications dans une “sandbox”, composée d’un webserver, du code de l’application, et d’un langage d’exécution. Les Managed VMs offrent maintenant plus de liberté à l’utilisateur en lui permettant de configurer le type de machines virtuelles utilisées pour héberger son application.
Les managed VMs et Docker
Avant les managed VMs, le code d’une application App Engine était exécuté dans la “sandbox”. L’utilisateur n’avait donc pas le choix de la VM utilisée, ni du langage d’exécution dont certaines librairies étaient restreintes (comme celles permettant l’écriture de fichiers). Les managed VMs offrent plus de liberté à l’utilisateur, ce dernier peut choisir des VMs configurables parmi celles proposées par App Engine, et les langages d’exécution ne sont plus soumis à restrictions.
Les utilisateurs de Docker pourront également utiliser ce système de conteneur avec App Engine. Docker permet d’empaqueter le code d’une application avec l’ensemble de ses librairies dans une image, et de l’exécuter sur n’importe quel type de système d’exploitation. Il est maintenant possible d’exécuter une image Docker sur une managed VM. L’association Docker – App Engine permet donc de profiter d’un plus grand choix sur la machine virtuelle utilisée, tout en gardant une grande simplicité d’utilisation lors du déploiement. En effet l’utilisateur peut se concentrer sur son code applicatif, Docker se chargera de créer un fichier qui pourra être déployé sur n’importe laquelle des machines virtuelles d’App Engine. En d’autres termes, App Engine offre plus de marge de manœuvre au développeur tandis que Docker maintient la simplicité du déploiement, essentielle à la philosophie d’App Engine.
Dart côté serveur
Image 1.1 : code d’un serveur dart
Image 1.2 : la couche de mapping (1)
Image 1.3 : la couche de mapping (2)
Les Modules
Ils permettent de construire une application segmentée en composants. Les modules sont maintenant à utiliser en remplacement des Backends, dépréciés depuis mars 2014. Ces derniers étaient utilisés pour des applications nécessitant de meilleures performances de calcul, plus de mémoire, ou faisant tourner des processus assez longs (plus long que la deadline imposée à la réponse HTTP). Il est donc recommandé de mettre à jour les applications utilisant des Backends avec la nouvelle API Modules. La documentation développeur explique comment passer de l’un à l’autre. Les modules ont des avantages supplémentaires, comme la possibilité d’être versionnés, et sont scalables automatiquement, contrairement aux Backends dont il faut obligatoirement spécifier le nombre d’instances à utiliser à l’avance.
Pourquoi utiliser des modules ?
Chaque module dispose d’au moins une instance, tout comme une application classique (sans modules) dispose d’une ou plusieurs instances. Le modèle de pricing se base sur le nombre d’instances de modules utilisées, qu’il est possible de faire gérer par Google de façon automatique. Il est alors plus facile d’optimiser une application en la découpant en modules, selon que ceux-ci sont plus ou moins utilisés, afin que le nombre d’instances allouées soit adapté à leur fréquence d’utilisation. De cette façon les coûts liés au fonctionnement des instances seront moins importants. La gestion du nombre d’instances peut se faire de trois façons :
– automatiquement, selon un certain nombre de métriques telles que le nombre de requêtes utilisateurs, et le temps de latence des réponses
– manuellement : l’utilisateur décide du nombre d’instances à allouer au module
– le “basic scaling” : les instances sont démarrées lorsque l’application reçoit des requêtes utilisateur, et arrêtées lorsque l’application est inutilisée.
Image 2. Architecture d’un projet organisé en module
Chaque module est composé de code source et de fichiers de configuration. La structure générale d’une application utilisant des modules est celle d’un fichier EAR (Java Enterprise Archive) décompressé. Il est possible de communiquer des informations entre les modules, via le service URLFetch, et de faire collaborer plusieurs modules en assignant des tâches via l’API TaskQueue.
Le nombre de modules par application est limité et varie selon les comptes payants ou gratuits :
Image 3.2 Limitation du nombre de modules et de versions
Image 3.3 Limitation du nombre d’instances
Les nouvelles API
Chaque fonctionnalité de Google App Engine est classée selon l’un de ces trois statuts :
- celui de G.A. (Generally Available feature), qui signifie que la fonctionnalité est publiquement accessible et est couverte par la politique de SLA de Google. Cela signifie que son implémentation est stable, et que toute modification de l’API sera rétrocompatible.
- les fonctionnalités en preview ne sont pas couvertes par la politique de dépréciation de Google, des changements rétro-incompatibles peuvent être apportés. Ces fonctionnalités sont amenées à passer au statut de G.A..
- les API expérimentales ont pour seule différence avec les previews de ne pas être nécessairement amenées à passer au statut de G.A., et donc d’être un jour couvertes par la politique de dépréciation de Google.
Outre les Modules, de nouvelles API ont vu le jour ou ont quitté leur statut expérimental ou de pre
view. Parmi les nouvelles G.A. le Dedicated Memcache permet d’avoir accès à une API de cache qui soit spécifiquement dédiée à l’application (à la différence de l’API de cache partagé, utilisée par l’ensemble des applications d’App Engine). Le temps de réponse de l’application est alors plus facilement prévisible. Cette fonctionnalité est disponible en Europe depuis avril. Du côté des previews, Google Cloud Storage Client Library permet d’intéragir avec Google Cloud Storage, le service App Engine permettant de stocker de gros volumes de données. L’API Map Reduce permet de réaliser des calculs impliquant de très grands volumes de données en utilisant l’algorithme éponyme de Google (en preview pour java, expérimental pour Python). Un exemple simple d’utilisation ici.
Image 4 : différences entre le cache dédié et partagé
Voici un tableau récapitulatif listant la plupart des fonctionnalités passées récemment à l’état de GA ou de preview :
Image 5 : Tableau récapitulatif des passages en preview ou GA
Du côté des fonctionnalités expérimentales, on constate qu’il y a moins de changement : il n’y a pas de nouvelle API expérimentale récente et les changements dans les API préexistantes sont rares :
Image 6 : Fonctionnalités expérimentales d’App Engine
App Engine Go et PHP :
Le SDK d’App Engine est disponible pour 4 langages : Java, Python, PHP et Go. Pour ces deux derniers langages, les SDK sont cependant à l’état “preview” et “expérimental” respectivement.
Bien qu’expérimental, le SDK Go possède la plupart des fonctionnalités disponibles avec les autres langages : fonctionnalités de stockage de données (cache, datastore, blobstore), de communication (envoi de mail, requêtage HTTP), de gestion de l’application (api Users pour se connecter avec un compte Google). Seules les API MapReduce, Cloud Endpoints et Prospective Search, ainsi que les services proposés par les partenaires de Google ne sont pas disponibles.
Pour PHP en revanche, de nombreuses fonctionnalités sont encore manquantes : pour n’en citer que quelques unes, les API Images (manipulation d’image) et Search sont par exemple absentes, et il n’existe pas d’API native pour enregistrer ses données dans le datastore. Malgré cela le SDK évolue beaucoup : Les API Sockets et Modules ont été ajoutées ces derniers mois et la version 1.9 assure maintenant le chargement automatique des librairies, il en résulte un temps de chargement de l’application moins long.
Aller plus loin
Pour plus d’informations sur la façon dont app engine permet de minimiser l’utilisation des ressources, vous pouvez consulter cet article officiel. Des conseils y sont donnés pour diminuer le nombre d’instances créées, en diminuant le temps de latence des instances ou en ajustant manuellement le nombre maximum d’instances inutilisées, ainsi que sur la façon de gérer la bande passante et l’utilisation du datastore, le système de base de données d’App Engine.
Nous avions également évoqué l’apparition des modules pour diminuer les coûts de l’application, ce lien explique leur intérêt et leur utilisation.
Enfin, si vous souhaitez en savoir plus sur l’ensemble des fonctionnalités proposées par App Engine, ce lien en donne la liste et la description.
