Delivery & run / Mise en production

Déployer en production est toujours un moment de stress. La bonne nouvelle, c’est qu’avec une méthode claire, ce stress peut devenir maîtrisable.

Pourquoi une mise en production fait toujours peur

Une mise en production, c’est une avalanche de questions : Est-ce que j’ai pensé à tout ? Est-ce que j’ai bien testé ? Est-ce que je ne vais pas tout casser ? Est-ce que je ne vais pas perdre mon référencement ?

Et très vite, on se dit : comment je vais continuer à innover, livrer plus vite, développer de nouvelles fonctionnalités, sans être en panique à chaque déploiement ? La réponse n’est pas magique. Elle repose sur une discipline claire et une checklist maîtrisée.

1) Savoir exactement ce que l’on déploie

Avant même d’écrire une ligne de code, il faut être capable d’expliquer clairement ce que l’on va mettre en production. Ça passe par :

une documentation claire
des objectifs précis
une compréhension partagée de la fonctionnalité

Cette documentation sert autant à l’équipe actuelle qu’aux personnes qui rejoindront le projet plus tard. Déployer sans savoir exactement ce que l’on déploie est la meilleure façon de perdre le contrôle.

2) Définir les cas de test avant de foncer

Les cas de test ne sont pas un luxe. Ce sont des garde-fous. Ils permettent de savoir quoi tester, comment tester et de réduire l’incertitude. Tests automatisés ou tests manuels, les deux sont nécessaires. Avoir des cas de test écrits permet d’aborder la mise en production avec beaucoup plus de sérénité.

3) Tester dans un environnement dédié (staging, pré-prod)

L’essentiel est d’avoir un environnement qui permet de tester ce qui va être déployé sans impacter les utilisateurs finaux. Cet environnement doit être le plus proche possible de la production :

même configuration
mêmes dépendances
mêmes contraintes

Tester ailleurs qu’en conditions réalistes donne un faux sentiment de sécurité.

4) Automatiser pour accélérer et sécuriser

Pour déployer sereinement et souvent, l’automatisation est indispensable. L’objectif de la CI/CD est d’automatiser les builds, les tests et les contrôles de qualité (SonarQube, Lint, scan de sécurité comme Snyk). Mais attention, automatiser les outils ne suffit pas sans une stratégie globale.

5) Mettre des garde-fous dans les pipelines

Un pipeline sans garde-fous est une autoroute vers les incidents. C’est une règle non négociable avant un déploiement :

tests automatisés exécutés systématiquement
code coverage minimum atteint
tests critiques obligatoirement au vert

L’équipe ne peut pas déployer tant que ces critères ne sont pas respectés. Ce n’est pas de la rigidité, c’est de la protection.

6) Classifier les tests selon leur criticité

Tous les tests n’ont pas la même importance. Certains sont vitaux pour le business (paiement, authentification, accès aux données), d’autres sont utiles mais moins bloquants. L’important est de savoir quels tests doivent absolument passer avant une mise en production.

7) Planifier et communiquer la release

Une release ne se fait pas dans le silence. Il faut définir ce qui va être livré, communiquer sur les nouvelles fonctionnalités et préparer les utilisateurs. C'est un élément clé de la réussite, surtout sur des plateformes SaaS interconnectées.

8) Utiliser des feature flags pour réduire le risque

Les feature flags permettent de déployer une fonctionnalité sans l’activer, de l’activer ou la désactiver à distance et de réagir rapidement en cas de problème. Le code est en production, mais le risque est maîtrisé.

9) Avoir une vraie stratégie de rollback

Une bonne stratégie de rollback inclut des conteneurs capables de redémarrer proprement, des backups de base de données avant déploiement et un retour en arrière déclenchable facilement. L'utilisation de Kubernetes avec des déploiements Canary permet de s'assurer qu'aucun switch n'est effectué tant que le nouveau conteneur n'est pas opérationnel.

10) Ne pas oublier les pages de maintenance

Si une micro-coupure est nécessaire, prévenez vos clients et choisissez des créneaux adaptés. Une bonne communication vaut mieux qu’un silence inquiétant.

Conclusion

Déployer en production sans trembler n’est pas une question de chance. C’est une question de méthode, d’automatisation, et de discipline. Plus votre checklist est claire, plus vos déploiements deviennent prévisibles. Et quand la production devient ennuyeuse, c’est généralement bon signe.

Delivery & DevOps / Multi-environnements & CI/CD

Livrer vite, c’est bien. Livrer vite sans casser la prod, c’est mieux. Et ça commence toujours par une stack CI/CD simple et maîtrisée.

Pourquoi les problèmes arrivent toujours au mauvais environnement

Beaucoup de bugs ne sont pas des bugs de code. Ce sont des bugs d’environnement. “Ça marche en local”, “ça marchait en staging”, “on n’a jamais testé ce cas en prod”.

Quand les environnements sont mal définis ou trop différents, chaque déploiement devient un pari. Une bonne stack multi-environnements n’accélère pas seulement les livraisons. Elle réduit drastiquement le stress.

Multi-environnements : ce qui est réellement nécessaire

Contrairement à ce qu’on croit, multiplier les environnements n’est pas toujours une bonne idée. La stack minimale efficace ressemble souvent à :

local
staging (ou pre-prod)
production

Chaque environnement doit avoir un rôle clair. Si un environnement ne sert à rien, il finira par être ignoré.

Local : reproductible ou inutile

Le local n’a pas besoin d’être identique à la prod, mais il doit être reproductible. Objectifs du local :

démarrer vite
tester sans friction
réduire les “ça marche chez moi”

Conteneurs, scripts, seed de données : peu importe les outils, tant que l’expérience est stable pour toute l’équipe.

Staging : un vrai filtre, pas une fausse prod

Le staging n’est pas là pour “faire joli”. Il doit filtrer ce qui ne doit pas arriver en production. Un staging utile :

utilise les mêmes versions que la prod
exécute les migrations réelles
permet des tests fonctionnels crédibles

Si le staging ne bloque jamais rien, il est probablement inutile.

Production : boring, stable, observable

La production n’est pas un terrain d’expérimentation. Elle doit être ennuyeusement fiable. En prod, on veut :

des déploiements prévisibles
des rollbacks rapides
une observabilité claire

Tout ce qui ajoute de la surprise en production finira par coûter cher.

CI/CD : le pipeline minimal qui fonctionne vraiment

Une bonne CI/CD n’est pas forcément complexe. Elle est surtout fiable et compréhensible. Pipeline minimal recommandé :

build et tests automatiques
analyse statique / linting
artefact versionné
déploiement automatisé par environnement

Si personne ne comprend le pipeline, personne ne lui fera confiance.

Versionner tout ce qui peut casser

Le code n’est pas le seul élément à versionner. Doivent être versionnés :

les images et artefacts
les migrations de base de données
les configurations critiques

Un déploiement doit toujours être reproductible. Sinon, ce n’est pas un déploiement, c’est un bricolage.

Automatiser sans perdre le contrôle

L’automatisation est un accélérateur, pas une excuse pour ne plus réfléchir. Bonnes pratiques :

déploiements déclenchés clairement
approbations explicites si nécessaire
logs et feedback immédiats

Une CI/CD doit rassurer, pas inquiéter.

Erreur classique : sur-optimiser trop tôt

Beaucoup d’équipes passent trop de temps à construire une CI/CD “parfaite”. Résultat : pipeline lent, maintenance lourde et peur de le modifier. La bonne CI/CD est celle qui sert le delivery aujourd’hui, pas celle qui anticipe tous les futurs possibles.

Checklist CTO : livrer vite et bien

Avant de valider une stack CI/CD, je veux voir :

• Des environnements clairement définis
• Un pipeline simple et compréhensible
• Des tests automatiques exécutés à chaque changement
• Un rollback rapide et maîtrisé
• Une observabilité post-déploiement

Conclusion

Livrer vite n’est pas une question d’outils. C’est une question de discipline. Une stack multi-environnements claire et une CI/CD simple mais robuste permettent de livrer plus souvent, avec moins de stress et moins d’incidents. Le meilleur indicateur d’une bonne CI/CD n’est pas sa sophistication, mais la confiance qu’elle inspire à l’équipe.

“Face à la pénurie de développeurs et développeuses de qualité en France, et d’autant plus en Rhône-Alpes, de nombreuses écoles voient le jour pour essayer de pallier cette problématique d’embauche.”

 

Dans le sillon de Simplon ou Coding Academy, la French Tech a décidé de lancer sa propre école de codage, le Campus Numérique in The Alps. La différence du projet, c’est la volonté d’investir les entreprises de la région dans l’apprentissage des futurs développeurs et d’adapter la formation aux compétences recherchées par les entreprises du digital. Alors pour comprendre un peu plus ce que l’école peut proposer, allons un peu plus loin.

 

C’est quoi exactement ? C’est un projet né et testé à Grenoble.

 

Son but ? Former de façon diplômante des demandeurs d’emplois au métier d’analyste-développeur, titre RNCP de niveau III à la clé, soit l’équivalent d’un Bac+2.

 

Comment ? Une formation de 18 mois décomposée en 2 périodes. Une première période de 6 mois de formation intensive, puis une alternance de 12 mois.

 

Le petit + ? L’investissement des entreprises dans la sélection des candidats. Un processus en 3 phases pour identifier les aptitudes, les motivations et le caractère des candidats.

 

Et WINZANA dans tout ça ? En plus d’être sponsor, WINZANA a eu le plaisir de participer à la formation des candidats dès la création du Campus Valence. Et oui, parce que cette formation a pour but de professionnaliser ces futurs développeurs, alors quoi de mieux que des professionnels pour leur apprendre le métier ? Nous avons décidé de nous investir dans leur apprentissage pour leur transmettre notre passion mais surtout pour leur apprendre les bases de notre métier.

 

Et cela porte ses fruits car aujourd’hui, notre dernier venu sort fraîchement du campus !

Conférence de Charles Laziosi (Web & Mobile Platform Owner at International Committee of the Red Cross) et Vincent Journel (Solution Architect) au DevOps Day 2022 de Genève.

Developers rarely take into consideration the offline experience when they design an application. Smartphones enable users to access the internet from anywhere or at any time so long as they are connected to a server, making an offline version of an application may seem unnecessary. But mobile networks are sometimes unreliable because coverage varies depending on the location. In this case, we should be able to handle network failures and latencies. It is at this point that offline architecture can really make a difference and save your application!

Bonjour à tous ! Aujourd'hui, nous allons nous immerger dans le monde fascinant de l'architecture serverless, un concept qui est en train de révolutionner le cloud computing. Ce n'est pas juste une mode passagère, mais une véritable évolution qui change la façon dont nous développons et gérons les applications. Imaginez un environnement où les préoccupations liées aux serveurs deviennent presque obsolètes, où vous pouvez vous concentrer sur la création et l'innovation plutôt que sur la maintenance et l'administration. C'est ce que propose le serverless. Dans cet article, nous allons décortiquer ce concept, explorer ses nombreux avantages, et discuter des défis qu'il présente. Que vous soyez un expert du cloud ou simplement curieux de cette nouvelle tendance, je vous promets que cette lecture vous apportera des éclairages nouveaux et passionnants sur le futur du développement dans le cloud. Alors, prêts pour cette exploration ? Allons-y !

Qu'est-ce que l'architecture Serverless ?

L'architecture serverless est un modèle de cloud computing qui modifie fondamentalement la façon dont les applications sont hébergées et gérées. Pour mieux comprendre ce concept, voici quelques détails supplémentaires :

Gestion par le fournisseur de cloud 

Dans un modèle serverless, c'est le fournisseur de cloud (comme AWS, Azure, ou Google Cloud) qui gère l'infrastructure serveur. Cela signifie que les développeurs n'ont pas à se soucier de la maintenance ou de la mise à jour des serveurs. Le fournisseur s'occupe de l'exécution du code, de la gestion des ressources, de la scalabilité et de la sécurité.

Exécution basée sur des événements

Les applications serverless sont généralement conçues pour répondre à des événements spécifiques. Par exemple, une fonction peut être déclenchée par une requête HTTP, un événement dans une base de données, ou un message dans un BUS (ex: RabbitMQ, Kafka, Azure Service Bus,...). Cela rend le modèle serverless particulièrement adapté pour des tâches qui ne nécessitent pas un serveur en fonctionnement continu, comme les traitements par lots, les tâches automatisées, ou le traitement de données en temps réel.

Conteneurs stateless

Le code dans une architecture serverless s'exécute dans des conteneurs qui sont stateless, c'est-à-dire qu'ils ne conservent pas d'état entre les exécutions. Chaque événement déclenche une nouvelle instance du conteneur, avec une initialisation propre à cet événement. Cela permet une grande flexibilité et scalabilité, car le système peut lancer ou arrêter des conteneurs en fonction de la demande.

Facturation basée sur l'utilisation

Un des grands avantages de l'architecture serverless est le modèle de facturation. Plutôt que de payer pour des serveurs qui tournent en continu, les coûts sont basés sur les ressources réellement consommées. Cela peut se traduire par des économies significatives, en particulier pour des applications avec des modèles d'utilisation irréguliers.

Exemples de plateformes serverless

• AWS Lambda

  Permet aux développeurs de lancer du code en réponse à des événements dans d'autres services AWS.

• Azure Functions

  Offre une intégration étroite avec d'autres services Azure, permettant de construire des applications riches en événements.

• Google Cloud Functions

  Intégrée dans l'écosystème Google Cloud, elle permet de créer des fonctions qui réagissent aux événements provenant de divers services Google.

Avantages de l'architecture Serverless

L'architecture serverless présente plusieurs avantages significatifs pour les entreprises et les développeurs. Voici une exploration plus détaillée de chacun des points mentionnés :

Réduction des coûts

• Paiement à l'utilisation : Dans un modèle serverless, les coûts sont basés uniquement sur les ressources consommées lors de l'exécution du code. Cela diffère des modèles traditionnels où les serveurs doivent être maintenus en fonctionnement en permanence, entraînant des coûts constants, indépendamment de l'utilisation réelle.
• Optimisation des ressources : Les développeurs peuvent se concentrer sur l'optimisation du code plutôt que sur la gestion de l'infrastructure, ce qui peut conduire à une utilisation plus efficace des ressources et, par conséquent, à des économies supplémentaires.
• Élimination des coûts inutiles : Les coûts liés à l'excédent de capacité ou à l'infrastructure sous-utilisée sont pratiquement éliminés, car l'architecture serverless ajuste automatiquement les ressources nécessaires.

Scalabilité automatique

• Gestion flexible de la charge : L'architecture serverless peut gérer automatiquement les augmentations soudaines de charge, en adaptant les ressources en temps réel. Cela est particulièrement utile pour les applications avec des modèles d'utilisation variables ou imprévisibles.
• Pas de planification manuelle : Les développeurs n'ont pas besoin de planifier manuellement la scalabilité ou de réserver des ressources supplémentaires pour gérer les pics de trafic, ce qui simplifie grandement le processus de gestion des applications.
• Réactivité accrue : La capacité à s'adapter rapidement aux changements de demande garantit que les applications restent performantes et fiables même sous de fortes contraintes de charge.

Déploiement rapide et gestion simplifiée

• Réduction du temps de mise sur le marché : Grâce à la simplification de la gestion de l'infrastructure, les entreprises peuvent déployer rapidement de nouvelles applications ou fonctionnalités, réduisant ainsi le temps nécessaire pour mettre les produits sur le marché.
• Moins de complexité opérationnelle : En éliminant la nécessité de gérer des serveurs, l'architecture serverless réduit la complexité opérationnelle, permettant aux équipes de se concentrer sur le développement et l'innovation.
• Maintenance réduite : Avec le fournisseur de services cloud s'occupant de la maintenance de l'infrastructure, les équipes de développement ont moins de soucis de maintenance, ce qui leur permet de consacrer plus de temps et d'efforts à l'amélioration et à l'expansion de leurs applications.

Défis de l'architecture Serverless

Les architectures serverless, tout en étant révolutionnaires, soulèvent plusieurs défis qui doivent être pris en compte lors de l'évaluation de leur adoption. Voici une explication approfondie des problèmes mentionnés :

Problèmes de démarrage à froid (Cold Start Issues)

Dans le contexte serverless, les fonctions sont exécutées dans des conteneurs qui doivent être lancés la première fois qu'une demande est reçue après une période d'inactivité. Ce délai de "démarrage à froid" peut introduire une latence supplémentaire.
Les fournisseurs de cloud ont des stratégies pour minimiser ce problème, comme le maintien des instances de fonction en vie pendant un certain temps après l'exécution, mais cela ne l'élimine pas complètement, en particulier pour les fonctions rarement appelées.
Ce problème est un facteur important dans les applications où la performance et la rapidité de réponse sont critiques.

Limitations de temps d'exécution (Execution Time Limitations)

Les fournisseurs de services serverless imposent généralement des limites de temps sur la durée pendant laquelle une fonction peut s'exécuter. Par exemple, AWS Lambda a une limite maximale d'exécution par défaut pour une seule invocation.
Ces limites peuvent poser problème pour des processus back-end qui nécessitent des opérations de longue durée ou des traitements de données complexes.
Les développeurs doivent concevoir leurs applications de manière à pouvoir gérer ces contraintes, potentiellement en segmentant les tâches longues ou en utilisant d'autres services en complément.

Dépendance au fournisseur de services cloud (Vendor Lock-in)

L'architecture serverless s'appuie fortement sur les services et les API spécifiques à un fournisseur de cloud, ce qui peut rendre la migration vers un autre fournisseur difficile.
Les fonctions serverless sont souvent étroitement intégrées avec d'autres services du fournisseur, ce qui renforce la dépendance à cet écosystème.
Le verrouillage du fournisseur peut limiter les options et la flexibilité de l'entreprise et potentiellement augmenter les risques et les coûts si le fournisseur change ses prix ou sa politique de service.

Conclusion

En conclusion, alors que l'architecture serverless ouvre de nouvelles avenues d'efficacité et d'innovation dans le cloud computing, elle apporte avec elle un ensemble de défis. Les questions de performances liées aux démarrages à froid, les contraintes de temps d'exécution et les risques de dépendance vis-à-vis des fournisseurs sont des sujets qui méritent notre attention. Ces obstacles, toutefois, ne sont pas insurmontables. Des solutions émergentes promettent d'adresser ces problématiques et d'offrir encore plus de flexibilité.

Dans cette optique, Knative se présente comme une évolution logique pour ceux qui cherchent à tirer parti de l'architecture serverless tout en minimisant la dépendance à un fournisseur spécifique. En se basant sur Kubernetes, Knative offre une plateforme agnostique pour déployer et gérer des applications serverless, offrant ainsi une portabilité accrue entre différents environnements cloud.

Ce n'est que le début de notre exploration. Dans les articles à venir, nous plongerons dans l'univers de Knative, décryptant son fonctionnement, ses avantages et comment il peut s'intégrer dans votre stratégie serverless. Nous étudierons également d'autres innovations qui permettent de naviguer efficacement dans l'écosystème serverless, telles que les plateformes d'intégration continue, les outils de monitoring et les stratégies de développement multi-cloud. Restez avec nous pour cette série d'articles où nous continuerons de dévoiler les facettes du cloud computing, pour vous guider vers des choix éclairés et des solutions optimales.

La réalisation d'architectures serverless avec ou sans Kubernetes présente des différences significatives, principalement en termes de complexité de gestion, de contrôle et d'évolutivité. On se pose souvent la question, dois-je faire du full SAAS en utilisant les services proposés par les providers Cloud, ou tout contrôler moi même en utilisant un cluster kubernetes. Nous allons essayé de faire un petit comparatif :

Serverless avec Kubernetes en utilisant Knative

L'utilisation de Knative sur Kubernetes pour déployer des architectures serverless offre un ensemble de fonctionnalités avancées qui améliorent significativement la personnalisation, la portabilité, la gestion de l'infrastructure, l'intégration avec l'écosystème Kubernetes, et la scalabilité.

Contrôle et Personnalisation

• Environnement d'Exécution : Avec Knative sur Kubernetes, vous pouvez personnaliser l'environnement d'exécution des applications à un niveau très détaillé, y compris la gestion des ressources CPU et mémoire, les variables d'environnement et les configurations de sécurité.
• Mise en réseau : Knative offre des options avancées pour la configuration réseau, comme les règles d'ingress, les politiques de sécurité réseau et la gestion des services internes et externes. Il s’appuie sur des services mesh tel que istio, Kourier.
• Sécurité : Vous avez le contrôle sur les aspects de sécurité, tels que les stratégies de Role-Based Access Control (RBAC), les secrets et les certificats, et la configuration des politiques de sécurité des conteneurs.

Portabilité

• Multi-cloud et On-premise : Les applications serverless développées avec Knative peuvent être déployées uniformément sur différents clouds (AWS, GCP, Azure, etc.) ou sur des infrastructures on-premise, tant que ces environnements prennent en charge Kubernetes.
• Indépendance vis-à-vis des Fournisseurs : Cela réduit la dépendance à un fournisseur cloud spécifique, permettant une flexibilité et une adaptation aux changements de fournisseurs ou de politiques.
• Environnement de développement : Il est possible de rapidement déployer un environnement Knative sur une infrastructure local pour les équipes de développements afin qu’ils puissent tester leur code en toute simplicité.

Gestion de l'Infrastructure

• Complexité Technique : Gérer Kubernetes requiert une compréhension approfondie de ses composants - pods, services, volumes, namespaces, etc. Cela implique une courbe d'apprentissage plus rapide pour le déploiement et la maintenance. Knative apporte une surcouche qui permet de faciliter le déploiement sur Kubernetes.
• Automatisation et Orchestration : Kubernetes facilite l'automatisation et l'orchestration des conteneurs, y compris la réparation automatique, le rolling update, et la gestion du cycle de vie.

Intégration avec l'Écosystème Kubernetes

• Monitoring et Logging : Intégrez avec des outils comme Prometheus pour le monitoring et Elasticsearch ou Fluentd pour la journalisation.
• CI/CD et DevOps : Utilisez des outils tels que Azure DevOps, Jenkins, GitLab CI et Argo CD pour l'intégration et le déploiement continus.

Scalabilité Granulaire

• Auto-scaling : Knative offre un scaling dynamique et précis, y compris la capacité de scaling à zéro, ce qui signifie que les applications peuvent s'échelonner en réponse à la demande et réduire à aucune instance lorsqu'elles ne sont pas utilisées.
• Gestion des Ressources : Vous pouvez définir des politiques de scaling personnalisées basées sur des métriques telles que le nombre de requêtes par seconde, l'utilisation de la CPU ou de la mémoire.

Serverless sans Kubernetes

Lorsque l'on parle de développement serverless, choisir entre des solutions basées ou non sur Kubernetes peut avoir un impact considérable sur votre flux de travail. Pour les développeurs, travailler avec des plateformes telles que Cloud Function de Google, AWS Lambda ou Azure Functions présente un avantage majeur : la simplification radicale du processus de déploiement et de gestion. Ces plateformes prennent en charge l'infrastructure sous-jacente, ce qui permet aux développeurs de se concentrer entièrement sur la rédaction de code efficace sans se soucier de la configuration et de la maintenance des serveurs. Cela représente une réduction significative de la charge opérationnelle, libérant du temps et des ressources pour l'innovation et le développement de fonctionnalités. On va essayer de détailler ces points :

Simplicité et Facilité de Démarrage

• Déploiement Automatisé : Les plateformes comme AWS Lambda et Azure Functions gèrent automatiquement le déploiement des fonctions. Les développeurs n'ont qu'à fournir le code, et la plateforme s'occupe du reste, y compris de la sélection de l'environnement d'exécution approprié.
• Absence de Gestion des Serveurs : Ces plateformes éliminent la nécessité de gérer des serveurs ou des clusters, comme c'est le cas avec Kubernetes, réduisant ainsi la charge opérationnelle pour les développeurs. Et permet également de s’abstraire de la complexité d’implémentation.

Moins de Contrôle sur l'Environnement d'Exécution

• Environnements Préconfigurés : Les environnements d'exécution sont préconfigurés par le fournisseur de cloud. Cela limite la personnalisation au niveau de l'OS, des logiciels intermédiaires et des configurations réseau.
• Restrictions de Runtime : Les fonctions doivent généralement être écrites dans des langages de programmation spécifiques et dans les limites des runtime supportés par la plateforme.

Dépendance au Fournisseur de Cloud

• Verrouillage de Plateforme : En utilisant des services spécifiques d'un fournisseur, les applications deviennent dépendantes de cet environnement cloud, ce qui peut compliquer leur migration vers un autre fournisseur.
• APIs et Services Propriétaires : Les fonctions peuvent utiliser des services et des APIs spécifiques au fournisseur, renforçant cette dépendance.

Facilité d'Utilisation et Maintenance

• Gestion Automatisée : Le fournisseur gère la scalabilité, la haute disponibilité, la tolérance aux pannes et la maintenance, permettant aux développeurs de se concentrer sur le code.
• Mises à jour et Sécurité : Les mises à jour de l'infrastructure et les mesures de sécurité sont également gérées par le fournisseur.

Scaling Automatique et Gestion des Ressources

• Élasticité : Les plateformes ajustent automatiquement les ressources en fonction de la charge, permettant une scalabilité efficace sans intervention manuelle.
• Optimisation des coûts : La facturation se base sur l'utilisation réelle, avec des modèles de tarification à la demande ou basés sur le nombre d'exécutions.

Quoi choisir ?

Le choix entre le serverless sur Kubernetes avec Knative et les solutions serverless natives du cloud n’est pas toujours simple. Il faut prendre en compte le contexte de votre implémentation. La décision ne se résume pas seulement entre un choix entre la complexité et contrôle pour les architectures d'entreprise importantes, ou  la simplicité et rapidité pour le développement de solutions plus petites. Avant toute prise de décision, il faut se poser  les bonnes questions et surtout concevoir son architecture avant de prendre son choix. Pour moi :

Serverless avec Kubernetes en utilisant Knative

Knative, utilisé sur Kubernetes, est particulièrement adapté pour les grandes architectures d'entreprise nécessitant un contrôle approfondi et une personnalisation étendue. Il offre un niveau de contrôle élevé sur l'environnement d'exécution, la mise en réseau et la sécurité, ce qui est crucial pour les entreprises ayant des besoins spécifiques et complexes. La portabilité offerte par Kubernetes permet également aux entreprises de déployer des applications sur différents clouds ou sur site. Cependant, cette approche exige une compréhension approfondie de Kubernetes, augmentant la complexité technique et la courbe d'apprentissage.

Serverless sans Kubernetes (Cloud Native)

En revanche, les solutions serverless natives du cloud comme AWS Lambda et Azure Functions sont idéales pour un développement rapide et efficace de solutions plus petites. Elles simplifient considérablement le processus de déploiement et de gestion, permettant aux développeurs de se concentrer sur le code sans se soucier de l'infrastructure sous-jacente. Bien qu'elles offrent moins de contrôle sur l'environnement d'exécution et créent une dépendance vis-à-vis du fournisseur de cloud, elles sont parfaites pour les projets nécessitant une mise sur le marché rapide et une gestion simplifiée.

En résumé, Knative sur Kubernetes est plus adapté pour les entreprises recherchant une solution serverless robuste et personnalisable pour des architectures complexes, tandis que les solutions serverless natives du cloud sont idéales pour les développeurs qui cherchent à déployer rapidement des applications moins complexes sans la charge opérationnelle de la gestion de l'infrastructure.

Dans le prochain article nous détaillerons qu’est-ce que Knative et comment nous l’implémentons au sein de Winzana pour nos projets. Si vous avez des questions n’hésitez pas à nous contacter.

L'écosystème du cloud computing connaît une évolution rapide avec l'intégration de solutions serverless avancées. Parmi celles-ci, Knative, utilisé avec Kubernetes, se distingue comme une solution puissante pour les architectures serverless. Cet article se penche sur les aspects techniques de Knative et de son intégration avec Kubernetes, expliquant pourquoi et comment cette combinaison est devenue un choix stratégique pour les entreprises technologiquement avancées.

Knative : Extension Serverless de Kubernetes

Knative est une plateforme open-source innovante conçue spécifiquement pour optimiser et étendre les fonctionnalités de Kubernetes dans le contexte du computing serverless. Voici un aperçu détaillé de ses trois composants clés :

Tekton Pipelines - Remplaçant de Knative Build

Fonctionnalités avancées de CI/CD : Tekton Pipelines apporte une solution de CI/CD native à Kubernetes, remplaçant la fonctionnalité de build de Knative. Il offre une personnalisation plus approfondie et une flexibilité accrue pour l'automatisation du processus de construction et de déploiement des applications.

Intégration dans les Workflows Kubernetes : En s'intégrant directement dans l'écosystème Kubernetes, Tekton permet une gestion plus cohérente et homogène des workflows de construction et de déploiement.

Serving

Modèle de déploiement Scalable : Serving propose un modèle de déploiement d'applications qui prend en charge le scaling automatique. Cela inclut le scaling horizontal en fonction de la demande, ainsi que la capacité de réduire les ressources à zéro lorsqu'une application est inutilisée (scaling à zéro).

Routing Intelligent : Il intègre un système de routing intelligent qui dirige le trafic vers les différentes révisions de l'application, facilitant le déploiement progressif et le testing A/B.

Support des Conteneurs : Serving est conçu pour prendre en charge divers types de conteneurs, offrant ainsi une grande flexibilité dans le choix des technologies et des langages de programmation.

Gestion de l'État : Bien que principalement axé sur les applications stateless, Knative Serving peut également être configuré pour gérer certaines formes d'état, ce qui le rend polyvalent pour une large gamme d'applications.

Eventing

Gestion des Événements : Eventing est le composant de Knative qui gère les événements au sein de l'écosystème Kubernetes. Il facilite la création, la gestion et le routage des événements entre les services.

Sources d'Événements : Il peut se connecter à diverses sources d'événements, internes ou externes, telles que les bases de données, les systèmes de messagerie ou les services cloud.

Déclencheurs et Abonnements : Eventing permet de définir des déclencheurs spécifiques qui activent les microservices en réponse à des événements, permettant ainsi de créer des architectures basées sur les événements.

Flexibilité et Interopérabilité : Ce composant offre une grande flexibilité et interopérabilité, permettant aux développeurs de lier facilement leurs services à un large éventail d'événements et de sources.

Broker layer : Possibilité d'utiliser des outils tel que Kafka ou RabbitMQ

Quel avantage d’utiliser Knative pour vos équipes de développeurs ?

Développement Agile : Knative accélère le développement et le déploiement des applications grâce à sa capacité à gérer automatiquement les aspects de l'infrastructure.

Scalabilité Simplifiée : Knative offre une scalabilité automatique, y compris le scaling à zéro, ce qui est essentiel pour les applications à charge variable.

Intégration CI/CD Facilitée : Knative s'intègre facilement dans les pipelines CI/CD, réduisant le temps et les efforts nécessaires pour la livraison continue.

Gestion des Événements et des Services : Knative simplifie la création d'applications basées sur les événements, permettant aux développeurs de se concentrer sur la logique métier.

Environnement Kubernetes Optimisé : Utiliser Knative sur Kubernetes offre une expérience améliorée, en profitant de la robustesse et de la sécurité de Kubernetes.

Un argument significatif en faveur de Knative pour les équipes de développement est la capacité à délivrer des environnements distincts pour chaque fonctionnalité. Cette approche permet :

Déploiement par fonctionnalité : Les développeurs peuvent tester de nouvelles fonctionnalités dans des environnements isolés avant leur intégration dans la production.

Rapidité et flexibilité : Chaque fonctionnalité peut être développée, testée et déployée indépendamment, accélérant le processus de développement et de mise sur le marché.

Réduction des risques : Les erreurs ou les problèmes liés à une fonctionnalité spécifique peuvent être identifiés et résolus dans un environnement isolé, sans impacter l'ensemble du système.

Comment aborder la mise en place de Knative

Les Défis

Complexité Technique : Kubernetes est un système complexe avec une courbe d'apprentissage élevée.

L'intégration de Knative ajoute une couche supplémentaire de complexité. Même s’il facilite l’usage de Kubernetes, il faut avoir une connaissance des concepts de la kubernetisation (Pod, Deployment, Service, PVC, …)

Expertise Requise : La mise en œuvre efficace nécessite une équipe avec une expertise approfondie en Kubernetes et Knative.

Gestion des Ressources : La gestion optimale des ressources et le scaling automatique requièrent une configuration et un monitoring attentifs.

Solutions

Formation et Certification : Investir dans la formation et la certification de l'équipe , d’abord sur Kubernetes puis sur Knative.

Automatisation et Outils : Utiliser des outils pour automatiser et simplifier la gestion des clusters Kubernetes tels qu’ArgoCD, Kaniko, Tekton.

Partenariats Stratégiques : Collaborer avec des partenaires technologiques ou des consultants spécialisés pour combler les lacunes en matière de compétences.

Évaluation Continue : Évaluer régulièrement l'architecture pour assurer son évolutivité et sa maintenance.

Approche Stratégique

Évaluation des besoins : Comprendre clairement les besoins de l'entreprise et comment Knative peut les adresser.

Pilotage et Phases : Commencer par des projets pilotes avant de déployer à grande échelle.

Feedback et Adaptation : Être réactif au feedback de l'équipe de développement pour améliorer continuellement les processus et les outils.

Ces stratégies peuvent aider à surmonter les défis techniques tout en maximisant les avantages de Knative en termes de flexibilité, de scalabilité et d'efficacité des coûts.

Applications Pratiques de Knative

ETL Dynamique pour le Traitement de Données Volumineuses pour le département du Vaucluse

Scénario : Traitement des données d'import volumineuses d'APIDAE.

Détails Techniques : Utilisation de Knative pour orchestrer des conteneurs éphémères qui s'activent pour traiter les données et s'éteignent une fois le travail accompli, optimisant ainsi les ressources et les coûts.

Environnements de Développement Agile avec Knative

Scénario : Mise en place d'environnements de développement avec scalabilité flexible.

Détails Techniques : Configuration de Knative pour déployer des environnements à la demande avec scalabilité de 0 (inactif) à n (actif), selon les besoins, réduisant ainsi les coûts d'infrastructure.

Architecture Macro-service pour Yamay

Scénario : Gestion de trafic élevé et traitement de données en tâche de fond pour Yamay.

Détails Techniques : Mise en place de services Knative capables de gérer des pics de charge tout en exécutant des opérations de traitement de données parallèles, garantissant ainsi performance et analyse statistique efficace.

Conclusion : Adopter Knative pour une Innovation Agile dans le Cloud

En conclusion, Knative, combiné à Kubernetes, représente une évolution majeure dans le cloud computing, offrant une flexibilité, une scalabilité et une efficacité accrues pour les architectures serverless. Pour les équipes de développement, Knative apporte agilité et innovation, permettant des déploiements par fonctionnalité et une réduction des risques. Néanmoins, les défis techniques, tels que la complexité de Kubernetes et la nécessité d'une expertise approfondie, doivent être abordés par une formation adéquate, l'utilisation d'outils automatisés, et une évaluation continue. L'adoption de Knative est une démarche stratégique, nécessitant une planification soignée et une adaptation constante. En fin de compte, Knative est un outil puissant pour les organisations cherchant à optimiser leur présence dans le cloud et à accélérer leur développement d'applications serverless.