Lift & shift ou refactoring ? EC2 ou Elastic Beanstalk ? Les services managés dispensent-ils de toute gestion ? Autant de questions et de situations récurrentes, et parfois de mauvaises réponses, qu’un consultant peut rencontrer au cours de ses missions. Pour vous aider à bien démarrer sur le Cloud AWS, nous vous proposons un focus sur 3 points d’attention qui font la différence : aller au-delà des services IaaS, comprendre le modèle des services managés, et anticiper la mise en production et son monitoring.

Se limiter aux services IaaS type EC2

Beaucoup d’entreprises démarrent leur voyage vers le cloud en optant pour une stratégie de migration « Lift & Shift », qui cumule plusieurs avantages : elle permet de démarrer rapidement avec AWS et d’aller vite, elle est rassurante car elle ressemble à ce que l’on connaît déjà on-premises (des serveurs physiques et des VM) … C’est assurément la plus simple, mais elle ne permet pas de tirer pleinement avantage des avantages du Cloud.

AWS propose plusieurs services de type IaaS, PaaS, SaaS, avec des modèles de responsabilité partagée différents. D’une manière générale, opter pour un service managé vous décharge d’une partie de la gestion et de la responsabilité du service et vous permet de vous concentrer sur l’essentiel, sans forcément vous contraindre à modifier en profondeur vos applications. Et si le refactoring ou le replatforming de vos applications sont des approches parfois trop complexes, vous pouvez aussi vous tourner vers le reHosting.

Par exemple : pour héberger une application simple, plutôt que d’utiliser EC2, vous pouvez considérer le service Elastic Beanstalk.

Ce service vous permet de simplement concevoir l’architecture souhaitée et d’y uploader votre code applicatif.

Attention néanmoins : si votre application doit être mise à jour (ou redéployée) régulièrement et/ou si elle doit pouvoir scaler, ce service managé peut présenter un certain degré de complexité. Il peut cependant être idéal pour monter rapidement un POC.

Si votre application est basée sur une technologie de containers, plutôt que de déployer votre stack sur EC2, vous pouvez vous tourner vers les orchestrateurs ECS ou EKS, et ainsi vous libérer de la maintenance du middleware. 

Ces produits sont-ils trop complexes pour votre cas d’usage ? Là encore, App Runner (si vous n’avez pas besoin de plus de 2 vCPU et/ou 4GB de RAM) ou Elastic Beanstalk peuvent parfois répondre à votre besoin et vous épargner de recourir à EC2.

En ce qui concerne les bases de données : j’ai rencontré un jour un client, qui déployait ses moteurs de base de données sur EC2 car cela le rassurait. Etonnamment, il n’avait pourtant pas de DBA dans ses équipes pour adresser les problématiques spécifiques aux bases de données.

Une partie de la gestion de son service étant externalisée, nous avons pu comparer le coût d’exploitation d’un service de base de données sur EC2 et sur RDS … Surprise ! Au final, RDS ne coûte pas plus cher qu’EC2 une fois que l’on intègre tous les coûts, pour un service qui s’est avéré être de meilleure qualité : le service conçu à grande échelle par AWS, est généralement plus robuste que celui construit en interne avec EC2.

Cependant, RDS n’est pas une solution universelle, car certaines fonctionnalités ne sont pas supportées : par exemple si vous utilisez SQL Server et que vous êtes un adepte des plans de maintenance, vous devrez soit refactoriser votre configuration, soit aller sur EC2.

Bien sûr, la réalité est plus nuancée.

L’essentiel est de ne pas avoir une approche dogmatique du type « tout sur EC2 » ou au contraire « tout managé ».

Chaque service a ses atouts et ses inconvénients, ses intérêts et ses limitations … Il faut garder ouvert le panel de solutions possibles, et c’est précisément le rôle d’un architecte AWS.

« C’est managé donc je n’ai rien à faire »

Je ne compte plus le nombre de fois où des clients m’ont dit « j’héberge mes applications sur le cloud, c’est managé donc je n’ai rien à faire, je n’ai même pas besoin de me préoccuper de la supervision ou des sauvegardes ».

C’est à mon sens un raccourci rapide et (beaucoup trop) réducteur.

Permettez-moi de faire le parallèle avec un service de VOD dont l’adoption est assez forte : Netflix. Netflix est un service de VOD managé. Vous n’avez donc rien à faire, sinon profiter du catalogue. Et pourtant quand vous vous êtes abonnés, vous avez fourni quelques informations et notamment votre formule.

Et bien sans le savoir, vous avez fait de la spécification… Le Cloud, c’est pareil !

Si vous déployez une base de données sur RDS, AWS ne pourra pas deviner quelle est la taille d’instance la plus adaptée à votre besoin. Tout au plus, si vous activez l’autoscaling, AWS pourra ajouter ou retirer des nodes en fonction de l’activité (en fonction de critères que VOUS devrez définir… c’est encore de la spécification!)

AWS ne pourra pas deviner non plus, quelle est la stratégie de sauvegarde de votre entreprise, combien de temps vous souhaitez garder vos logs, etc.

Sur les services IaaS/PaaS, AWS ne fait « que » vous délivrer une infrastructure, selon vos spécifications, qui sera plus ou moins managée.

AWS ne sera pas en mesure d’évaluer, si votre application performe correctement selon VOS critères.

(Ceci étant évidemment moins vrai avec des services SaaS comme par exemple S3, DynamoDB, Lambda)

Ne pas anticiper la mise en production

Les projets Cloud sont souvent associés (à raison) aux pratiques DevOps. L’un des objectifs de ces méthodologies est de gagner en vélocité, et d’accélérer la livraison des applications.

A ce titre, beaucoup d’organisations se focalisent sur la construction d’une infrastructure et le déploiement d’applications, et négligent le passage en production de leurs applications. Elles ne tirent pas avantage de l’outillage proposé par AWS, notamment en matière d’observabilité.

L’un de mes clients, n’avait pas de monitoring : la performance de l’application était évaluée en fonction des plaintes des clients ! Et les pannes étaient détectées de la même manière.

C’est d’autant plus dommage, qu’AWS propose à ses clients un certain nombre d’outils. Beaucoup d’entre eux sont même gratuits, ou d’un coût très modéré. Votre point d’entrée dans le monde de l’observabilité AWS est le service Amazon Cloudwatch. Ce n’est pas un outil parfait, mais il regroupe bon nombre de fonctionnalités très utiles, que nous allons tenter de passer en revue.

Le premier volet de Cloudwatch concerne les métriques. Pour chacun de ses services, AWS propose un certain nombre de métriques (parfois plusieurs dizaines par service). La première étape pour vous est de comprendre ce qui existe pour les services que vous utilisez, comprendre à quoi correspondent ces métriques et comment les interpréter. Pour cela, la documentation produit d’AWS est extrêmement bien fournie et organisée (par exemple pour EC2). Et si besoin, Cloudwatch vous permet aussi d’intégrer vos propres métriques.

AWS propose deux autres fonctionnalités liées aux métriques : les alarmes et les dashboards.

Les premières permettent de définir des choses simples (une valeur dépasse un seuil) mais aussi plus complexes, comme de la corrélation entre les valeurs de plusieurs métriques.

Par exemple : déclencher une alarme si le taux d’utilisation CPU dépasse une certaine valeur ET si le taux d’erreur HTTP dépasse un certain seuil.

Des fonctionnalités de détection d’anomalie sont aussi proposées pour certaines métriques : une alarme se déclenche si une métrique s’éloigne trop d’une valeur de référence, déterminée par le machine learning en fonction de l’historique des valeurs de cette métrique.

Sur ces actions, vous pouvez déclencher des notifications (via SNS), des actions de collecte d’information ou de remédiation (via Lambda ou SSM par exemple), ou simplement appeler un endpoint HTTP, par exemple vers vos outils ITSM pour automatiser la création d’un ticket.

Les dashboards permettent de construire des tableaux de bord de vos infrastructures. La feature est cependant assez rudimentaire et on pourra lui préférer une solution tierce telle que Grafana qui est aujourd’hui l’un des standards de l’industrie. Pour cela, vous pouvez vous appuyer sur un Grafana qui existerait déjà sur vos infrastructures, vous pouvez construire une brique Grafana sur une instance EC2, ou encore vous appuyer sur sur le service AWS Managed Grafana.

Cloudwatch propose également des fonctionnalités d’agrégation de logs pour les différents services que vous utilisez. Là encore, le service est assez rudimentaire et pour les usages plus évolués, on pourra lui préférer des solutions du type Elasticsearch (ou AWS OpenSearch) ou Splunk par exemple.

Une fonctionnalité souvent méconnue de Cloudwatch est celle d’Events. Pour chaque service AWS, au même titre que les métriques, AWS propose un certain nombre d’événements préconfigurés. Vous pouvez ainsi détecter l’arrêt d’une instance EC2, une action d’autoscaling, la complétion ou l’échec d’un snapshot RDS, etc. et déclencher une action.

Il serait trop long de détailler toutes les capacités de ce véritable couteau suisse de l’observabilité AWS, mais Cloudwatch propose également d’autres fonctionnalités plus avancées telles que :

• Container Insights & Lambda Insights, qui permettent de collecter les métriques ou les logs de vos containers et de vos fonctions Lambda
• Application Insights, qui peut vous aider à identifier des problèmes d’ordre applicatif
• Contributor Insights, pour vous aider à identifier les utilisateurs ou process susceptibles de consommer le plus de ressources sur vos applications
• Des services d’application monitoring (APM) telles que ServiceLens Map, qui permet de coupler les données de Cloudwatch et du service de debug applicatif Xray, ou Cloudwatch Synthetic, qui vous permet de mettre en place des scénarios pour tester votre application, ou encore des fonctionnalités de Real-User Monitoring (end-to-end monitoring).

Pour les bases de données relationnelles, AWS propose gratuitement avec RDS l’outil Performance Insights. Cet outil vous permet de comprendre l’activité de votre base de données :

• Quelles sont les requêtes les plus nombreuses ?
• Les plus consommatrices ?
• Pourquoi telle requête est-elle lente ?
• Où se trouve la contention ?
• Faut-il rajouter du CPU ? De la RAM ? Des I/O ? Des index ?

Cependant, l’ensemble de ces outils va uniquement vous permettre de développer une observabilité de votre plateforme, mais un élément restera le plus souvent de votre responsabilité : les décisions à prendre, suite à la détection de telle anomalie ou tel comportement.

Parmi tous les outils que nous avons détaillé, il manque d’ailleurs un élément important : comment savoir si un incident ou un changement sur l’infrastructure AWS, peut impacter votre plateforme ? Ce rôle est accompli par le Personal Health Dashboard, qui vous permettra de savoir quels incidents ou changements ont lieu sur les infrastructures d’AWS, et lesquels sont susceptibles d’impacter votre service.

De plus, il vous est possible de mettre en place de l’automatisation (par exemple, desnotifications) sur la base de ces informations, grâce au framework Health Aware.

Bref, l’outillage proposé par AWS pour vous assurer une bonne observabilité de vos applications est (très) riche. Devant une telle quantité d’outils disponibles, il peut être tentant de sur-instrumenter votre application.  Il faut trouver le bon équilibre entre “pas de monitoring” et une instrumentation complète de vos infrastructures, où l’information sera si riche qu’elle ne sera pas exploitée.

La bonne approche est de procéder de manière itérative, et d’enrichir votre instrumentation au fur et à mesure des cycles de vie de votre application. De toute manière, vous ne serez jamais en mesure d’anticiper toutes les anomalies possibles.

Mais aussi…

Bien sûr, les points d’attention décrits dans cet article ne sauraient être exhaustifs. Ils ne reflètent que des problématiques récurrentes, observées au sein d’un échantillon, pas forcément représentatif, d’organisations.

Dans tous les cas, la migration vers le Cloud doit être accompagnée d’une adaptation de votre gouvernance. Comme pour tout SI, établir les rôles et responsabilités est essentiel. Ne laissez pas de zone d’ombre au prétexte que le “service est managé”.

Et même si vous outsourcez, garder un certain degré de maîtrise et de compétence en interne est essentiel.