Orchestration de conteneurs : quelles différences entre AWS, Google et Azure

ECS : l’intégration avec l’écosystème AWS

Amazon EC2 Container Service (ECS) a bien progressé depuis son lancement il y a maintenant 2 ans. Ce service s’intègre étroitement aux autres services AWS, comme ceux dédiés au stockage, à la sécurité et bien sûr au dimensionnement. Il ajuste les instances en fonction d’événements  et peut être inclus à d’autres outils comme CloudTrail, qui mesure les performances des applications et des conteneurs. ECS supporte aussi Service Auto Scaling.

Le service d’AWS est adapté si tous les composants Cloud sont aussi sur l’infrastructure d’AWS. Mais il peut être par exemple difficile d’orchestrer ECS à partir de flux ou d’événements hors AWS, comme des applications sur des Clouds privés ou des plateformes Saas. ECS est également intégré à CloudFormation pour ajuster le comportement des conteneurs à partir de templates.

Evidemment, les entreprises qui disposent déjà de workloads chez AWS pourront déployer rapidement des applications avec ECS. Mais attention du coup au verrou-vendeur, si tout s’exécute sur une unique plateforme. Il est possible d’utiliser d’autres moteurs d’orchestration pour intégrer cloud public et cloud privé.

Le service d’AWS propose des APIs pour s’intégrer à Kubernetes et Mesos, permettant ainsi la mise en place de scenarii d’orchestration plus complexes et denses. Mais ces possibilités d’intégration n’en sont qu’à leur début. Il manque encore les capacités de contrôle et la facilité de déploiement propre à ECS, en natif.

Google Container Service : pour des déploiements hybrides

Google Container Service (GCS) – qui est en fait une implémentation de Kubernetes – est l’un des moteurs de l’infrastructure interne de Google qui soutient Gmail, Google Search et Google Maps. Ce projet est Open Source et s’adosse à une communauté, ce qui en fait le projet n°1 en termes d’activités sur GitHub. Kubernetes est encadré par la Cloud Native Computing Foundation, en charge de ses développements et de sa gouvernance.

Kubernetes comprend nombre de fonctions pour gérer le dimensionnement de clusters, cela bâti sur des indicateurs de la Google Cloud Platform, d’infrastructures privées et d’autres Clouds. Il est également intégré à Stackdriver Logging pour monitorer les conteneurs et gérer les comportements du cluster.

Ce moteur permet aussi de décrire la configuration du cluster ainsi que les comportements, sous la forme d’un groupe d’objets Kubernetes. Cette méthode permet donc de disposer d’un modèle de données simplifié pour décrire un cluster et ses conteneurs dans le même code JSON. Les fichiers ne sont pas différents.

Actuellement, Google est le seul à facturer en plus son moteur d’orchestration – 0,15$ par heure pour l’orchestration d’un cluster de plus de 6 conteneurs, soit plus de 100$ par mois environ. Cela pourrait être un problème si l’on fait tourner un grand nombre de clusters doté de petits microservices, répartis sur plusieurs conteneurs. Mais l’orchestration n’est qu’une partie des coûts totaux.

Azure Container Service

Azure Container Service (ACS) de Microsoft est disponible depuis 2016. L’éditeur a beaucoup investi pour égaler les fonctions d’AWS et de Google. Son offre initiale ne supportait que les moteurs d’orchestration DCOS (bâti sur Mesos) et Docker Swarm. Désormais, ACS supporte également Kubernetes.

Même mécanique que Google et AWS, ACS peut s’appuyer sur Azure Monitoring pour l’orchestration. Toutefois, à l’inverse des autres outils, les développeurs peuvent choisir entre plusieurs technologies. Les autres fournisseurs de Cloud supportent certes plusieurs moteurs d’orchestration, mais peuvent en limiter l’accès aux services natifs – ce qui a pour effet d’augmenter la complexité en termes d’intégration et de développement.

Microsoft développe une technologie commune pour les clouds public et privé : Azure Stack. Cette démarche vise à simplifier le développement d’applications hybrides qui naviguent entre plusieurs infrastructures.

ACS reprend cette approche, et fonctionne avec plusieurs technologies d’orchestration pour rapprocher les infrastructures privés et publiques. De son côté, ECS ne fonctionne que dans le Cloud d’AWS. GCS quant à lui peut intégrer des Clouds privés avec Kubernetes, mais propose un faible support de Docker Swarm et Mesos.

Les entreprises avec une forte empreinte Microsoft seront probablement attirées par ACS.

Le back-end prime, pas les fonctions

Les fournisseurs de Cloud finissent toutefois par atteindre une certaine parité fonctionnelle. L’année dernière, tous ont amélioré leur capacité de dimensionnement, la gestion, le monitoring et leurs capacités de développement. Et cela se poursuit. Sur le long terme, des gains existent d’autant plus si une meilleure intégration entre les orchestrateurs de conteneurs et les services dits Serverless est mis en place.

Les DSI peuvent certes considérer les nouvelles technologies émergentes d’orchestration de conteneurs. Mais elles seront plus difficiles à intégrer dans les processus de développements que ces moteurs natifs.