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