Miro a abandonné AWS Lambda pour l’acquisition client

Choisir AWS EKS parce qu’il est devenu un « standard de facto » ? C’est le raisonnement qu’on avance chez Miro. En tout cas au sein de l’équipe acquisition.

Cette dernière s’est retrouvée confrontée aux limites d’un autre service AWS : Lambda. Principal souci : la durée maximale d’exécution des fonctions (15 minutes), devenue insuffisante pour certaines tâches traitant de gros volumes de données.

Deux options de remplacement ont été envisagées. EKS, donc… et un autre produit de la maison : ECS. Qui, reconnaissent les ingés de Miro, aurait tout à fait convenu, pour un coût potentiellement moins élevé (pas de facturation d’un plan de contrôle en plus des ressources consommées).

Miro change de service, pas de fournisseur

Miro disposait toutefois déjà d’un patrimoine EKS, pour plusieurs applications. Par rapport à ECS, il n’y avait pas de journalisation native sur CloudWatch, mais davantage de possibilités de personnalisation… et la compatibilité « out of the box » avec l’écosystème Kubernetes.

L’objectif était le même qu’avec l’architecture fondée sur Lambda : automatiser la création et l’exécution de tâches planifiées. La mise en place sur le socle EKS a impliqué quelques manips spécifiques sur des aspects allant de l’emplacement des fichiers de configuration à l’introduction d’un conteneur intermédiaire pour packager les tâches au format JAR.

À consulter en complément, le cas d’Amazon Prime Video. L’équipe tech utilisait initialement, pour analyser la qualité des flux, un service fondé sur des fonctions Lambda coordonnées par Step Functions. Elle a fini par regrouper ces composantes dans une tâche ECS unique.

Photo d’illustration © Vavilen – Adobe Stock