Pour beaucoup d’entreprises, le Cloud n’est pas encore une réalité opérationnelle et la migration de leurs applications historiques vers le Cloud est source d’interrogations. Ce sujet a été abordé durant l’AWS Summit, lors d’une session consacrée à l’exemple de la modernisation d’une application de gestion documentaire.

Durant cette session Julien Lepine, Solutions Architect AWS, présente une application de gestion documentaire Web, développée en ASP.net, C#, et basée sur Windows server 2012 et SQL Server 2014. Cette application a été créée spécifiquement pour les besoins de la démonstration, mais elle respecte des pratiques d’architecture “classiques”. Cette application propose un portail de documents, et permet de créer des répertoires, télécharger des documents, etc. ; elle intègre un processus d’authentification.

Les piliers d’une architecture Cloud

Julien Lepine identifie 4 piliers essentiels pour bien opérer une architecture sur le cloud. L’opérateur d’une application devrait se focaliser sur ces quatre piliers, et les prendre en compte dès le déploiement de l’application :

• La sécurité : on ne peut pas se contenter des firewalls réseau et des mécanismes d’authentification fournis par la plateforme. La sécurité doit être directement inclue dans l’application.

• Fiabilité : les mécanismes de stabilité et de reprise sur incident doivent être intégrés directement dans l’application.

• Performance : il faut partir du principe que l’application et la base de données ne sont pas nécessairement sur le même serveur ; ce point doit être pris en compte dès le design de l’application.

• Budget : le budget ne se limite pas à la taille de l’équipe de développement, il faut également inclure l’impact côté Ops de l’ajout de telle ou telle fonctionnalité. Si on travaille dans une méthologie SCRUM, où on essaie de donner de la valeur métier à chaque fonctionnalité, intégrer une étude de coûts dès le développement des fonctionnalités peut être riche d’enseignements pour l’entreprise.

Les étapes de la migration dans le Cloud

En gardant à l’esprit ces principes, on peut commencer la migration dans le cloud, découpée en trois grandes étapes.

• Rehosting : durant cette première phase, il n’y a pas de changement de code ni de changement d’architecture. On se contente de bouger l’application on premise vers le Cloud, sans modifier l’application. Habituellement, ce projet est mené par les Ops. C’est un projet rapide, qui demande un niveau d’effort minimal : un “quick win”.

• Replatforming : une fois que l’application est sur une plateforme cloud, pourquoi ne pas tirer parti des avantages et des bonnes pratiques du cloud comme la scalabilité ? Augmenter la taille de la plateforme en proportion du nombre d’utilisateurs, et inversement… Si ce type de projet est initialement piloté par les ops, il implique également les développeurs pour répondre aux besoins d’élasticité. Cette étape est un peu plus coûteuse, mais elle offre de réels gains en termes de coûts d’opération et de maintenance pour peu qu’on se soit concentré sur l’automatisation des process. Par exemple, avoir des machines qui rédémarrent automatiquement après un plantage dispense d’une intervention manuelle souvent coûteuse.

• Refactoring : il s’agit maintenant de concevoir l’application sur le cloud, et de travailler sur son développement afin de tirer tous les bénéfices de la plateforme. Par exemple, plutôt que de stocker des millions d’entrées en base de données, Julien Lepine préconise de faire appel à des services managés comme DynamoDB. Durant cette phase, les métiers sont sollicités : les points d’optimisation de l’application sont ceux qui apportent de la valeur aux métiers. Une fois cette étape passée, il est possible de capitaliser et de commencer à concevoir des applications Cloud Native. Ce sont des projets agiles et itératifs, rapides à mener et qui sont pilotés par des équipes Devops, de façon à mettre en place un déploiement continu.

Services managés : l’exemple de la base de données

Revenons à notre application Legacy et à sa migration sur le Cloud. En tant que développeur, Julien Lepine ne voit pas particulièrement d’intérêt dans la création d’une base de données classique. Cela demande du temps, beaucoup d’étapes de configuration… D’où la démonstration qui va suivre : la création d’une base de données RDS sur AWS à travers Visual Studio. Pour l’exemple, en quelques clics, Julien Lepine choisit une base SQL Server standard, sa version, la taille de la machine, s’assure de la haute disponibilité… après le nommage de la base et la définition d’un mot de passe, la base de données démarre en quelques minutes. Etape suivante, nourrir la base avec des données, celles de l’application Legacy de gestion documentaire; l’extraction est réalisée avec un script Powershell, qui va chercher les données locales pour les envoyer vers la base distante SQL Server. Il suffit ensuite de changer la configuration de l’application pour qu’elle pointe vers la base dans le Cloud, avant de couper la base locale.

Les microservices : la nouvelle norme du Cloud

Passer sur le cloud suppose une nouvelle philosophie d’architecture, basée sur les microservices. Les microservices permettent de réduire la complexité : plutôt que d’avoir une boîte noire à la complexité masquée, on a un ensemble de petites boîtes, qui sont liées entre elles, et dont la complexité est exposée. Exposée, cette complexité peut alors être quantifiée, et donc mieux gérée sur le long terme.

On peut définir un microservice comme étant un service indépendant, et qui peut être reconstruit en un maximum de deux semaines. Chaque microservice doit être très simple, très limité : il n’est centré que sur une seule tâche. Chaque microservice doit être son propre maître; il peut appeler d’autres services, mais il n’en dépend pas. Un microservice doit être rapide à réécrire, et si on doit étendre ses fonctionnalités, alors il faut peut-être créer un autre microservice. Autre élément caractéristique du microservice : il est indépendant du langage de programmation. Node.js, Python… il n’y a pas de langage de prédilection pour écrire les microservices, tout dépend du contexte. Dernier point : le microservice « sait » que les pannes existent. On en revient à la question de la fiabilité dans le design d’applications, vu précédemment.

Intégration avec Amazon Alexa

D’une application Legacy à l’IoT : la session se termine par une démonstration d’intégration avec AWS Alexa, le service de commande vocale derrière Amazon Echo. Nativement intégrée à AWS Lambda, Alexa est programmable. Dans le cadre de l’application présentée en début de session, et dont la base de données a été migrée sur le Cloud, l’objectif est ici de mettre en place un système de pilotage vocal. Pour connecter Alexa à son application, Julien Lepine utilise CloudFormation pour déployer une stack basée sur Alexa : 2 tables DynamoDB, un point d’entrée API et une fonction Lambda. Un petit morceau de code en Javascript permet d’utiliser l’API créée et de se connecter à Alexa, un autre d’envoyer des documents à Alexa. Ensuite, il ne reste plus qu’à associer Alexa au compte de l’application Document Manager. Julien Lepine peut ensuite demander directement à Alexa de lire des tables ou un document qui vient d’être uploadé : le document lu par Alexa est un résumé en anglais de la session. Démonstration réussie !

Retrouvez l’intégralité de la session AWS Summit dans la vidéo ci-dessous :