The Art of Kubernetes

Multi-cluster Kubernetes : pourquoi et comment gérer plusieurs clusters

2024-09-15T00:00:00+02:00

Il est possible que vous ressentiez le besoin de disposer de plusieurs clusters Kubernetes. Cela implique, ni plus ni moins, d'avoir plusieurs control planes, donc plusieurs cerveaux.

Pourquoi utiliser plusieurs clusters Kubernetes ?

Le besoin le plus répandu est l'isolation des ressources par environnement. Il est essentiel de bien définir ce que chaque environnement inclut ou exclut. Les équipes applicatives auront besoin, au minimum, d'un environnement de développement, d'un environnement de test fonctionnel, d'un environnement de pré-production (staging) et, bien entendu, d'un environnement de production pour livrer le produit aux clients. Il est également envisageable d'ajouter un environnement d'intégration, qui permet de vérifier la compatibilité entre les différentes applications et leurs dépendances, ou encore un environnement de performance, conçu pour tester la robustesse du produit dans des conditions identiques à celles de la production, sans impacter les autres environnements.

Un autre besoin réside dans l'isolation des données par zone géographique. Il serait, par exemple, non conforme de faire communiquer la charge de travail d'un cluster en Europe avec celle d'un cluster situé aux États-Unis. Pour répondre à ce besoin, vous pouvez instancier un cluster par zone, qui agit comme un isolant des données. C'est aussi une approche courante pour faire de l'edge computing avec Kubernetes.

Répartir les charges de travail avec KubeStellar

Maintenant que vous disposez de plusieurs clusters, vous souhaiterez probablement répartir vos charges de travail de manière optimisée entre ces différents environnements. Un outil particulièrement intéressant pour cela est KubeStellar. Il présente l'avantage de ne nécessiter aucune modification de l'architecture de vos clusters Kubernetes existants, et permet de centraliser la gestion de l'ensemble des ressources de vos clusters depuis un point unique.

Fédérer ses clusters : le modèle Hub and Spoke du SIG Multicluster

Vous envisagez peut-être aussi d'interconnecter vos clusters, notamment pour mutualiser certains services de vos plateformes afin de réduire les coûts. Un Special Interest Group (SIG) nommé Multicluster se penche sur cette problématique et propose des recommandations, des bonnes pratiques ainsi qu'une ligne de conduite pour y répondre.

L'idée centrale consiste à fédérer plusieurs clusters Kubernetes afin de gérer les charges de travail de manière centralisée via une API Kubernetes unique. Dans cette approche, un cluster joue le rôle de « Hub » (cluster central) et communique avec des clusters dits « Spoke » (clusters satellites). Ce modèle de distribution, connu sous le nom de Hub and Spoke, est soutenu par plusieurs extensions de l'API Kubernetes :

une CRD Work représente une charge de travail constituée de plusieurs manifestes, ainsi que le cluster Spoke cible sur lequel elle doit être déployée. Un contrôleur, appelé Work Controller, prend en charge le déploiement de cette charge sur le cluster désigné ;
les CRD ServiceExport et ServiceImport gèrent la partie réseau des services, en représentant respectivement l'exposition d'un service et son importation. Conceptuellement proches des objets Service, ils sont spécifiquement adaptés aux environnements multi-cluster.

Fédération de clusters avec une architecture Hub and Spoke : les objets Work sont déployés dans l'API centrale et les contrôleurs des clusters satellites prennent en charge leur déploiement. Les Pods de clusters différents ne communiquent qu'au travers des services exposés par ServiceExport et ServiceImport.

Avantages et limites de l'approche Hub and Spoke

Cette stratégie multi-cluster comporte plusieurs avantages notables. Tout d'abord, il s'agit d'une solution portée par le projet Kubernetes, qui devrait donc continuer à évoluer et à être maintenue dans les années à venir. Ensuite, elle peut être mise en place même après le déploiement de plusieurs clusters, et peut ainsi être vue comme une amélioration naturelle de votre infrastructure. Enfin, elle répond au besoin de distribution de charge sur plusieurs localisations avec des exigences d'interconnexion moindres qu'une stratégie d'extension de clusters.

Sa limite : les Pods des différents clusters ne communiquent pas directement entre eux. Il est nécessaire de mettre en place le système ServiceExport / ServiceImport pour qu'ils puissent interagir avec les services des autres clusters.

Interconnecter ses clusters : Liqo et Submariner

Il existe également d'autres solutions, certes moins « officielles », mais redoutablement efficaces.

Liqo

Si vous avez besoin d'interconnecter vos clusters afin que les applications déployées sur un cluster puissent découvrir les services d'un autre comme s'ils faisaient partie du même cluster, Liqo est un outil minimaliste, open source et facile à prendre en main. Il permet également une certaine gestion de la répartition des charges de travail entre les clusters interconnectés, et se distingue par sa simplicité de déploiement, puisqu'il ne requiert aucune modification des configurations existantes des clusters.

Intégrer plusieurs clusters hétérogènes, notamment gérés par différents fournisseurs Cloud, peut toutefois rendre sa configuration et sa gestion plus complexes. De plus, la latence des interconnexions réseau peut varier en fonction des distances géographiques entre les clusters, ce qui impacte les performances des applications distribuées.

Submariner

Submariner, projet incubé par la CNCF, est spécialisé dans l'interconnexion sécurisée et performante des clusters, mais sans gestion de charge distribuée. Il a été développé pour répondre aux défis de la connectivité réseau dans des environnements multi-cluster, et vise les déploiements qui nécessitent une communication entre clusters tout en maintenant une stricte isolation réseau.

Submariner établit une connectivité transparente en configurant automatiquement des tunnels sécurisés et performants : les Pods d'un cluster accèdent aux services d'un autre comme s'ils étaient sur le même réseau. Ce qui le différencie, c'est son approche décentralisée, qui ne nécessite aucun point de gestion central pour orchestrer la connectivité, ce qui renforce la disponibilité du réseau.

D'un point de vue technique, Submariner repose sur des tunnels VPN chiffrés, utilisant des technologies éprouvées comme IPsec ou WireGuard, qui garantissent une communication sécurisée entre les clusters Kubernetes. Cette approche facilite l'extension des réseaux tout en maintenant des niveaux de sécurité élevés.

Multi-cluster et Platform as a Service

Le concept de Platform as a Service (PaaS), au cœur de The Art of Kubernetes, est parfaitement compatible avec une architecture multi-cluster et vous laisse une certaine liberté quant à son implémentation : une plateforme par cluster, ou seulement une partie de la plateforme par cluster, en mutualisant certains services et outils sur d'autres clusters.

Encore une fois, il est préférable de limiter au strict minimum le nombre d'outils et de services d'une plateforme, ainsi que le nombre d'instances associées. Bien que plusieurs outils de gestion permettent de gagner du temps dans l'exploitation des services, restez vigilant quant à la complexité supplémentaire qu'ils ajoutent à la suite logicielle que vous devrez maîtriser.

Adoptez une approche pragmatique : concentrez-vous sur les niveaux de service que la plateforme fournit, plutôt que sur la multiplication des outils, des services et des fonctionnalités.

Qu'est-ce que Kubernetes ? Bien plus qu'un orchestrateur de conteneurs

2024-09-09T00:00:00+02:00

Depuis quelques années, Kubernetes est présenté comme la technologie incontournable. Pourtant, si l'on s'en tient à sa définition stricte, il ne s'agit « que » d'un orchestrateur de conteneurs. Alors, pourquoi cette solution s'est-elle imposée comme indispensable dans tant d'entreprises depuis plus de dix ans ?

La conteneurisation a transformé la gestion des infrastructures

La conteneurisation, couplée à l'architecture microservices, a profondément transformé le paysage de la gestion des infrastructures. Elle a facilité la gestion du cycle de vie des applications tout en rendant leur déploiement et leur évolution plus efficaces. Cette architecture Cloud Native a progressivement remplacé les approches de virtualisation traditionnelle, plus lourdes.

Kubernetes a été conçu pour orchestrer ces conteneurs, en mettant un accent particulier sur la résilience et la performance. Il intègre des mécanismes permettant, par exemple, de redémarrer automatiquement les conteneurs défaillants ou de faire évoluer dynamiquement leur nombre pour absorber des pics de charge. Il est toutefois important de noter que certains aspects comme la sécurité, bien qu'essentiels, ne sont pas fournis nativement par Kubernetes.

Les principales fonctionnalités de Kubernetes.

Flexibilité et extensibilité : les clés du succès de Kubernetes

Ce qui a véritablement permis à Kubernetes de surpasser ses concurrents réside dans sa flexibilité et son extensibilité.

D'une part, Kubernetes offre une grande flexibilité grâce à son architecture modulaire, qui permet de choisir et d'adapter ses composants en fonction des besoins spécifiques de chaque entreprise. Par exemple, bien que Kubernetes définisse un modèle réseau à respecter, il laisse une liberté totale quant à son implémentation via des solutions compatibles comme Cilium.

D'autre part, en tant que projet open source, Kubernetes bénéficie d'une communauté dynamique qui développe rapidement des extensions pour enrichir ses fonctionnalités. Il est ainsi extrêmement facile d'ajouter, par exemple, l'extension CoreDNS pour permettre la découverte automatique des services au sein du cluster.

Grâce à cette flexibilité et à cette extensibilité, Kubernetes répond non seulement aux attentes d'une infrastructure Cloud Native moderne, mais garantit également un très haut niveau de qualité de service.

De l'infrastructure à la plateforme (PaaS)

L'association de l'architecture Cloud Native et de la puissance de Kubernetes change fondamentalement la perception de l'infrastructure. Celle-ci n'est plus seulement un socle technique pour faire fonctionner les applications : elle devient une véritable plateforme capable de fournir des services et des outils standardisés.

Ces outils simplifient la gestion du cycle de vie des applications : l'intégration d'un service de déploiement continu (Continuous Delivery), par exemple, permet de déployer automatiquement les services applicatifs. Par ailleurs, des services prêts à l'emploi, comme une base de données, peuvent être déployés facilement dans Kubernetes, notamment grâce aux Operators.

Kubernetes est bien plus qu'un simple orchestrateur de conteneurs : c'est un outil de choix pour la mise en œuvre de plateformes.

Aujourd'hui, il est possible d'implémenter des plateformes sur mesure, adaptées à chaque entreprise et offrant des niveaux de service élevés. Une plateforme en tant que service (Platform as a Service) ne représente pas seulement un atout technique, mais également un levier organisationnel : elle constitue un cadre efficace de communication et de collaboration entre les équipes applicatives et celles en charge de l'infrastructure.

En résumé

Kubernetes est une solution technologique conçue pour gérer de manière résiliente et performante des charges de travail conteneurisées. Grâce à son architecture flexible et extensible, couplée à une infrastructure Cloud Native, il se positionne comme un outil de choix pour la mise en œuvre de plateformes, et il excelle notamment dans la gestion du cycle de vie des applications.

Dans The Art of Kubernetes, j'explique comment devenir des artisans de l'infrastructure, en affinant nos solutions pour optimiser l'infrastructure grâce à Kubernetes.

Edge computing avec Kubernetes : architectures et outils

2024-08-14T00:00:00+02:00

Comment Kubernetes peut-il orchestrer des ressources dispersées au plus près des utilisateurs ? Voici ce qu'il faut savoir sur l'edge computing et sur les architectures possibles avec Kubernetes.

Qu'est-ce que l'edge computing ?

L'edge computing, ou informatique en périphérie, est une approche décentralisée du traitement des données : le calcul et le stockage sont effectués au plus près de la source de production des données, plutôt que dans un centre de données centralisé. Cette architecture permet de réduire la latence, d'améliorer la réactivité des applications et de gérer les données plus efficacement en local, avant de les transférer éventuellement vers un cloud centralisé pour un traitement approfondi ou un stockage à long terme.

En rapprochant la puissance de calcul des utilisateurs finaux, l'edge computing est particulièrement adapté aux environnements qui nécessitent une prise de décision en temps réel, comme l'Internet des objets (IoT), les véhicules autonomes ou les systèmes industriels intelligents.

Réduire la latence en traitant les données localement

Netflix a été l'une des premières entreprises à installer des points de présence chez les fournisseurs d'accès à Internet (FAI), avec son réseau Open Connect : les films et séries sont stockés au plus près des utilisateurs, ce qui garantit une lecture optimale partout dans le monde.

Sans aller jusqu'à déployer des points de présence chez les FAI, ce qui n'est pas à la portée de toutes les entreprises, une architecture edge peut être réalisée sur plusieurs zones géographiques au sein de votre fournisseur d'infrastructure.

L'un des principaux avantages de l'edge computing réside dans sa capacité à réduire la latence en traitant les données localement.

Dans des secteurs tels que l'IoT, les véhicules autonomes ou les réseaux de capteurs industriels, la rapidité de traitement est essentielle. En utilisant Kubernetes pour orchestrer ces environnements, les entreprises peuvent déployer des microservices et des applications conteneurisées directement en périphérie du réseau. Cette approche réduit les temps de réponse et optimise l'utilisation de la bande passante, en évitant l'envoi de volumes massifs de données vers des centres de données centraux.

Pourquoi Kubernetes est adapté à l'edge computing

Kubernetes se révèle être un outil puissant pour orchestrer et gérer ces environnements décentralisés, où les ressources sont dispersées géographiquement et où les exigences en matière de latence, de bande passante et de résilience sont particulièrement critiques.

Il offre d'abord une grande flexibilité pour déployer et gérer des applications sur les infrastructures hétérogènes typiques de l'edge. Que les ressources disponibles se trouvent sur des serveurs locaux, des dispositifs IoT ou de petits datacenters régionaux, Kubernetes maintient une gestion et une orchestration homogènes des conteneurs. Cette standardisation facilite la scalabilité horizontale, essentielle dans un contexte où la capacité de réponse doit s'adapter rapidement aux fluctuations de la demande.

Kubernetes renforce aussi la résilience des infrastructures edge en assurant une gestion autonome des défaillances. En déployant des applications sur plusieurs nœuds en périphérie, il garantit la continuité des services, même en cas de panne de l'un des nœuds. Cette tolérance aux pannes est cruciale pour les applications critiques qui ne peuvent se permettre aucun temps d'arrêt, comme la gestion des urgences ou les opérations industrielles.

Quatre approches pour faire de l'edge computing avec Kubernetes

L'implémentation de l'edge computing avec Kubernetes peut prendre plusieurs formes, selon les besoins de l'entreprise et l'architecture sous-jacente.

Des clusters Kubernetes en périphérie

La manière la plus directe consiste à déployer des points de présence sous forme de clusters Kubernetes en périphérie, répartis sur différents sites, chacun autonome mais interconnecté. Cette configuration est idéale lorsque chaque site a des exigences spécifiques en matière de traitement des données, mais qu'une certaine coordination entre les sites reste nécessaire. Les outils présentés dans notre article sur le multi-cluster Kubernetes s'appliquent alors directement.

Étendre un cluster avec des nœuds distants

Une autre approche consiste à étendre un cluster Kubernetes centralisé vers les périphéries du réseau, en utilisant des nœuds distants pour exécuter les charges de travail propres à l'edge. La répartition des charges de travail selon des règles métier est déjà implémentée et documentée dans Kubernetes. Cette méthode permet de centraliser la gestion tout en déployant des services là où ils sont le plus nécessaires.

Fédérer plusieurs clusters

La fédération de clusters est un cas particulier de gestion de plusieurs clusters : Kubernetes permet de gérer plusieurs clusters distribués comme une seule entité cohérente. Cette approche est particulièrement efficace pour orchestrer des déploiements multi-régionaux, où les applications doivent être disponibles et réactives dans plusieurs emplacements géographiques.

Des plateformes edge clés en main : KubeEdge et Open Horizon

De nombreuses entreprises intègrent Kubernetes avec des plateformes edge spécialisées telles que KubeEdge ou Open Horizon, conçues pour faciliter le déploiement et la gestion des applications sur des infrastructures distribuées. Ces plateformes ajoutent des fonctionnalités spécifiques aux contraintes de l'edge, comme la gestion d'une connectivité réseau intermittente ou l'intégration avec des dispositifs IoT.

Si vous disposez des ressources en interne, il est également possible de développer votre propre solution edge à partir de Kubernetes. Mais à ce stade, vous faites sans doute déjà partie des experts de Kubernetes !

Conclusion

L'edge computing avec Kubernetes ouvre la voie à des architectures plus réactives, résilientes et flexibles, qui répondent aux exigences croissantes des entreprises en matière de traitement des données en temps réel. Kubernetes permet non seulement de tirer parti des avantages de l'edge computing, mais aussi de standardiser la gestion des ressources à travers des infrastructures dispersées, tout en maintenant une cohérence opérationnelle à l'échelle mondiale.

Operator ou pas Operator ? Avantages et limites des Operators Kubernetes

2024-08-01T00:00:00+02:00

Kubernetes est conçu pour prendre en charge tout type d'application conteneurisée de manière performante et résiliente. Sa flexibilité constitue un atout majeur : elle lui permet d'étendre ses fonctionnalités afin de supporter les divers services et outils d'une plateforme, tout en optimisant l'utilisation des ressources d'infrastructure d'une entreprise.

Gérer le cycle de vie des applications dans Kubernetes

Les outils intégrés à une plateforme facilitent la gestion du cycle de vie des applications et des services. Par exemple, un bon système de déploiement continu (CD) permet de gérer efficacement les déploiements au sein de votre parc.

Un autre système de gestion du cycle de vie des applications s'est imposé dans l'écosystème Kubernetes : celui des Operators. Ces derniers occupent désormais une place centrale en automatisant la gestion d'applications complexes directement au sein du cluster Kubernetes.

Comme je le développe dans The Art of Kubernetes, Kubernetes et son écosystème permettent de définir des plateformes efficaces pour chaque entreprise, avec les outils adaptés pour gérer le cycle de vie des applications et des services. Pour des raisons que je vais détailler, je recommande pourtant de recourir aux Operators uniquement dans des cas spécifiques. Dans d'autres situations, vous pouvez facilement gérer le service vous-même ou opter pour un service externalisé.

Qu'est-ce qu'un Operator Kubernetes ?

Un Operator est une extension de Kubernetes qui encapsule la logique opérationnelle d'une application spécifique dans des contrôleurs personnalisés, en s'appuyant sur des Custom Resource Definitions (CRD), une fonctionnalité de Kubernetes qui permet de définir de nouvelles ressources. C'est en quelque sorte un « opérateur humain » codifié, capable de gérer des tâches complexes telles que le déploiement, la mise à jour, la sauvegarde, la restauration et même la mise à l'échelle de l'application, le tout de manière automatisée.

Un Operator surveille ces ressources personnalisées et réagit aux événements associés en exécutant des actions prédéfinies pour gérer l'état de l'application. Il gère ainsi le cycle de vie d'une application ou d'un service, stateful ou stateless, de son installation à sa désinstallation, en passant par ses différents états fonctionnels. Il ajoute une couche de logique supplémentaire entre l'administrateur et l'application, ce qui nécessite des droits élevés, au minimum équivalents à ceux de l'administrateur du service concerné.

Prenons l'exemple de l'Operator PostgreSQL CloudNativePG. Il met à disposition de l'administrateur du cluster des CRD comme Cluster, Backup ou ScheduledBackup. Pour déployer un cluster PostgreSQL à l'intérieur de votre cluster Kubernetes, il suffit de créer un objet Cluster dans l'API Kubernetes avec les bons paramètres, puis de laisser l'Operator faire sa magie : il déploiera les Pods, Services et PersistentVolumes nécessaires pour obtenir un cluster PostgreSQL fonctionnel.

L'automatisation, une arme à double tranchant

L'avantage principal des Operators réside dans leur capacité à automatiser des tâches complexes qui, autrement, nécessiteraient une intervention humaine. Par exemple, la mise à jour d'une base de données stateful, avec toutes ses spécificités, peut être entièrement gérée par un Operator, minimisant ainsi les risques d'erreurs.

Si les Operators automatisent l'exploitation d'un service, ils posent également un défi en déléguant les décisions critiques à un logiciel plutôt qu'à un expert humain.

Cependant, ce même avantage peut se transformer en inconvénient : l'administrateur risque de se reposer entièrement sur l'Operator et de perdre la connaissance approfondie de la logique de l'application. Il pourrait alors négliger la documentation et ne plus maîtriser suffisamment l'application pour la déployer et la maintenir en état de fonctionnement, ce qui pourrait avoir des conséquences graves en cas de problème majeur. L'opérateur humain doit rester expert des services qu'il administre.

C'est un peu comme balayer la poussière sous le tapis : la poussière est toujours là, et vous risquez toujours d'y être allergique. Il n'existe pas de raccourci pour maîtriser un logiciel et atteindre un haut niveau de service : cela nécessite une solide expertise, de la pratique, ainsi qu'un investissement en temps.

Les choix que vous déléguez à un Operator ne vous exemptent pas d'en assumer les conséquences, qu'elles soient positives ou négatives.

Standardisation et reproductibilité : une promesse trompeuse ?

Les Operators jouent un rôle essentiel dans la standardisation de la gestion des applications et des services, en garantissant que les meilleures pratiques sont appliquées de manière cohérente à travers différents environnements. Cette reproductibilité s'avère particulièrement utile dans des contextes multi-environnements ou multi-clusters, où il est crucial que les applications soient déployées et maintenues de manière uniforme.

Cette standardisation peut cependant s'avérer trompeuse. En ajoutant une couche automatisée qui gère le cycle de vie du logiciel, comment être certain que ce logiciel se trouve dans le même état dans deux environnements différents ? Cela devient presque impossible si vous ne contrôlez pas l'ensemble de l'état de l'Operator, qui dépend de tout l'environnement. Cela pose un réel problème dans les environnements d'intégration continue (CI), où la reproductibilité et l'idempotence sont des notions essentielles pour garantir la fiabilité des résultats.

Des Operators qui ne couvrent pas tous les besoins

Les Operators disponibles ne couvrent pas nécessairement l'ensemble des besoins opérationnels d'une application. Il est donc possible qu'un Operator limite votre capacité à maintenir le service dans un état pleinement fonctionnel. Une migration de l'application ou du service est-elle prise en compte par l'Operator ? Et même si c'est le cas, préférez-vous effectuer la migration à l'aide d'un Operator automatisé ou d'un opérateur humain ?

Résilience : qui décide en cas d'incident ?

En automatisant la gestion des erreurs et en surveillant continuellement l'état des applications, les Operators contribuent à améliorer la disponibilité et la résilience des services. Un Operator peut par exemple détecter un dysfonctionnement et prendre automatiquement des mesures correctives, comme le redémarrage d'un composant défaillant ou la restauration à partir d'une sauvegarde.

Mais là encore, le choix de la résolution des dysfonctionnements est laissé à un composant logiciel plutôt qu'à un expert de l'application. Cette automatisation peut entraîner l'application dans un état non seulement indésirable, mais aussi problématique, sans possibilité de retour en arrière.

Le vrai intérêt : des Operators sur mesure pour vos applications

Je vais probablement m'écarter de ce que vous avez déjà entendu à propos des Operators, mais je pense que leur efficacité et leur utilité résident dans les Operators personnalisés pour vos propres applications. En développant un Operator adapté à vos besoins, vous pouvez l'utiliser facilement comme un service au sein de votre plateforme Kubernetes, sans dépendre de nombreux outils tiers. La logique de gestion du cycle de vie de vos applications étant intégrée dans l'Operator, vous pouvez instancier votre application aisément pour la tester depuis une autre plateforme.

Attention cependant : le développement d'un Operator peut s'avérer complexe et nécessite une compréhension approfondie de Kubernetes. Cette complexité peut constituer une barrière à l'adoption, en particulier pour les petites équipes ou les entreprises qui ne disposent pas des compétences nécessaires en interne.

Maintenance et charge cognitive : le coût caché des Operators

Comme tout composant logiciel de votre cluster, un Operator doit être maintenu, mis à jour et corrigé en cas de bugs ou de vulnérabilités. Cela implique un effort de maintenance continu, qui peut devenir coûteux si l'Operator est complexe ou s'il doit évoluer avec l'application qu'il gère. Cet effort doit également être pris en compte dans les cas critiques, comme une migration de l'application.

Pour les équipes qui gèrent déjà un grand nombre d'outils et de services, l'ajout d'Operators peut aussi contribuer à une surcharge cognitive. Comprendre et gérer les différents Operators déployés dans un cluster peut devenir complexe, en particulier lorsque chacun a ses propres configurations et comportements.

Conclusion : utiliser les Operators avec parcimonie

Les Operators sont aujourd'hui très (voire trop) répandus : plus de 277 étaient déjà référencés sur OperatorHub en 2024, et il est désormais possible de déployer presque n'importe quel composant logiciel open source avec un Operator. Il est cependant crucial de bien peser les avantages et les inconvénients d'un Operator par rapport à d'autres méthodes pour gérer le cycle de vie d'un composant logiciel.

Je vous recommande donc d'utiliser les Operators avec parcimonie : principalement pour transformer vos propres applications en services au sein d'une plateforme, et dans les cas où vous n'avez pas d'autre choix.