The Doppler Quarterly (FRANÇAIS) Été 2018 - Page 26

Restent donc les deux autres options, à savoir l'orchestration de conteneurs et l'architecture sans serveur, deux plateformes légitimement positionnées pour gérer les contraintes que le cloud natif impose aujourd'hui comme demain aux environne- ments informatiques. Orchestration de conteneurs  : ces plateformes, telles que Kubernetes, Swarm ou Mesos, confèrent aux développeurs un pouvoir inatteignable avec le modèle PaaS ou d'autres plate- formes de développement classiques. Ils peuvent en effet construire et déployer des applications portables et les exécu- ter n’importe où, sans avoir à les reconfigurer ou à les redé- ployer sous des environnements différents. Cette capacité offre aux développeurs une flexibilité et un contrôle sans précédent sur les versions et l'emplacement pré- cis des images à déployer. Il leur est possible de superviser les infrastructures en ayant le dernier mot sur les exécutions, la réutilisation d'images et les déplacements des applications conteneurisées vers le cloud. L’inconvénient de l'orchestration de conteneurs ? C'est qu'elle introduit un niveau de complexité supplémentaire dans le pro- cessus. La construction d’un cluster Kubernetes à haute dispo- nibilité est déjà une tâche ardue. L'ajout de nouveaux orchestra- teurs de conteneurs exige que les développeurs soient plus attentifs à des aspects tels que la découverte de services, l'équilibrage de charge, la gestion de capacité, la surveillance, la journalisation, les mises à niveau et d'autres services com- muns. Dès lors, soit les développeurs voient leur travail se mor- celer, soit ils doivent s'en remettre à des orchestrateurs Kuber- netes gérés de type EKS, Fargate, AKS ou GKE, qui induisent un certain degré d’enfermement propriétaire et de retard entre les versions successives. Architecture sans serveur  : les plateformes sans serveurs impliquent des manipulations beaucoup moins nombreuses que les orchestrations de conteneurs. Certains outils tels qu'AWS Lambda, Azure Functions ou IBM Openwhisk per- mettent aux équipes de développement d’écrire une logique sous forme de petits fragments de code qui répondent à des événements spécifiques. L'architecture sans serveur consiste essentiellement en un service géré. Les développeurs peuvent se concentrer sur les applications qui répondent à des déclen- cheurs, en laissant la plateforme se charger de toutes les tâches subalternes, telles que la mise à l'échelle automatique, l'installation de correctifs, l'équilibrage de charge élastique, etc. Cette démarche convient idéalement aux développeurs qui privilégient un modèle de paiement à l’usage qui calcule uni- quement le temps de fonctionnement effectif du code. Cette structure fonctionne bien pour les charges de travail imprévi- sibles ou dépendantes d'événements, tels que les modèles de 24 | THE DOPPLER | ÉTÉ 2018 messagerie, d'IoT et de Big Data. Les couches intermédiaires peuvent être optimisées pour améliorer les performances des applications dans le temps. De plus, l’architecture sans serveur facilite l'intégration aux API et modules d'extension tiers. Mais elle se solde aussi par quelques inconvénients. L'architec- ture sans serveur est un modèle de calcul moins mature, donc moins bien doté en échantillons stables, outils, meilleures pra- tiques et documentations. C'est un modèle plus difficile à déboguer que les autres plateformes. En raison de la structure à la demande, les « démarrages à froid » du système après une période d'inactivité peuvent être à l'origine d'incidents. L'exé- cution des charges de travail sans serveur étant limitée à cinq minutes, tout allongement de cette durée nécessite une orchestration supplémentaire ou une refactorisation sous forme de plusieurs microservices. Décision en faveur d'une solution de plateforme Au vu de ces contraintes, sur quelle plateforme allez-vous jeter votre dévolu ? Il n’y a pas de réponse unilatérale à cette ques- tion, pas plus qu'il n'existe de solution universelle. Certains types de charges de travail s’intègrent mieux à des conteneurs, tandis que d’autres sont plus adaptées aux environnements sans serveur. Vous pouvez répartir