AWS Fargate vs Azure Fabric Mesh : deux CaaS serverless au coude-à-coude

Déployer des microservices et des containers sans avoir à se préoccuper de l'infrastructure et des machines virtuelles, c'est la promesse des offres de container as a service sans serveur.

C'est en 2014 qu'Amazon Web Services (AWS) dévoilait Lambda, une infrastructure cloud dite sans serveur (ou serverless) permettant de lancer des applications sous forme de fonctions et de ne payer que les quelques secondes nécessaires à leur exécution. Une approche innovante à l'heure où les développeurs s'orientent de plus vers des architectures à base de microservices. Depuis, Docker a popularisé les conteneurs et les développeurs ont préféré cette voie qui présente beaucoup moins de risques de "vendor lock-in". En 2016, AWS lançait Amazon ECS, pour Elastic Container Service. Puis fin 2017, il commercialisait EKS (Elastic Container Service for Kubernetes), une distribution managée de Kubernetes, mais aussi et surtout Fargate. Dans cette dernière offre de Container as a Service (CaaS), la notion de serveur virtuel disparaît, l'approche est purement serverless. En réponse à cette initiative, Microsoft dévoilait quelques mois après, en mai 2018, Azure Service Fabric Mesh en bêta.

"Si on définit le serverless comme le fait de ne plus avoir à gérer les machines physiques, Amazon le permettait déjà via ses services EC2 ou EKS", souligne Marc Bojoly, manager et consultant senior pour le cabinet français de conseil Octo Technology. "Amazon Fargate vient masquer un peu plus la couche de serveurs physiques, mais il reste néanmoins une notion d'instance. En effet, celle-ci est facturée au moment où elle démarre jusqu'à ce qu'elle s'arrête et ce contrairement au service Amazon Lambda pour lequel seule l'exécution d'une fonction est facturée."

Deux réponses à un même besoin

Azure Service Fabric Mesh et AWS Fargate sont comparables, mais n'en présentent pas moins une différence d'approche. "Le premier se positionne comme une plateforme de déploiement alors que le second est plus proche d'un CaaS pur limité au management de containers", décrypte Marc Bojoly. "Azure Service Mesh peut en effet faire tourner n'importe quel workload, qu'il s'agisse de container ou même d'exécutable .exe." Hormis porter des applications découpées en microservices, Microsoft destine sa solution aux migrations (type "lift-and-shift") d'anciennes applications vers des containers Docker Windows ou Linux. L'argument massue étant qu'il s'agit de la même plateforme utilisée par Microsoft pour supporter ses services Azure ainsi que ses applications SaaS comme Skype for Business, Dynamics 365, etc.

Cyril Parisot d'Octo Technology détaille : "Les entreprises habituées à développer pour l'environnement Microsoft .Net se dirigeront assez naturellement vers la plateforme Azure Services Fabric Mesh tandis que celles qui viennent du monde de l'open source et des containers seront plutôt tentées par ECS et pourquoi pas Fargate." Le consultant architecte DevOps ajoute : "Amazon propose de choisir soit ECS avec Fargate qui va gérer de manière automatique le provisioning des ressources IT, soit utiliser le couple ECS-EC2 en gérant soi-même les nœuds EC2. Dans ce cas, vous gérez directement les instances et pouvez  éventuellement les configurer plus finement, tandis qu'avec Fargate une instance est créée automatiquement pour chaque tâche sans intervention possible."

Via un pilotage manuel des instances, il est envisageable d'ajuster la puissance au plus près des besoins, faire tourner plusieurs containers sur une même instance, et dans le même temps optimiser la facture AWS. Fargate offre cinq niveaux de puissance CPU avec pour chacun une quantité minimale de mémoire, le provisioning est automatique. Quant à Azure Service Fabric, s'il intègre la gestion d'état, ce qui lui permet d'accueillir n'importe quel type d'application. "Une fonctionnalité qui bride ses capacités de dimensionnement en puissance informatique. A l'inverse, l'autoscaling sur Fargate est théoriquement infini puisqu'AWS crée une nouvelle machine virtuelle par tâche autant de fois que cela est nécessaire", explique Cyril Parisot. "C'est techniquement simple car il n'y a pas de gestion d'état, donc il est plus simple de commissionner ou décommissionner des ressources. C'est aux développeurs gérer cet aspect via une base de données ou le système de stockage Amazon EFS pour les volumes. Côté Azure Service Fabric, tout doit scaler simultanément, notamment les volumes, ce qui introduit une plus grande complexité."

Caas managé, y aller ou pas ?

Pour l'heure Microsoft accuse encore du retard sur Amazon Web Services. Azure Service Fabric Mesh est toujours une bêta, ce qui veut dire qu'il n'est disponible que sur quelques régions Azure et n'offre pour l'heure aucune garantie de qualité de service.

Faut-il mettre en production des applications sur ces plateformes encore relativement jeunes ? De plus en plus d'entreprises franchissent le pas. Pour Cyril Parisot, c'est avant tout une question de maturité de l'entreprise vis-à-vis des containers. "Pour exécuter une série de microservices représentant quelques dizaines de containers, il sera en général plus simple de démarrer avec AWS Fargate ou Azure Service Fabric Mesh. C'est certain. S'il faut en gérer un plus grand nombre, je pense qu'il vaut mieux d'orienter vers des solutions plus matures comme EKS ou un cluster Kubernetes en propre pour avoir un contrôle total de la plateforme d'exécution." Pour Cyril Parisot, opter pour un Caas impose certains choix d'architecture. "Pour prendre un exemple, sur Fargate, si une entreprise souhaite disposer d'une registry privée, la seule solution disponible est d'utiliser l'outil de credentials propre AWS, Secret Manager. Ce choix liera votre architecture à AWS avec le risque de rester pieds et poids liés à ce provider."

Marc Bolojy insiste : "Fargate est une plateforme totalement stateless. Cela implique une plus grande maturité des équipes applicatives, et une capacité à créer une application dont l'état est totalement délégué à d'autres services managés. C'est une contrainte forte mais qui offre l'accès à une scalabilité extrêmement puissante." Pour doter Service Fabric Mesh d'une couche de persistance, Microsoft propose notamment son service cloud de base de données Azure Cosmos DB. Quant à AWS, il met en avant RDS ou Dynamo DB. Des choix techniques, sortant du standard des containers logiciels, qui contribueront par conséquent à piéger les DSI.