Sommaire

• DevOps
• Middleware
• Industrialisation
• Infra as Code
• GitOps
• Pet VS Cattle
• Gitflow
• Microservices
• Observabilité
• Bug Bounty
• Cloud
• Services managés
• Serverless
• Security Group - Cloud init / user data

DevOps

Le DevOps est une méthodologie ayant pour but de réduire le Time To Market des applications. Pour cela elle va prôner la collaboration entre développeurs et opérationnels.

Souvent le DevOps est rapproché des principes C.A.L.M.S :

Culture
Automatisation
Learn
Metric
Solidarité

Si vous souhaitez en savoir plus, voici deux articles de ce blog qui traitent du sujet plus en profondeur :

• DevOps : Episode 1
• DevOps : Episode 2

Middleware

Les middelwares sont des logiciels qui vont intéragir avec différents autres logiciels. Ils servent de liant entre les différentes applications d’un système d’information d’entreprise.

Exemple de produit : les systèmes d’authentifications sont des middelwares qui vont intéragir avec différentes autres briques du système d’information

Industrialisation

L’industrialisation est une pratique bien antérieure à l’ère du DevOps. Elle permet d’automatiser les tâches d’installation et de paramétrage de machine. Cela comprend notamment l’installation des middelwares, leurs paramétrages, au paramétrage de la machine (règles pare-feu etc…). Cela permet notamment de gérer de grand-ensemble de serveur automatiquement, mais aussi de passer par du code pour effectuer les actions, donc être combiné avec du versionning, voir GitOps.

Exemple : Ansible est l’outil d’industrialisation le plus populaire actuellement, il vous permet de déployer et gérer vos machines au travers de fichier de configuration.

Infra As Code

L’infrastructure a évolué rapidement avec la propagation du DevOps, même si l’industrialisation est une pratique assez ancienne, écrire du code pour créer des ressources d’infrastructure est assez récent. C’est là tout le principe de l’Infra As Code, plutôt que de manipuler des interfaces graphiques pour créer nos ressources d’infrastructure (machines virtuelles, réseau,…), on va le faire par du code.

Cela a plusieurs avantages, on peut versionner notre infrastructure, donc historiser les changements, revenir en arrière, collaborer plus facilement et recréer facilement des choses avant répétitives.

Un des produits les plus utilisé dans l’infra as code est Terraform

GitOps

GitOps, est un terme pas toujours bien employé. Il désigne simplement le fait de centraliser tout l’état de l’infrastructure (par exemple, l’industrialisation) sur un outil de versionning comme Git. On va généralement y adjoindre une chaîne de Deploiement Continue, afin de gagner en efficacité.

Cela permet de bénéficier de tous les avantages du versionning dans les métiers opérationnels. Toutes les actions que vous aller mener, mise à jour de machine, changement réseau passera par git et une chaine d’intégration et de déploiement continue.

Exemple : Gitlab est un produit très souvent associé au GitOps, même s’il est possible d’utiliser d’autres solutions.

Pet Vs Cattle

C’est un des paradigme les plus déstabilisant pour les personnes qui ont été habituées à gérer les machines avec un cycle de vie classique. Globalement elle oppose deux manières de gérer le cycle de vie des machines.

La méthode classique de gestion des machines, on les suit de près, on connait par coeur les opérations qui on été faites dessus, on leur donnent aussi des petits nom. On la compare donc au Pet car le comportement se rapproche de celui des propriétaires d’animaux de compagnie.

La nouvelle manière, ou l’on ne se préoccupe plus du système en lui même, on standardise et automatise au maximum leurs générations et leurs fonctionnements, en cas de problème on n’hésite pas à les détruires pour les recréer ou les multiplier, on leur donne un nom générique celle-ci pouvant mourir à tout moment. Cette approche en opposition au Pet est appelée Cattle, pour comparer à la gestion des abattoirs ou le propriétaire ne se lie pas à l’animal dans son unité.

Une des technologies qui a le plus démocratisé le pet vs cattle reste Docker.

Gitflow

Git est aujourd’hui le gestionnaire de versionning le plus utilisé et un standard quasi incontesté. Gitflow est une organisation spécifique qui décrit une manière de gérer les branches, contenant différentes versions concurentes du code, dans laquelle on créé une branche “Develop” pour le développement, une “release” afin de gérer les releases et ensuite des branches par feature.

Lors de l’ajout d’une fonctionnalité, notre modification va effectuer le chemin suivant :

• Création de commit et push sur une branche dédiée à la feature
• Une fois la feature terminée, merge request (ou pull request) sur la branch de développement
• Lors de la création d’une nouvelle realease merge du code de developpement vers la branche release. Qui sera utilisé pour placer un tag.
• Merge de la branche release une fois celle-ci prête vers master

A noter que les corrections urgentes et les correctifs de sécurité passent par une branche spécifique (hotfix) qui sera mergé directement sur master après test/

Microservices

Pendant longtemps le modèle de service le plus utilisé était le monolithe, on accumule tout le code et toutes les fonctionnalités sur la même machine (approche monolithique).

Cela a très rapidement montré ses limites notamment quand le trafic a explosé et les sites ont dû se mettre au niveau “scale”. Quand on héberge un monolithe, on ne peut que scale “verticalement” c’est-à-dire en augmentant la puissance de la machine. Cela montre rapidement ses limites et pour effectuer un scale “horizontal”, c’est-à-dire en dupliquant les services, il est quasi indispensable de les découper. Une fois notre application découpée en fonction plus simple, nous obtenons un microservice. Chaque application est composée d’un ensemble de petites applications qui effectue des choses simples.

Par exemple, sur un site d’achat de vêtement on peut imaginer une version microservice, ou le paiement, la recherche de vêtement, même s’ils font partie du même site sont indépendantes voir sur des machines différentes.

Cela a d’autres avantages au-delà du scale, cela permet de gérer plus simplement le code et les impacts sur celui-ci, vous pouvez mettre à jour un service sans toucher à tous les services. Elle permet aussi de mieux gérer le développement de projets d’envergure et créant des features teams autour de fonctionnalités précises de votre produit.

Observabilité

Souvent vu comme une évolution de la supervision, qui permettait de remonter sous forme d’indicateur binaire (OK/KO) l’état d’un service. Encore très répandu, cela permet par exemple de vérifier que votre serveur web fonctionne correctement.

Mais avec l’évolution des enjeux et des besoins, définir l’état des différents services s’est avéré très peu efficace. En effet, définir un comportement conforme dans une infrastructure micro service est bien plus complexe qu’un ensemble d’états binaires.

Pour cela on a changé la manière de faire les choses, plutôt que de relever des états, on va collecter un grand ensemble de metrics, par exemple la latence des disques, le temps de réponse du site, voire même le taux de conversion sur le site ! Avec la combinaison de ces paramètres, déduire un état précis de fonctionnement du site.

De plus les différentes métriques n’étant pas binaire, on peut de manière plus fine comprendre le fonctionnement des ressources.

Des produits qui sont très répandus dans ces domaines sont : Prometheus pour la récolte des metriques et Grafana pour l’affichage

Bug bounty

Le “Bug bounty” est une approche qui gagne grandement en popularité ces dernières années. Elle consiste à récompenser les personnes qui trouvent des bugs, ou des failles dans votre application afin de les corriger et de dissuader la revente d’informations.

Un Bug bounty concerne en général la sécurité où il permet de lancer des campagnes de tests à une communauté de personnes travaillant dans la sécurité de manière flexible. La rémunération se fait à la découverte de bug en fonction de la criticité de celui-ci.

Cloud

Le cloud, ou informatique nuagique désigne le fait d’utiliser des ressources (serveurs, services…) chez un prestataire (provider) auquel vous déléguez une partie de la gestion, comme par exemple la gestion du datacenter, du matériel. Ce qui caractérise le cloud aujourd’hui c’est d’être facturé à l’utilisation / consommation, contrairement aux solutions traditionnelles où vous payerez un forfait d’utilisation, ou devez apporter des investissements successifs. Si vous avez besoin d’une VM pendant 2 jours, vous payerez 2 jours. Le cloud est souvent mis en avant pour sa flexibilité.

Il existe 3 catégories de cloud :

• Cloud public: le plus populaire est un service de cloud qu’une entreprise met à destination de client ouvert. Vos ressources sont hébergées sur des infrastructures mutualisées en général (avec de l’isolation bien sur)

• Cloud privé: le cloud privée est une offre de cloud qui va être géré pour l’entreprise elle-même, elle n’est pas partagée. Elle va surtout permettre aux différentes équipes de profiter de la flexibilité d’accès aux ressources. Il est souvent utilisé dans les cadres utilisant des données sensibles, qui peuvent poser problème dans des clouds publics soumis à d’autres juridictions.

• Cloud hybride: est de plus en plus populaire aujourd’hui, il vise à combiner le meilleurs des deux mondes. Pour cela il va combiner des parties hébergées sur du cloud public à des parties hébergé sur du cloud privé.

Il existe aussi différents niveaux de service, voire la partie IaaS / PaaS / SaaS

Services managés

Les services managés sont des services qui sont opérés et entretenu directement par un prestataire, vous n’avez pas à gérer de serveur. Bien sûr des serveurs restent utilisés pour fournir le service. Cela vous permets en tant qu’utilisateur de ne pas à avoir à vous préoccuper de la couche système du service, cette partie est gérée par votre fournisseur.

Exemple: quand vous utilisez un cluster SQL managé (RDS sur AWS ou autre), vous n’avez pas à installer, ni gérer les serveurs c’est votre provider qui se charge de cela.

Serverless

Les services qualifiés de serverless sont une catégorie de service managé. Ils sont même souvent confondus avec ces derniers. Il n’y a pas de réel consensus sur ce qui définit la différence entre les deux. Globalement un élément qui est souvent utilisé pour qualifier un service managé de serverless va être la facturation. On va souvent considérer que si on ne paye pas de charge fixe, mais seulement à l’utilisation, il s’agit d’un service de type serverless.

Exemple : Avec les fonctions AWS Lambda, vous ne payer que si votre fonction est executée. Si ce n’est pas le cas, vous ne payez pas.

Security group

Fonctionnalité grandement mise en avant par le cloud, les security groups sont des pare-feu virtuelles que vous pouvez attacher à vos machines. Certaine permettent notamment de tager de trafic sortant afin d’effectuer les ouvertures de flux non pas au niveau de l’IP mais du security group d’origine. Il est rare de voir aujourd’hui des machines sur le cloud qui n’utilise pas cette fonctionalitée.

CLoud-init / userdata

Il s’agit d’un script (payload en base64) que l’on attache à une instance. Celui-ci sera utilisé à la création de la machine. Là encore c’est un mécanise très répendu depuis l’explosion du cloud.

Des suggestions, corrections direction Twitter: DamyR.