Où votre application va-t-elle s'exécuter ? Serveur, Conteneur, Serverless ou Edge

Vous avez construit une application. Elle fonctionne sur votre ordinateur portable. Maintenant, vous devez la placer quelque part où d'autres personnes peuvent l'utiliser. Cette question simple — « où cette application va-t-elle vivre ? » — façonne tout ce qui concerne la façon dont vous construisez, testez et livrez votre logiciel.

La réponse est rarement unique. Peut-être que votre application s'exécute sur un serveur physique dans un placard au bureau. Peut-être qu'elle s'exécute sur une machine virtuelle dans le cloud. Peut-être qu'elle est empaquetée dans un conteneur géré par Kubernetes. Peut-être qu'elle s'exécute comme une fonction serverless qui n'existe que lorsque quelqu'un l'appelle. Ou peut-être qu'elle doit s'exécuter en périphérie (edge), près de l'utilisateur, sur un appareil IoT ou un nœud réseau.

Chacune de ces cibles modifie la façon dont vous concevez votre pipeline CI/CD. Les outils sont importants, mais la question plus profonde concerne ce que votre pipeline doit gérer. Passons en revue chaque cible et voyons ce qui change.

Déploiement sur des serveurs : physiques ou virtuels

Lorsque vous déployez directement sur un serveur, votre pipeline doit gérer la pile complète. Vous ne livrez pas seulement du code. Vous livrez une application qui nécessite un système d'exploitation spécifique, un intergiciel (middleware) spécifique, des versions spécifiques de bibliothèques et des fichiers de configuration spécifiques.

Votre processus de build produit généralement un binaire, un package ou un ensemble de fichiers. Votre pipeline transfère ensuite ces fichiers vers le serveur, les installe et redémarre l'application. Le rollback consiste à remplacer les fichiers ou à revenir à une version précédente sur la même machine.

Le pipeline pour les déploiements sur serveur a tendance à être plus long. Vous avez besoin d'étapes pour provisionner le serveur, installer les dépendances, configurer l'environnement et vérifier que tout fonctionne ensemble. Si vous gérez plusieurs serveurs, vous devez également coordonner les mises à jour entre eux.

L'avantage est le contrôle. Vous décidez exactement ce qui s'exécute sur la machine. L'inconvénient est que chaque serveur devient un flocon de neige. De petites différences entre les environnements — une version de bibliothèque légèrement différente, un fichier de configuration modifié manuellement — peuvent causer des problèmes difficiles à reproduire.

Déploiement dans des conteneurs

Les conteneurs changent la donne. Votre application et toutes ses dépendances sont empaquetées dans une image. Cette image est construite une fois et déployée partout. L'environnement à l'intérieur du conteneur est cohérent entre le développement, les tests et la production.

Votre pipeline change de focus. Au lieu de gérer la configuration du serveur, vous vous concentrez sur la construction de l'image, son stockage dans un registre et son déploiement sur une plateforme d'orchestration comme Kubernetes. Le rollback devient plus simple : il suffit de pointer vers une version d'image précédente.

Mais de nouveaux défis apparaissent. Vous devez vous assurer que l'image est sécurisée. Vous devez gérer les versions et les tags des images. Vous devez mettre à jour les conteneurs en cours d'exécution sans interrompre le trafic. Vous devez également gérer les composants avec état (stateful) comme les bases de données, qui ne s'intègrent pas parfaitement dans le modèle de conteneur.

Les conteneurs offrent cohérence et portabilité. Mais ils nécessitent une compréhension des environnements d'exécution de conteneurs, de l'orchestration et du réseau. Votre équipe doit apprendre à déboguer les problèmes qui se produisent à l'intérieur d'un conteneur, pas seulement sur un serveur.

Déploiement en serverless

Le serverless pousse l'abstraction encore plus loin. Vous ne pensez pas du tout aux serveurs. Vous écrivez une fonction, vous la téléchargez sur une plateforme, et la plateforme gère l'exécution, la mise à l'échelle et la disponibilité.

Votre pipeline devient plus simple à certains égards. Vous avez juste besoin d'empaqueter le code de votre fonction et de le déployer. Il n'y a pas de serveur à provisionner, pas de système d'exploitation à configurer, pas de conteneur à gérer.

Mais les défis se déplacent vers d'autres domaines. Comment gérez-vous les versions de fonctions ? Comment configurez-vous les variables d'environnement et les secrets ? Comment testez-vous votre fonction lorsque l'environnement d'exécution n'est pas entièrement sous votre contrôle ? Comment gérez-vous les démarrages à froid (cold starts), où une fonction met plus de temps à répondre parce qu'elle n'a pas été appelée récemment ?

Le serverless fonctionne bien pour les charges de travail pilotées par les événements, les API avec un trafic variable et les tâches qui s'exécutent de manière intermittente. Il réduit la charge opérationnelle mais limite votre contrôle sur l'environnement d'exécution.

Déploiement en périphérie (Edge)

Le déploiement en périphérie ajoute un type de complexité différent. Votre application doit s'exécuter dans de nombreux emplacements, souvent avec des ressources limitées. Pensez aux appareils IoT, aux routeurs, aux nœuds CDN ou aux systèmes de point de vente.

Votre pipeline doit gérer la distribution des mises à jour vers des milliers ou des millions d'appareils. Certains appareils peuvent être hors ligne lorsque vous poussez une mise à jour. Certains peuvent avoir des connexions réseau peu fiables. Certains peuvent fonctionner sur du matériel que vous ne pouvez pas remplacer facilement.

Le rollback en périphérie est difficile. Vous ne pouvez pas simplement actionner un interrupteur et revenir en arrière sur tous les appareils à la fois. Vous avez besoin de stratégies pour les déploiements progressifs, pour gérer les appareils qui manquent des mises à jour et pour récupérer les appareils qui échouent après une mise à jour.

Le déploiement en périphérie ne concerne pas seulement le logiciel. Il s'agit de logistique. Comment garantir qu'un appareil dans un emplacement distant reçoive la bonne version ? Comment surveiller les appareils qui ne sont pas toujours connectés ? Comment gérer les appareils qui manquent d'espace de stockage ou de mémoire ?

La cible n'est pas permanente

Voici le fait : votre cible de déploiement n'est pas une décision permanente. La même application peut se déplacer entre les cibles au fil du temps. Vous pouvez commencer avec un serveur physique, passer à une machine virtuelle, puis à des conteneurs, et plus tard diviser des parties de l'application en fonctions serverless.

Chaque déplacement modifie votre pipeline. Le processus de build change. La stratégie de déploiement change. Le mécanisme de rollback change. Les exigences de surveillance et d'observabilité changent.

La clé est de comprendre ce que chaque cible exige de votre pipeline, pas seulement les outils à utiliser. Lorsque vous connaissez les implications, vous pouvez concevoir un pipeline qui correspond à vos besoins réels, pas seulement à la dernière tendance.

Liste de contrôle pratique pour choisir une cible de déploiement

Avant de vous engager sur une cible, parcourez ces questions :

Le diagramme suivant peut vous aider à visualiser comment vos réponses à ces questions mènent à une cible de déploiement.

flowchart TD A[Début : Quels sont vos besoins ?] --> B{Contrôle total sur l'environnement ?} B -- Oui --> C[Serveur : physique ou VM] B -- Non --> D{Environnement cohérent entre les déploiements ?} D -- Oui --> E[Conteneur : Docker, Kubernetes] D -- Non --> F{Piloté par événements ou trafic variable ?} F -- Oui --> G[Serverless : fonctions] F -- Non --> H{Nombreux emplacements distribués ?} H -- Oui --> I[Edge : IoT, CDN] H -- Non --> J[Réévaluer les exigences] C --> K[À considérer : provisionnement, gestion config, complexité rollback] E --> L[À considérer : sécurité image, orchestration, services avec état] G --> M[À considérer : démarrages à froid, contrôle limité runtime, tests] I --> N[À considérer : mises à jour hors ligne, déploiements progressifs, gestion appareils]
  • Où votre équipe a-t-elle le plus d'expérience ? Une équipe qui maîtrise bien les serveurs aura moins de difficultés avec le déploiement sur serveur qu'avec Kubernetes.
  • De quel niveau de contrôle avez-vous besoin sur l'environnement d'exécution ? Plus de contrôle signifie plus de complexité du pipeline.
  • Comment allez-vous gérer le rollback ? Certaines cibles facilitent le rollback (conteneurs), d'autres le rendent pénible (appareils en périphérie).
  • Comment allez-vous tester le déploiement ? Les environnements serverless et edge sont plus difficiles à reproduire localement.
  • Quel est votre modèle de trafic ? Un trafic régulier favorise les conteneurs ou les serveurs. Un trafic irrégulier favorise le serverless.
  • Combien d'instances devez-vous gérer ? Quelques serveurs sont gérables. Des milliers d'appareils en périphérie nécessitent une approche différente.

Ce qui importe le plus

La cible de déploiement détermine la forme de votre pipeline. Elle décide ce que votre build produit, comment vos tests s'exécutent, comment vos mises à jour atteignent les utilisateurs et comment vous récupérez après des échecs.

Choisissez en fonction des besoins de votre application, des capacités de votre équipe et de votre réalité opérationnelle. Pas parce que les conteneurs sont populaires ou que le serverless est l'avenir. La bonne cible est celle que vous pouvez exploiter de manière fiable, mettre à jour en toute sécurité et déboguer efficacement lorsque les choses tournent mal.

Votre pipeline doit refléter ce choix, pas lutter contre lui.