Architecture Cloud : ce sur quoi travaille Google

Tirer le maximum du Cloud

Une bonne pratique en matière de développement d’applications pour le cloud est que les développeurs et les architectes en entreprise prennent minutieusement en compte l’état de résilience des applications cloud, affirme-t-il. Les défaillances du cloud ne sont pas des anomalies. Seul un nombre réduit de disques durs et de commutateurs réseau sont susceptibles de tomber à tout moment, leur fiabilité est liée à une couche au-dessus du hardware physique. Cela peut être effectué avec des outils comme des bases de données et des systèmes de fichiers distribués. « Dans le Cloud, vous devez considérer cela comme une source d’inspiration pour votre architecture », affirme Alexis Moussine-Pouchkine.

Autre élément à considérer : les instances des microservices peuvent aller et venir à tout moment. Une requête envoyée à un serveur à un moment peut aboutir sur une instance différente à un autre moment. Nombre d’architectes se bornent à concevoir des applications sans état - ou "stateless", c'est -à-dire qui ne conservent pas d’informations liées à la session utilisateur côté serveur), mais Moussine-Pouchkine affirme que l’état doit tout de même exister quelque part, ce qui nécessitte un espace dédié. Il prône un état implémenté dans une base In-Memory ou dans un cache distribué plutôt que dans l’application.

Une autre bonne pratique est d’implémenter des services plutôt que des API complètes, note-t-il. La distinction est que les services sont déployés comme des instances configurées. Cela comprend les services de cache, les services de données et les services de file d’attente de messages. Cette approche facilite le dimensionnement des applications cloud (up et down) et avec une plus grande résilience.

Jetty pour des services cloud plus rapides

Pour accélérer la mise en place de microservices, une approche consiste à utiliser le serveur et moteur de servlets Jetty. Google utilise beaucoup Jetty dans sa stratégie Web. Greg Wilkins, en charge du projet à la Fondation Eclipse et architecte en chef chez Intalio soutient que Jetty est idéal pour le Cloud du fait de sa faible empreinte, de son efficacité et de ses possibilités de déploiements modulaires.

Selon Wilkins, Java EE n’est pas adapté au cloud du fait de sa capacité à proposer un grand nombre de dépendances lors de l’implémentation de nouvelles applications. Selon le modèle J2EE, inclure de nombreux fichiers JAR (archives Java) est pratique pour les développeurs pour accélérer la mise à disposition de l’application. Mais cette approche a son revers : le coût supplémentaire lié au temps requis pour créer de nouvelles instances.

Le problème : la surchauffe occasionnée par le passage en revue de tous les fichiers JAR lorsque les nouvelles instances se lancent. Il reste encore beaucoup de travail pour résoudre ce problème, affirme Wilkins. Ce temps trop long de démarrage des services cloud provoque alors un surcoût de l’entreprise en matière de cycle CPU. De plus, les microservices doivent être sur-provisionnés pour respecter le SLA.

Wilkins pointe un autre problème : la très importe base de code de Java EE qui offre une plus grande surface d’attaque et de vulnérabilités. Il est nécessaire que les entreprises soient attentives lors du scan de ces fichiers et s’assurent que des servlets non prévus n’y soient inclus. Cela peut constituer un vrai problème si des milliers d’instances d’une application ont été déployées. La modularité de Jetty permet de rationaliser le déploiement de microservices en réduisant au minimum le nombre de fichiers JAR nécessaires.

Des extensions ainsi qu’un mode démarrage rapide ont été ajouté à Jetty pour améliorer la vitesse de déploiement de microservices dans le cloud. Ces modules vont faciliter la création de nouvelles instances d’un service en moins d’une seconde, comparé aux 30 secondes actuelles. L’équipe de Jetty collabore avec Google pour affiner davantage ses outils pour gagner en performance.

Associer le meilleur d’App Engine et de Compute Engine

Google prévoit d’ailleurs d’exploiter ces améliorations dans sa Cloud Platform, supportant désormais Docker.  Cette nouvelle architecture associe certains éléments de modularité de Google App Engine à la flexibilité de Compute Engine.

L’accès aux services, comme Abstract Window Toolkit, via App Engine a souvent été pointé du doigt par les développeurs. La nouvelle Google Cloud Platform associe le meilleur des deux mondes dans ce que la firme appelle une machine virtuelle managée, que Ludovic Champenois, tech lead sur Cloud Platform, estime différente de l'approche d’un Iaas ou d’un Paas traditionnel. Le nouveau service de VM managées est aujourd’hui disponible en accès restreint. Ludovic Champenois évoque une version finalisée pour le début novembre.

La Google Cloud Platform devrait se voir doter d’un support de processus à longue exécution, avec une durée de requête de 24 heures maximum contre 60 secondes aujourd’hui avec Compute Engine. La nouvelle plateforme devrait également supporter les processus en tâche de fond, le debugging de Secure Shell, l’écriture sur disque en local et une personnalisation de la pile serveur.

Plutôt que de s’adosser à des fichiers d’archives Web, les développeurs pourront déployer de nouvelles applications sur la Cloud Platform avec des conteneurs Docker, un serveur Jetty et une version adaptée de Linux. Cette approche permettra également à Google d’offrir des instances de conteneurs Docker pré-configurées, contenant des versions spécifiques de Jetty, l’OS et le kit de développement Java le plus adapté aux différents cas d’usage.

Red Hat travaille à créer une implémentation Dockerisée d'App Engine pour que les développeurs puissent coder en local sur un Mac, PC ou une plateforme Linux. Les développeurs pourront ensuite pousser cette version sur le Cloud avec l’assurance que cela fonctionne bien.

Avec cela, les développeurs devront acquérir de nouvelles compétences liées à la création d’applications via les conteneurs Docker, soutient Ludovic Champenois. Les architectes devront également réfléchir à de nouvelles approches pour orchestrer les services répartis sur plusieurs serveurs. Des outils comme Kubernetes et Apache Mesos devraient alors jouer un rôle en ce sens.

Traduit par la rédaction