Kubernetes au service de votre stratégie applicative

Article rédigé par Maxime Villeger, Cloud Solution Architect (Microsoft)

Aujourd’hui, Kubernetes est sur toutes les lèvres et dans toutes les stratégies applicatives des plus grands groupes. Cependant, même si sa notoriété et ses bénéfices sont nombreux, Kubernetes est – et doit rester – un outil technologique au service de vos applications et non l’inverse ! En effet, le choix de Kubernetes doit être fait en connaissance de cause et non par défaut.

Cassons donc dès à présent certains mythes :

• Micro-service ≠ Conteneurisation
• Conteneur ≠ Kubernetes
• Kubernetes ≠ CaaS
• Kubernetes des Cloud providers (AKS, EKS, GKE…) ≠ PaaS

Posons ensemble une définition d’application Cloud native. Les applications Cloud native sont créées et optimisées pour la mise à l’échelle et les performances Cloud. Elles sont basées sur des architectures de type micro-services, utilisent des services managés et tirent parti d’une livraison continue pour gagner en fiabilité et accélérer la commercialisation.

A ce titre, Kubernetes peut être envisagé mais ne répondra pas à tous les usages et se doit d’être contextualisé ! Autrement dit, Kubernetes seul n’est rien. Il vient avec son écosystème et doit être ancré dans une réalité : les services adjacents du Cloud provider.

Kubernetes, une plateforme parmi les autres

Kubernetes n’est qu’une plateforme applicative au service des applications. On arrive à ce choix non pas parce que c’est le sujet « Tech-Trendy » du moment mais bien parce qu’il correspond à un besoin.

Avant de décider si Kubernetes sera le socle de notre future plateforme applicative dans Azure, il convient de déterminer si c’est effectivement un bon candidat.

Pour évaluer cela, une étape de rationalisation doit être opérée afin de déterminer un arbre de décision concret.

La méthode des 5R de la rationalisation Cloud est alors applicable :

• Réhébergement (rehost): Également appelé migration lift-and-shift, le réhébergement déplace une application vers le Cloud en apportant des modifications minimales à l’architecture globale.
• Refactorisation (refactor): Il est judicieux de refactoriser légèrement une application pour qu’elle corresponde à un modèle PaaS (remplacement de sa base de données, exposition via une API web etc.). La refactorisation peut également s’appliquer au développement même de l’application, dans lequel du code est refactorisé pour permettre de répondre à de nouveaux besoins.
• Réarchitecture (rearchitect): Certaines applications vieillissantes ne sont pas compatibles avec le Cloud en raison de décisions prises lors de leur conception. Dans ce cas, l’application doit subir une réarchitecture avant d’être transformée.
• Reconstruction (rebuild): Dans certains scénarios, les efforts nécessaires à la réarchitecture d’une application peuvent être trop importants pour justifier tout investissement supplémentaire. C’est particulièrement vrai pour les applications qui répondaient autrefois aux besoins de l’entreprise, mais qui ne sont plus prises en charge ou ne sont plus alignées sur les processus métier actuels. Dans ce cas, une nouvelle application est créée pour s’aligner sur l’approche Cloud native by design.
• Remplacement (replace): Parfois, les applications SaaS peuvent fournir toutes les fonctionnalités nécessaires à l’application hébergée. Dans ces scénarios, une charge de travail peut être programmée pour un remplacement futur, ce qui évite tout effort de transformation. Les services de messagerie comme Microsoft Exchange Server ont été d’excellents candidats pour ce type d’approche avec l’offre Microsoft Office 365.

Ces stratégies permettent de définir certains drivers essentiels à la construction de notre arbre de décision quant à notre future plateforme applicative. En effet, si on confronte cette rationalisation au choix d’une plateforme applicative sur Azure nous obtenons l’arbre de décision suivant :

Source : Choose an Azure compute service for your application

En synthèse, nous avons ci-dessus un arbre de décision reprenant des critères pour nous aider à choisir la future plateforme de nos applications dans Azure. AKS (Azure Kubernetes Services) est loin d’être la seule cible. Le résultat est donc un point de départ à prendre en considération. Il reste ensuite à effectuer une évaluation plus détaillée du service et de l’application pour déterminer quelle plateforme est la plus adaptée.

Rappelons que Kubernetes est un orchestrateur de conteneurs : de ce fait, seules les applications conteneurisables sont envisageables. Ensuite, comme on peut le voir sur notre arbre de décision, un conteneur sur Azure peut s’exécuter sur différentes plateformes et ces dernières peuvent coexister sur une même architecture en fonction des besoins.

Nous pouvons donc déjà fixer quelques candidats types pour AKS :

• Les applications tournant déjà sur Kubernetes – lift & shift ;
• Les nouvelles applications que nous développons selon les principes « Cloud natives » ;
• Les applications conteneurisées dont les conteneurs doivent être orchestrés par un orchestrateur de conteneurs – refactor/rebuild.

Pour synthétiser, le tableau ci-dessous devrait vous aider à orienter vos choix en fonction de votre besoin.

Si votre choix de Kubernetes se confirme, une question majeure va alors se poser : lors de la création d’une nouvelle application, est-ce que je veux m’investir dans l’écosystème Kubernetes ? En effet, Kubernetes (AKS, GKE, EKS…) seul ne sera pas suffisant. Il faudra s’appuyer sur un écosystème riche afin d’avoir une couverture complète de votre application avec de multiples domaines à couvrir :

• Sécurisation : Qualys, TwistLock…
• Déploiement : Helm, Flux, Argo-CD, Github Actions
• Observabilité : Elastic search, Prometeus + Graphana, Splunk…
• Gestion des secrets : Cert-Manager, Hashicorp Vault, Azure Secrets Store CSI Driver
• Etc.

Le temps de montée en compétences sur la plateforme Kubernetes peut sembler long afin de parfaitement maîtriser toute la chaîne et ainsi avoir une vraie plateforme robuste, scalable et réplicable pour héberger les applications cibles. Ainsi, pour héberger un front-web ou des APIs, est-ce réellement la bonne stratégie ?

L’écosystème Kubernetes

Un des principaux facteurs de succès d’une plateforme réside dans la taille de son écosystème. C’est une des grandes forces de Kubernetes. Né dans le monde de l’open-source (projet hébergé par la Cloud Native Computing Foundation), cet outil a su rallier tous les acteurs autour de lui pour proposer un écosystème très riche. Microsoft a massivement investi dans cet écosystème, initiant ou participant à de nombreux projets en relation avec Kubernetes. Cet investissement de Microsoft a permis de soutenir de nombreux projets, contribuant ainsi à l’ouverture de l’écosystème de la plateforme Kubernetes.

Source : https://azure.microsoft.com/en-us/topic/what-is-kubernetes/#community

Il faut donc penser « Kubernetes et son écosystème » ! Ainsi, AKS ne doit pas être imaginé seul sur Azure mais bien accompagné de l’ensemble de l’écosystème afin d’avoir une chaîne complète et maîtrisée, du développement jusqu’au maintien en condition opérationnelle.

Comme on le verra dans un article dédié sur le sujet, l’écosystème est vaste. Pour s’en donner une idée, il suffit de consulter le panorama proposé par la Cloud Native Computing Foundation (CNCF). Adopter AKS, c’est en fait adopter un écosystème complet et complexe dont le cluster Kubernetes n’est qu’une petite partie. Nous allons devoir construire notre plateforme en utilisant un certain nombre de ces composants. Les prochains articles de ce Mois du Conteneur vous aideront à vous focaliser sur l’essentiel.

Le rêve d’être « Cloud agnostique »

« La plateforme Kubernetes est agnostique et offre donc une solution au Vendor-Locking » : c’est une illusion !

Comme nous venons de le voir, Kubernetes seul n’est rien : il doit vivre avec son écosystème et la plateforme sur laquelle il tourne. En effet, dès lors qu’on parle d’une application dans un cluster Kubernetes, il faut penser à l’intégration des secrets et certificats, à un référentiel de données, à un réseau, à des mécanismes de filtrage et d’intégration propres au Cloud provider… Même si nous déportons la plupart de ces éléments vers d’autres plateformes (un vault d’Hashicorp, une base de données conteneurisée…), nous restons dépendants de ces nouveaux vendeurs que nous venons d’introduire et l’intégration même à la plateforme reste bel et bien présente. Cela met à mal également le rêve de réversibilité : utiliser Kubernetes seul pour assurer de la réversibilité est illusoire. Il manque un outil de fédération/management faisant abstraction de la plateforme. Une solution comme Azure ARC se positionne pour unifier la gestion des clusters Kubernetes, que ceux-ci soient hébergés dans vos datacenters ou même chez d’autres Cloud providers.

Finalement, ne serait-il pas plus simple d’abstraire l’infrastructure sous-jacente afin de bénéficier de l’agnostique et de la réversibilité ? Voulons-nous que nos applications soient totalement agnostiques ou uniquement portables d’un socle technique à un autre ? Ce n’est pas la même chose.

En effet, aujourd’hui, les développeurs sont à l’aise avec les architectures d’applications web + base de données (par exemple les conceptions classiques à 3 niveaux) mais pas avec les architectures de type micro-services qui sont intrinsèquement distribuées. Les développeurs veulent se concentrer sur la logique d’entreprise tout en s’appuyant sur les plateformes pour que leurs applications soient résilientes, maintenables, élastiques et tous autres attributs des architectures Cloud native. C’est là que Dapr entre en jeu.

Dapr offre des building blocks pour la construction d’applications de micro-services, indépendants, open-source, qui permettent de construire des applications portables avec le langage de programmation et le Cloud provider de votre choix. Chaque bloc est complètement indépendant et vous pouvez en utiliser un, certains ou tous dans votre application. Cela permet de s’affranchir de la cible (que ce soit l’infrastructure de compute mais également la base de données utilisée…) afin de se concentrer la construction même de l’application, conteneurisée ou non.

L’essentiel à retenir

Pour reprendre synthétiquement les grands points de ce billet :

• Kubernetes est au service d’une stratégie applicative : Kubernetes n’est pas LA réponse (42 🙂). Il permet d’assoir une certaine stratégie applicative basée sur l’orchestration de conteneurs dans un monde Cloud natif.
• Kubernetes n’est pas seul : Kubernetes doit être vu comme un écosystème complet et complexe et non uniquement comme un cluster. Il nécessite ainsi une expertise fine et possiblement complexe avant d’être mis en place à l’échelle d’une entreprise.
• Kubernetes ne répond pas « by design » aux exigences de sécurité et de réversibilité… : par défaut, un cluster Kubernetes est très permissif (tout est ouvert, tout est accessible, tout est en clair…), il ne permet pas d’être Cloud agnostique ni vendor-free.

Avant de se lancer dans l’aventure, il conviendra donc de définir la cible applicative à atteindre, que ce soit pour nos applications Legacy que nous allons porter dans le Cloud mais aussi pour les nouvelles applications.

Pour aller plus loin sur Kubernetes

Pour mettre en pratique tout ce que vous avez appris au cours du Mois du Conteneur, Cellenza vous propose de voir le replay du webinaire de clôture. Pendant une heure, Benoît Sautière (Senior Technical Officer chez Cellenza), Stanislas Quastana (Cloud Solution Architect chez Microsoft) et Louis-Guillaume Morand (Cloud Solution Architect chez Microsoft) vous présentent les différentes étapes à suivre pour adopter Kubernetes dans votre entreprise !

Retrouvez également tous les articles du Mois du Conteneur :

• Un mois pour tout savoir sur Kubernetes
• Kubernetes : quel intérêt pour répondre aux enjeux Business ?
• Kubernetes : un écosystème à construire
• Stratégie de CI/CD sur Kubernetes
• Mettre en place sa stratégie de migration vers Kubernetes
• Comment intégrer Kubernetes dans sa stratégie de monitoring ?
• Sécuriser son service Kubernetes

Tous ces articles sont compilés dans un livre blanc téléchargeable gratuitement.

Article rédigé par Maxime Villeger, Cloud Solution Architect (Microsoft) avec Benoit Sautière (Cellenza)