Avec un faible coût d’entrée et une mise en œuvre rapide, les architectures Serverless sont un bon terrain pour expérimenter et tester de nouveaux services innovants. L’équipe IT de 20 Minutes a ainsi récemment développé un skill pour Alexa, accessible au public francophone aux Etats-Unis et au Royaume-Uni. Aurélien Capdecomme, CTO chez 20 Minutes, a répondu à nos questions sur ce projet mené avec AWS Lambda.

Quel est votre contexte d’infrastructure et votre connaissance de l’éco-système AWS ?

Nous sommes hébergés sur un Cloud privé chez Oxalide et nous sommes en cours de migration vers AWS. Ce projet va s’étaler sur 12 à 18 mois. Nous ne migrons pas en bloc : nous re-développons certaines applications pour profiter des services managés. Certaines de ces applications ont une architecture Serverless, pour des raisons d’économie de ressources, de performances. D’autres applications, qui ont été développées récemment (en PHP) par exemple, seront migrées telles quelles. Elles fonctionnent bien, et avec la taille réduite de notre équipe, nous ne pouvons pas tout réécrire pour passer sur le Cloud. Environ 50% des applications seront migrées en lift and shift, et 50% seront re-développées pour le Cloud.

Pourquoi avoir choisi le Cloud public ?

C’est un choix qui a été en partie poussé par l’équipe, très technophile. Le Cloud offre un paradigme de développement différent, où il faut penser les applications pour la résilience. Mais il y a également l’argument financier. Si le Cloud coûte au départ un peu plus cher qu’une infrastructure on premise, à terme on est rapidement gagnant. Dans le cadre du projet mené pour Alexa, nous avons pu monter un POC à coût très réduit. Pour faire la même chose chez un hébergeur traditionnel, il faut engager beaucoup plus de temps et d’argent. Cela demande de provisionner les machines, d’intervenir dans le datacenter, etc. Sur le Cloud AWS, l’infrastructure est provisionnée en quelques clics ; si le résultat est satisfaisant, il est facile d’industrialiser, dans le cas contraire il suffit d’éteindre les instances, et ça n’a coûté que quelques dollars. Nous sommes aujourd’hui dans cette dynamique de “test & learn”. Nous préférons délivrer vite, même si le produit n’est pas abouti ou parfait, et le Cloud public permet de répondre à cette logique d’itération agile.

Avec quels services travaillez-vous ?

Aujourd’hui notre infrastructure repose essentiellement sur EC2, CloudFormation, RDS, ElasticSearch Service, ElastiCache, SQS, S3, Kinesis, CloudWatch, Lambda et Polly pour Alexa.

Peux-tu présenter la fonction développée pour Alexa ?

L’audience de 20 Minutes est française à 95%, mais nous avons tout de même des lecteurs dans les pays anglophones. De fait, nous avons saisi deux opportunités : la communication voix d’Alexa, qui est un axe de développement nouveau pour les médias dits traditionnels / ou écrits, et la possibilité de faire un POC innovant, pour créer un Skill permettant aux lecteurs expatriés d’avoir en 5 minutes toutes les informations les plus récentes dans leur langue, et notamment concernant l’élection présidentielle française. L’utilisateur s’adresse à Alexa et lui demande quelle est l’actualité et les textes sont lus automatiquement en français, via Polly. Aujourd’hui, en français la voix est encore un peu robotique, mais on peut espérer qu’elle sera rapidement au niveau de l’anglais et très naturelle. Nous avons aussi profité de l’élection présidentielle pour proposer des news plus en rapport avec cette actualité : il est possible de configurer le flux “Présidentielle” de 20 Minutes dans son compte Alexa. Et tout cela se fait avec des commandes vocales (avec Alexa, Amazon Echo, l’application Amazon, ou d’autres devices…).

Quelle est l’architecture ?

Pour chaque contenu produit par la rédaction de 20 Minutes (100 journalistes), on ajoute un message dans SQS, avec les informations qui doivent être lues. C’est une fonction Lambda qui vient ensuite dépiler cette file SQS, et qui génère l’audio via Polly. Les fichiers sont déposés sur S3, et la distribution est faite par CDN. 300 à 400 fichiers audios sont générés par jour.

Par ailleurs nous utilisons également Lambda dans notre nouvelle API. Nous répliquons des données dans ElasticSearch Service, RDS et ElastiCache pour tirer parti de la performance spécifique de chacun. Chaque contenu est ainsi mis sur RDS, puis les fonctions Lambda synchronisent les informations dans les outils correspondants. A terme, nous voudrions que notre API soit complètement Serverless via Lambda et Step Functions. Notre volonté est vraiment d’utiliser au maximum les architectures Serverless, parce qu’il y a de vraies économies.

Pour quelle raison êtes-vous passé au Serverless ? La promesse du coût ? Celle de ne pas avoir à opérer votre infrastructure ?

On parle souvent du coût, et c’est en effet une composante importante pour un média. Mais nous voulons aussi émuler nos développeurs sur un marché du travail qui est très concurrentiel : pour être attractif sur le marché de l’emploi, il faut mener des projets innovants ! Et puis le Cloud se développe de plus en plus, toutes les entreprises migrent sur AWS, Google ou Azure, et les trois providers proposent des outils Serverless : c’est une vraie tendance. Et je pense que cette tendance va aller en grandissant. Donc plutôt que de rester sur ce qu’on sait faire, repensons nos concepts de développement pour ouvrir de nouvelles opportunités. Chez 20 Minutes, cet état d’esprit est omniprésent, dans tous les services et à tous les niveaux. Dans l’exemple de ce Skill Alexa, ce n’est pas le marketing qui est allé vers la technique, mais l’inverse. C’est parce qu’on s’est intéressé au fonctionnement des skills qu’on a pensé à utiliser Lambda et Polly pour proposer un nouveau service. Je trouve ça bien que la technique puisse, elle aussi, innover pour le business !

Quelles difficultés avez-vous rencontré dans le projet ?

Les difficultés rencontrées étaient surtout dues au fait que l’on débutait sur Serverless, il a fallu comprendre la logique. Le vrai frein a été la gestion des droits d’Amazon. Créer des stratégies d’autorisation a été compliqué, nous avons passé du temps pour trouver le juste milieu entre restriction et ouverture. Côté Serverless, nous avons trouvé beaucoup de ressources en ligne, bien que la technologie soit récente. La simplicité du framework Serverless a été une grande aide. Pour le Skill Alexa, nous sommes en déploiement continu : le master est mergé sur Github, les tests sont joués dans Travis, et c’est déployé. Cela a été un vrai bénéfice quand on l’a présenté à la direction : voilà ce qu’on a pu faire avec peu de temps et une poignée de dollars.

Avez-vous d’autres projets Serverless ?

Nous avons encore beaucoup d’autres projets en Lambda, pour remplacer des instances gérant diverses tâches ou encore utiliser du machine learning pour que nos journalistes gagnent en efficacité par exemple. Les EC2 vont rester pour les frontaux web; pour tout ce qui est statique, images, médias, on ne s’interdit pas d’aller vers du lambda plus tard…

À lire également sur le sujet :

Retour sur le TIAD Camp Serverless

Comment construire un proxy d’API avec AWS Lambda

AWS Lambda, une révolution pour les applications ?