“S’il y a une seule chose qu’on sache en matière d’IT, c’est qu’il y aura un couac à un moment donné”

La migration vers le nuage peut être simple, mais sa pleine utilisation exige une autre approche. Comme veiller à ce qu’une application continue de fonctionner en cas de problème quelque part.

Data News a rencontré Sébastien Stormacq, Senior Technical Evangelist chez le fournisseur de nuages Amazon Web Services (AWS). Il y fait la liaison entre les utilisateurs et l’équipe en charge des produits. “Mon rôle est d’une part d’en ‘apprendre’ aux clients à propos de notre technologie. D’autre part, je parle avec eux des défis à relever et ce feedback, je le transmets alors à notre équipe en charge des produits. Voilà qui rend la prise de parole lors de conférences telles Devoxx en Belgique très intéressante pour nous.”

Vous aimez aborder la façon de faire face à des problèmes lors du déploiement d’une infrastructure. Ne devrait-on pas plutôt faire en sorte que tout fonctionne bien directement?

STORMACQ: “Je veux parler de la possibilité de continuer de fonctionner, même lorsqu’il y a un pépin. S’il y a une chose qu’on sache en matière d’IT, c’est qu’il y aura un couac à un moment donné. Cela peut se passer au niveau du réseau, de l’alimentation… partout. Mais au lieu que votre appli web se plante et devienne indisponible, mieux vaut se tourner vers un système qui fonctionne de manière limitée et se restaure finalement grâce à plusieurs techniques au niveau du code. Cela rend les applis plus robustes et réactives.

“La plupart des applis héritées ne sont pas conçues pour le nuage ou les systèmes distribués, mais plutôt pour un système, où la base de données est toujours présente, ce qui n’est pas toujours vrai dans le nuage et sur site. Voilà pourquoi il faut miser sur une meilleure gestion des pannes.“

Comment l’apprendre aux clients?

STORMACQ: “Nous avons beaucoup découvert en interne, souvent de la plus pénible des manières. Mais nous documentons les meilleures pratiques, lorsque nos équipes découvrent des problèmes et les partagent le plus largement possible. Au fil des ans, nous avons collecté les meilleures pratiques, afin de faire fonctionner les systèmes à très grande échelle, et nous les partageons avec les développeurs via l’Amazon Builder’s Library.”

Vous procédez probablement aussi de cette façon, parce qu’AWS propose une infrastructure flexible à mettre en oeuvre?

STORMACQ: “Il faut bien entendu compter avec la dynamique de l’infrastructure et avec AWS, nous voulons offrir une plate-forme fiable à nos clients. Mais l’application est aussi très importante. Il faut que des codes spécifiques puissent continuer de fonctionner.”

“A un niveau inférieur, cela signifie que les clients utilisent notre infrastructure pour une architecture hautement disponible, comme par exemple deux serveurs au lieu d’un seul dans le nuage, et répartie entre plusieurs centres de données. L’infrastructure est dès lors prévue pour pouvoir continuer de fonctionner au cas où un serveur ne serait pas disponible. Les oeufs sont déposés dans deux paniers différents.”

Pourriez-vous décrire cela plus concrètement?

STORMACQ: “Au niveau des applications, il est possible de faire aujourd’hui certaines choses différemment qu’avant. Lorsque j’étais encore un développeur, j’écrivais du code pour une base de données. Dès qu’il y avait un problème, elle ne fonctionnait plus. A présent, on développe de manière telle qu’une appli fasse une pause, puis réessaie et se restaure ainsi souvent d’elle-même. Si ce n’est pas possible, il faut faire appel à une sorte de contenu par défaut ou de contenu caché, à savoir quelque chose sur quoi retomber.”

“Un bel exemple est fourni par la page d’accueil de Netflix. Idéalement, on y obtient des recommandations sur base du comportement de visionnage de l’utilisateur et des tendances du moment. Il s’agit de plusieurs services en un. Si l’un d’eux ne fonctionne pas, il se peut que l’on voie apparaître alors une case blanche avec un message d’erreur, ou bien un contenu caché, qui sera identique pour chaque utilisateur, mais qui aura le mérite d’exister.”

Je vais ici enfoncer une porte ouverte, mais ne serait-il dès lors pas plus utile pour de nombreuses applications de combiner un nuage public tel AWS avec un nuage privé sur site?

STORMACQ: “L’utilisateur aura alors autant de problèmes sur son réseau local. Chez nous, les données passent par plusieurs régions de disponibilité, et on peut concevoir l’infrastructure de sorte qu’elle demeure toujours opérationnelle.”

Cela ne se traduit-il pas par un problème de latence pour certaines applications? Une autre zone ne se trouve-t-elle pas bien vite à quelques centaines, voire à des milliers de kilomètres de distance?

STORMACQ: “Chez nous, on parle de régions. Nous en disposons de 22 notamment en Irlande, à Francfort, à Londres, à Paris et bientôt aussi à Milan. Nous possédons aussi des centres de données locaux distants de quelques kilomètres les uns des autres. La latence entre ces centres est généralement inférieure à 10 ms.

Vous aimez aussi promouvoir l’utilisation de services à développer pour le nuage. Est-ce très spécifique ou est-ce une approche universelle?

STORMACQ: Actuellement, il existe quelque 185 services disponibles pour les clients d’AWS. Il ne s’agit donc aucunement d’une approche universelle. Nous proposons des éléments de formation pour aider les clients à démarrer. Certains sont même gratuits et en version vidéo. Et évidemment, nous disposons d’un large réseau de partenaires, qui peuvent aider les clients lors du développement de solutions.”

Comment cela se passe-t-il en Belgique? Des modèles ou l’adoption du nuage public sont-ils déjà des pratiques courantes ici?

STORMACQ: “Les clients belges se tournent vers le nuage comme les autres. Mais on observe des différences. Dans la finance, on voit par exemple des startups nous choisir plus rapidement pour des raisons d’agility et d’élasticité facilitant l’évolutivité. Une seule grande banque belge, dont je ne peux malheureusement pas citer le nom, travaille bien avec nous.”

“Le VDAB (le pendant flamand du FOREM et d’ACTIRIS, ndlr) utilise AWS pour faire correspondre par apprentissage machine les meilleurs candidats pour certaines places vacantes. La Vlaams Agentschap Wegen en Verkeer possède aussi sur AWS une appli qui cartographie toutes les routes et tient à jour tout le matériel et les défauts routiers. Avant, lorsque cette appli n’était pas disponible, il fallait en revenir au stylo et au papier. Grâce à AWS, elle est toujours disponible.

Migrer vers le nuage est évidemment facile pour les nouveaux projets. Y emmenez-vous aussi les anciennes applications?

STORMACQ: “Oui. On distingue trois types de migration: le premier, c’est lift & shift: vous prenez votre application et la transférer dans le nuage. C’est relativement simple, mais l’avantage du nuage est limité.”

“Le deuxième est le refactoring: au lieu de gérer quelque chose soi-même, on utilise Amazon RDS. Nous gérons la base de données, et le client ne doit même pas se soucier des sauvegardes, mises à niveau, etc.”

“Le troisième type, qui comprend aussi les nouvelles applications, consiste en un changement d’architecture vous permettant d’utiliser la technologie du nuage. Comme par exemple laisser tourner du code sans serveur. On passe ici d’une migration sur site à une application conçue pour le nuage.”

“Pour ce qui est d’Aurora, notre base de données relationnelle utilisant la technologie ‘cloud’ résidente, elle connaît les différents centres de données et réplique les data vers eux, afin que rien ne se perde. Elle est compatible avec mySQL et postgreSQL, ce qui fait qu’il ne faut pas changer de code. Nous possédons aussi un service de migration pour aider les développeurs à migrer vers Aurora au départ de la base de données Oracle traditionnelle. A partir de là, l’évolutivité est possible. Il ne faut pas non plus prévoir de stockage supplémentaire, comme c’est le cas dans un environnement traditionnel.”

“Récemment, nous avons du reste avec Amazon.com (dont dépendent le magasin web, le service de diffusion, etc., ndlr)complètement renoncé à Oracle. Ce faisant, nous avons transféré 1.600 instances vers une nouvelle plate-forme, parfois vers Aurora, parfois vers mySQL ou vers noSQL, en fonction de l’appli.”

Le fondateur d’Oracle, Larry Elisson, aimait insister sur le fait qu’Amazon ne pouvait se passer de la technologie d’Oracle. Je suppose que vous allez utiliser cela pour convaincre les clients que c’est tout autant possible avec la technologie AWS?

STORMACQ: “Tel est en effet le message à faire passer. Si une organisation aussi vaste et complexe qu’Amazon peut se passer d’Oracle, à plus forte raison les autres. Cela nécessite pas mal de travail, et ce n’est pas toujours facile, mais c’est à coup sûr possible.”

A l’inverse, est-ce facile de renoncer aux services AWS? Si une entreprise veut transférer sa charge de travail spécifique vers Azure ou Google Cloud? Ou l’héberger de nouveau sur site?

STORMACQ: “Cette question nous est posée par de nombreux clients et à juste titre. Les clients d’AWS restent en possession de leurs données. C’est leur propriété, et ils doivent pouvoir les déplacer.”

“Nous utilisons à cette fin beaucoup de technologies disponibles par défaut sur le marché. C’est ainsi qu’un outil conçu pour déplacer des données dans et hors de mySQL est aussi compatible avec Aurora. Pour les applications, cela fonctionne de la même façon qu’avec Linux ou Windows dans votre propre centre de données. Il n’y a pas de lock-in (enfermement propriétaire, ndlr). Les clients peuvent déplacer leurs données vers nous et vice versa. Cela ne leur coûte rien.”