SlideShare une entreprise Scribd logo
1  sur  61
#GlobalAzure
L’évolution vers le
(Dev)NoOps ;-)
http://www.e-novatic.fr
@enovatic
■Introduction
■Une application Cloud Native ?
■L’approche DevOps
■Les conteneurs et architecture orientées micro-service
■Infrastructure As Code – IaC
■Les architectures Serverless
■L’Application Management Performance dans une chaîne NoOps
■L’approche NoOps
■Conclusion
Agenda
■Nouvelle façon de concevoir, déployer & d’opérer les infra & applis
■NOUVEAU business model !
■Une transformation CLOUD c’est transformer son Operating & Delivery
Model
■Nouvelles notions: PaaS, serverless, conteneurs, micro services, …
■Utiliser les outils cloud native
■Nouvelles façons de travailler: DevOps, DevSecOps, NoOps
■Mort des admins (?), transformation des métiers admin & dev
=> Chaine réussie d’une transformation cloud !
Le Cloud: le messie ? Oui, mais…
■Méthodologie pour construire des applications software-as-a-service
qui :
■Utilisent un format déclaratif pour l’automatisation des installations
■Ont un contrat clair avec l’OS sous jacent et qui offrent une portabilité maximale
pour l’exécution sur différents environnements
■Sont adaptées à un déploiement sur des plateformes cloud
■Minimisent la divergence entre développement et production et permettent un
déploiement continu pour un maximum d’agilité
■Peuvent monter en charge sans changement majeur d’outillage, d’architecture
ou de pratique de développement
Les Twelve Factor
Faites moi un sandwich
1. Prendre du pain
2. Le couper en deux
3. Mettre du beurre sur un morceau
4. Poser une tranche de jambon
5. Mettre la deuxième tranche de
pain
Format déclaratif
Je veux ce sandwich
“Un sandwich avec deux tranches de
pain. Il doit avoir du beurre sur les
morceaux de pain et une tranche de
jambon entre les deux morceaux de
pain
 Impératif
 Déclaratif
■Il existe plusieurs approches, classique (Waterfall par exemple) et
DevOps (Agile, ...) qui incluent les OPS (Ingénieurs systèmes,
architectes, ...) et les DEV (développeurs, Architectes logiciels, ...).
■Dans une approche classique:
■Les DEV produisent du code, les évolutions fonctionnelles, ...
■Les OPS mettent à disposition les infrastructures sans tenir compte des
évolutions logicielles mais plutôt en se concentrant sur le SLA du service ainsi
que la performance associée
■Dans une approche de type DevOps, l'ensemble des acteurs, soit les
DEV et les OPS se répartissent les responsabilités et sont tous impliqués
dans la chaîne de mise en production d'une application
Le concept DevOps
Le concept DevNoOps, les nouvelles technologies permettront de
s'affranchir des OPS dans le sens où le code de l'infrastructure ne
deviendra plus qu'une variable dans la chaîne !
En images
CI, CD… KEZAKO ?
CI: intégration continue,
une pratique qui vise à
faciliter la préparation
d'une version
CD: une livraison
continue ou un
déploiement continu
■Intégration continue consiste à fusionner les modifications dans la branche
principale aussi souvent que possible. Les modifications du développeur sont
validées en créant une génération et en exécutant des tests automatisés par
rapport à la génération
■Livraison continue est une extension de l'intégration continue qui, en plus
d'avoir automatisé les tests, automatise le processus de publication et de
déploiement à tout moment en cliquant sur un bouton
■Déploiement continu va plus loin car chaque modification apportée à toutes
les étapes de votre pipeline de production est transmise aux utilisateurs. Il n'y
a pas d'intervention humaine, et seul un test échoué empêchera le
déploiement d'un nouveau changement dans la production
En détail
CI/CD en images
BUILD
Test
unitaires
Intégration
Test
UAT
Production
BUILD
Test
unitaires
Intégration
Test
UAT
Production
BUILD
Test
unitaires
Intégration
Test
UAT
Intégration
Continue
Livraison
Continue
Déploiement
Continu
Automatisé Manuel
Pet vs Cattle
Mutable vs immutable
Baking vs Frying
Exemple concret
La vue fonctionnelle
L’architecture technique
■Chaque micro service dispose de son datastore
■Cycle de vie indépendant pour chaque micro service
■Peu / pas d’adhérence entre micro services
■Scalabilité indépendante
■Déploiements plus petits, plus fréquents, plus nombreux
■Isolation des ressources
Les micro services en bref
■Les architectures micro-services permettent des déploiements plus
petits, plus fréquents et plus nombreux
■Cela qui induit une multiplication des conteneurs (Cattle) car une
application pensée micro-services est découpée en de multiples
services/composants
■L'orchestrateur sera révélera indispensable pour gérer cet ensemble de
Cattle...
Pour récapituler
Transport de marchandises avant les années 60
Multiplicité des
marchandises
Est ce que je
m’inquiète de
l’interaction entre
marchandises?
Multiplicité des
méthodes de
transport et de
stockage
Est ce que je
peux transporter
rapidement et de
manière fluide?
Le conteneur a apporté une solution
Multiplicité des
marchandises
Est ce que je
m’inquiète de
l’interaction entre
marchandises?
Multiplicité des
méthodes de
transport et de
stockage
Est ce que je
peux transporter
rapidement et de
manière fluide?
Et en IT, ça donne quoi ?
Multiplicité des
piles applicatives
Est ce que les
services et
applications
interagissent de
manière
appropriée ?
Multiplicité des
plateformes
matérielles ou
virtuelles
Est-ce que je
peux migrer
rapidement et de
manière fluide?
User
DB
QA
server
Development
VM
Contributor’s
laptop
Customer
Data Center
Production Cluster
Public
Cloud
Static
website
nginx 1.5 + modsecurity + openssl + bootstrap 2
Web
frontend
Ruby + Rails + sass + Unicorn
Queue
Redis + redis-sentinel
Analytics
DB
hadoop + hive + thrift +
OpenJDK
Le conteneur apporte LA solution 
32
Multiplicité des
piles applicatives
Est ce que les
services et
applications
interagissent de
manière
appropriée ?
Multiplicité des
plateformes
matérielles ou
virtuelles
Est-ce que je
peux migrer
rapidement et de
manière fluide?
User
DB
Analytics
DB
Queue
Web
frontend
Static
website
QA
server
Development
VM
Contributor’s
laptop
Customer
Data Center Production Cluster
Public
Cloud
Consiste à reconstruire la vue qu’un processus a de son
environnement d’exécution
Lui donner l’illusion qu’il est le seul à s’exécuter sur la machine,
avec une arborescence de fichiers limitée par le périmètre du
container
Le principe
En image
VM
■Les conteneurs permettent de conditionner l'application avec son
environnement d'exécution complet, soit tous les fichiers nécessaires à
son exécution. L'image de conteneur contient toutes les dépendances
de l'application, elle est portable et cohérente au fur et à mesure qu'elle
passe du développement au test et enfin à la production.
Récapitulatif
Fonctionnalité Conteneur VM
Définition Virtualisation d'OS Virtualisation de serveur
OS Partage OS hôte Chaque VM a son propre OS
Taille Mo Go
Démarrage secondes minutes
Kernel Partagé avec l'hôte
Chaque VM a son propre
Kernel
Bref, quels usages pour les conteneurs
■Configurer des environnements de développement locaux qui
s'exécutent exactement comme un serveur de production
■Exécuter plusieurs environnements de développement à partir du
même hôte avec un logiciel, des systèmes d'exploitation et des
configurations uniques
■Permettre à quiconque de travailler sur le même projet avec les mêmes
paramètres, quel que soit l'environnement hôte
Et le DevOps la dedans ?
En termes de part de marché, les technologies de conteneurs les plus
largement adoptées ne sont pas étonnant: Docker à 52%
et Kubernetes en tant d'orchestrateur à 30%.
Un point intéressant révèle que 71% des personnes interrogées ont
déployées des conteneurs dans une machine virtuelle, ce qui signifie que
les machines virtuelles ne vont pas disparaître, mais la tendance est de
réduire les coûts de licence.
La tendance du marché
Source: Diamanti
■Efficacité: la consommation (cloud) a lieu sur le conteneur plutôt que
sur l'application ou la machine virtuelle, densité d’applications bien
supérieure, sans sacrifier les performances, tout en réduisant le temps
nécessaire pour effectuer des tâches courantes, en accélérant le
déploiement en s'intégrant parfaitement dans une chaîne DevOps
■Flexibilité: plate-forme de conteneurs véritablement agnostique, offrant
une véritable portabilité, basés sur des normes ouvertes et s'exécutent
sur toute infrastructure (Cloud, virtuelle, ...)
■Sécurité: les plates-formes de conteneur isolent les applications de
l'infrastructure, ainsi que des autres applications
Trois principales caractéristiques
■Comme tout élément de l'infrastructure informatique, les conteneurs
doivent être surveillés et contrôlés
■La courte durée de vie des conteneurs et leur densité accrue ont des
implications importantes dans la surveillance des infrastructures qui
doivent être surveillés individuellement
■La réponse réside dans les outils d’orchestration. Ceux-ci surveillent,
gèrent le clustering et la planification des conteneurs
L’orchestration, pourquoi faire ?
■Il existe trois solutions majeures d'orchestration de conteneurs dans le
cloud : Docker Swarm, Kubernetes (K8s pour les intimes) et
Mesosphere, mais Kubernetes est de loin le programme d'orchestration
le plus répandu
■Docker intègre Kubernetes dans sa plateforme Docker, tout comme
Microsoft avec Azure ou encore Mesosphere avec DC/OS
■54% des entreprises Fortune 100 utilisent Kubernetes.... Faites-le (bon)
choix !
La tendance du marché
■Continuité - lorsqu'une application est composée de composants
granulaires, il devient beaucoup plus facile de faire évoluer cette
application en mettant à jour et en améliorant ces composants
individuellement.
■Résilience - maintenir la disponibilité et la réactivité en cas d'échec d'un
regroupement de conteneurs. Cela signifie qu'un Datacenter n'a pas
besoin de répliquer l'application entièrement pour basculer vers
l'application secondaire en cas de défaillance !
■Évolutivité - capacité intégrée des charges de travail de se multiplier
dans le système, afin de les redimensionner selon des règles définies
Trois fonctions essentielles
IaC permet de fournir une infrastructure reproductible, standardisée et
extensible et est l'une des premières étapes de l'intégration des pratiques
DevOps au sein d'une entreprise
On gère la gestion de la configuration dans le pipeline d'intégration de
de livraison continue
La promesse
■Infrastructure as Code repose sur des outils offrant une abstraction
haut niveau des ressources d'infrastructure, offrant une bien meilleure
lecture qu'un fichier JSON
■La séparation de la configuration du code, et de sa variabilisation
permettront de maximiser l'usage du template pour de multiples
environnements (1 template servira à 4 environnements)
■Le code devient ainsi un build, qui est combiné avec une configuration
pour créer une version
Le principe de l’IaC
Distinguer la différence entre l'orchestration de la configuration et le
management de la configuration:
■le premier inclut des outils comme Terraform ou DsC qui automatise le
déploiement
■le second inclut d'autres outils comme Ansible qui aide à configurer les
systèmes (création de compte de services, ...) et applications
(installation de SQL Server, ...) sur des infrastructures préalablement
déployées avec Terraform
Terraform, Chef, Puppet, Ansible… même combat ?
■Il ressort principalement 3 uses cases concernant le Serverless : des
APIs "simple" et scalable, l'automation, et le Data Processing. Les
avantages sont multiples: configuration minimale, support multi
langages (python, NodeJS, Java, Powershell, ...), support de l'ALM et le
streaming des logs
■Les applications sans serveur déployées sont fondamentalement sans
administration et évoluent automatiquement avec la demande, ce qui
évite de gérer des instances de serveur et centrées sur le CODE avec
une tarification adaptée (paiement à l'exécution du code et non par
instance)
Serverless, FaaS, … Kézako ???
■On entend beaucoup de choses sur le Serverless, que c'est le NoOps
par excellence, que cela va induire un "DEPRECATED" sur les
conteneurs, etc...
■La technologie Serverless se limite à un déclenchement d'une
exécution de code (fonction) selon un besoin (événement), sans qu'un
serveur doive fonctionner en continu
■Point bloquant important, le Serverless est locké par Cloud Providers
qui utilisent leurs propres services, API, ... Une portabilité n'est donc
pas possible et nécessite une réécriture du code de la fonction
(OpenFaaS, Kubeless, IronFunctions, ?)
Quelques informations
Analyse de données anormales toutes les 15 minutes
Exemple d’une application Serverless
■Les APM modernes (orientés Cloud et/ou DevOps) permettent
d'améliorer la performance, réduire le temps de résolution d'incident(s),
d'anticiper les problèmes, d'identifier les "roots causes", d'améliorer
l'expérience utilisateur, les tests, ...
■Les APM peuvent fournir des analyses prédictives pour identifier les
anomalies et alerter les équipes DevOps avant que le service soit
impacté
■Plus la solution APM sera capable d'identifier un problème rapidement,
plus vite les équipes DevOps pourront mitiger l'impact !
La promesse des APM
■Outils d’analyse pour aider à diagnostiquer les problèmes
■Permettre d’améliorer continuellement les performances
■Large éventail de plates-formes, notamment .NET, Node.js et J2EE, …
■S’intègre au processus DevOps et offre des points de connexion à un
large éventail d’outils de développement
Azure Application Insights
■Lorsque nous parlons de Self Healing ou Auto Remediation, on parle
d'un système capable de percevoir qu'il ne fonctionne pas
correctement et, sans intervention humaine, de faire les ajustements
nécessaires pour rétablir son fonctionnement normal
■On pourrait presque parler ici de "Autonomic Computing", mais ce
terme sous-entends en plus que l'application est auto-configurable,
auto-optimisée et auto-protégée
■Mais pas que !!! Pour qu'une application puisse s'auto-réparer, elle doit:
détecter les échecs, répondre aux échecs et enregistrer et surveiller les
défaillances pour obtenir des informations opérationnelles
Quid du NoOps ?
Une approche NoOps signifie l’ automatisation du déploiement, de la
surveillance et de la gestion des applications
On pourrait aussi avoir une approche uniquement NoOps sans DevOps ?
Il faut garder à l'esprit d'avoir comme cible une transition totalement
automatisée entre le développement et l'exploitation
La promesse NoOps, c'est une infrastructure qui a atteint un tel niveau
d'automatisation qu'aucune équipe OPS n'est nécessaire pour l'administrer…
…pour le Cloud…
NoOps… Un DevOps réussi ?
■On parle ici de "Secure by design", DevSecOps consiste à prendre en
compte dans la démarche globale DevOps dès le début, l'intégration
des équipes sécurité dans ce dispositif, pour prévenir et corriger plus
facilement et rapidement des problèmes de sécurité, d'intégrer les
contraintes sécurité client, ...
■Un certain nombre d'aspects liés à la sécurité peuvent être intégrés et
automatisés dans la chaîne CI/CD DevOps comme la signature de
code, test unitaires, dans le but, à minima de couvrir les problèmes de
sécurité OWASP TOP10
Tiens, j’ai entendu parler de DevSecOps ?!
■Les opérations restent essentielles dans toute démarche DevOps mais
le métier se transforme : les éléments serveurs, réseaux, etc doivent
approcher une méthode Infra as Code, un administrateur ne
provisionnera plus à la main une VM mais un docker ou une VM
"Térraformée" et "Puppetisée" qui s'intègre dans une chaîne DevOps
■NoOps ne signifie pas forcément plus d'opérations, mais plutôt
d'intégrer By Design toutes les méthodologies et technologies
abordées ici pour pousser l'automatisation au maximum en vue de
limiter, voir faire disparaître les interventions manuelles/humaines sans
ou peu de valeur ajoutée
Nous y voilà…
■Pour conclure, les sujet abordés ici permettront à coup sûr de tendre
vers le NoOps !
■comme l'Infra as Code et apportera des apports indéniables et mesurables
rapidement
■Mais quoiqu'il en soit, NoOps est encore très jeune dans son approche,
et il y aura toujours besoin des OPS pour maintenir les architectures et
les infrastructures, à minima pour les superviser
Le mot de la fin
Merci!

Contenu connexe

Tendances

DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011Henri Gomez
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020NimeOps
 
Rex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesRex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesChristophe Furmaniak
 
REX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryREX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryDamien Goldenberg
 
Objectif libre - OpenStack
Objectif libre - OpenStackObjectif libre - OpenStack
Objectif libre - OpenStackDigitalPlace
 
OpenStack - open source au service du Cloud
OpenStack - open source au service du CloudOpenStack - open source au service du Cloud
OpenStack - open source au service du CloudLINAGORA
 
OpenStack & DevOps, l'Open Source au service du Cloud
OpenStack & DevOps, l'Open Source au service du CloudOpenStack & DevOps, l'Open Source au service du Cloud
OpenStack & DevOps, l'Open Source au service du CloudMichel-Marie Maudet
 
Introduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupIntroduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupAdrien Blind
 
Formation libre OpenStack en Français
Formation libre OpenStack en FrançaisFormation libre OpenStack en Français
Formation libre OpenStack en FrançaisOsones
 
Alter Way's digitalks - Docker : des conteneurs pour tout faire ?
Alter Way's digitalks - Docker  : des conteneurs pour tout faire ?Alter Way's digitalks - Docker  : des conteneurs pour tout faire ?
Alter Way's digitalks - Docker : des conteneurs pour tout faire ?ALTER WAY
 
Production logicielle, outils et pratiques
Production logicielle, outils et pratiquesProduction logicielle, outils et pratiques
Production logicielle, outils et pratiquesJohan Moreau
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsPublicis Sapient Engineering
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvementUlrich VACHON
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèseCOMPETENSIS
 
Etude de la virtualisation : Réseau & Cloisonnement
Etude de la virtualisation : Réseau & CloisonnementEtude de la virtualisation : Réseau & Cloisonnement
Etude de la virtualisation : Réseau & CloisonnementAntoine Benkemoun
 
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?Adrien Blind
 

Tendances (20)

DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
DevOps - Retour d'expérience - MarsJug du 29 Juin 2011
 
REX Devops Docker
REX Devops DockerREX Devops Docker
REX Devops Docker
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020
 
Rex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantesRex docker en production meeutp-docker-nantes
Rex docker en production meeutp-docker-nantes
 
REX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous DeliveryREX sur l'outilage Continuous Delivery
REX sur l'outilage Continuous Delivery
 
Objectif libre - OpenStack
Objectif libre - OpenStackObjectif libre - OpenStack
Objectif libre - OpenStack
 
OpenStack - open source au service du Cloud
OpenStack - open source au service du CloudOpenStack - open source au service du Cloud
OpenStack - open source au service du Cloud
 
OpenStack & DevOps, l'Open Source au service du Cloud
OpenStack & DevOps, l'Open Source au service du CloudOpenStack & DevOps, l'Open Source au service du Cloud
OpenStack & DevOps, l'Open Source au service du Cloud
 
Introduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetupIntroduction to Unikernels at first Paris Unikernels meetup
Introduction to Unikernels at first Paris Unikernels meetup
 
Openstack proposition
Openstack propositionOpenstack proposition
Openstack proposition
 
Formation libre OpenStack en Français
Formation libre OpenStack en FrançaisFormation libre OpenStack en Français
Formation libre OpenStack en Français
 
Alter Way's digitalks - Docker : des conteneurs pour tout faire ?
Alter Way's digitalks - Docker  : des conteneurs pour tout faire ?Alter Way's digitalks - Docker  : des conteneurs pour tout faire ?
Alter Way's digitalks - Docker : des conteneurs pour tout faire ?
 
Virtualisation
VirtualisationVirtualisation
Virtualisation
 
Production logicielle, outils et pratiques
Production logicielle, outils et pratiquesProduction logicielle, outils et pratiques
Production logicielle, outils et pratiques
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOps
 
Présentation Docker
Présentation DockerPrésentation Docker
Présentation Docker
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
 
Etude de la virtualisation : Réseau & Cloisonnement
Etude de la virtualisation : Réseau & CloisonnementEtude de la virtualisation : Réseau & Cloisonnement
Etude de la virtualisation : Réseau & Cloisonnement
 
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
DevOps, NoOps, everything-as-code, commoditisation… Quel futur pour les ops ?
 

Similaire à L'évolution vers le (Dev)NoOps

Sw 100 fr docker conteneurisation des applications
Sw 100 fr docker conteneurisation des applicationsSw 100 fr docker conteneurisation des applications
Sw 100 fr docker conteneurisation des applicationsStephane Woillez
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptxboulonvert
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxZALIMAZA
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxZALIMAZA
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfboulonvert
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxZALIMAZA
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxssuserf298861
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxZALIMAZA
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxZALIMAZA
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptxZALIMAZA
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxZALIMAZA
 
Kuberbetes 101: Unlocking containerisation’s full potential
Kuberbetes 101: Unlocking containerisation’s full potentialKuberbetes 101: Unlocking containerisation’s full potential
Kuberbetes 101: Unlocking containerisation’s full potentialOVHcloud
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptxZALIMAZA
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxZALIMAZA
 
La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...Laurent Goujon
 
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...Jasmine Conseil
 
SUSE Expert Days Paris 2018 – CaaSP
SUSE Expert Days Paris 2018 – CaaSPSUSE Expert Days Paris 2018 – CaaSP
SUSE Expert Days Paris 2018 – CaaSPSUSE
 
Architecture Moderne dans le Cloud en 2018
Architecture Moderne dans le Cloud en 2018Architecture Moderne dans le Cloud en 2018
Architecture Moderne dans le Cloud en 2018Marius Zaharia
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOpsMicrosoft
 
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...OCTO Technology
 

Similaire à L'évolution vers le (Dev)NoOps (20)

Sw 100 fr docker conteneurisation des applications
Sw 100 fr docker conteneurisation des applicationsSw 100 fr docker conteneurisation des applications
Sw 100 fr docker conteneurisation des applications
 
Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptx
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdf
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptx
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptx
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptx
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptx
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptx
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptx
 
Kuberbetes 101: Unlocking containerisation’s full potential
Kuberbetes 101: Unlocking containerisation’s full potentialKuberbetes 101: Unlocking containerisation’s full potential
Kuberbetes 101: Unlocking containerisation’s full potential
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptx
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptx
 
La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...
 
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
 
SUSE Expert Days Paris 2018 – CaaSP
SUSE Expert Days Paris 2018 – CaaSPSUSE Expert Days Paris 2018 – CaaSP
SUSE Expert Days Paris 2018 – CaaSP
 
Architecture Moderne dans le Cloud en 2018
Architecture Moderne dans le Cloud en 2018Architecture Moderne dans le Cloud en 2018
Architecture Moderne dans le Cloud en 2018
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
 
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...
La Duck Conf - "Microservices & Servicemesh : le retour des frameworks d'entr...
 

L'évolution vers le (Dev)NoOps

  • 3. ■Introduction ■Une application Cloud Native ? ■L’approche DevOps ■Les conteneurs et architecture orientées micro-service ■Infrastructure As Code – IaC ■Les architectures Serverless ■L’Application Management Performance dans une chaîne NoOps ■L’approche NoOps ■Conclusion Agenda
  • 4.
  • 5. ■Nouvelle façon de concevoir, déployer & d’opérer les infra & applis ■NOUVEAU business model ! ■Une transformation CLOUD c’est transformer son Operating & Delivery Model ■Nouvelles notions: PaaS, serverless, conteneurs, micro services, … ■Utiliser les outils cloud native ■Nouvelles façons de travailler: DevOps, DevSecOps, NoOps ■Mort des admins (?), transformation des métiers admin & dev => Chaine réussie d’une transformation cloud ! Le Cloud: le messie ? Oui, mais…
  • 6.
  • 7. ■Méthodologie pour construire des applications software-as-a-service qui : ■Utilisent un format déclaratif pour l’automatisation des installations ■Ont un contrat clair avec l’OS sous jacent et qui offrent une portabilité maximale pour l’exécution sur différents environnements ■Sont adaptées à un déploiement sur des plateformes cloud ■Minimisent la divergence entre développement et production et permettent un déploiement continu pour un maximum d’agilité ■Peuvent monter en charge sans changement majeur d’outillage, d’architecture ou de pratique de développement Les Twelve Factor
  • 8. Faites moi un sandwich 1. Prendre du pain 2. Le couper en deux 3. Mettre du beurre sur un morceau 4. Poser une tranche de jambon 5. Mettre la deuxième tranche de pain Format déclaratif Je veux ce sandwich “Un sandwich avec deux tranches de pain. Il doit avoir du beurre sur les morceaux de pain et une tranche de jambon entre les deux morceaux de pain  Impératif  Déclaratif
  • 9.
  • 10. ■Il existe plusieurs approches, classique (Waterfall par exemple) et DevOps (Agile, ...) qui incluent les OPS (Ingénieurs systèmes, architectes, ...) et les DEV (développeurs, Architectes logiciels, ...). ■Dans une approche classique: ■Les DEV produisent du code, les évolutions fonctionnelles, ... ■Les OPS mettent à disposition les infrastructures sans tenir compte des évolutions logicielles mais plutôt en se concentrant sur le SLA du service ainsi que la performance associée ■Dans une approche de type DevOps, l'ensemble des acteurs, soit les DEV et les OPS se répartissent les responsabilités et sont tous impliqués dans la chaîne de mise en production d'une application Le concept DevOps
  • 11. Le concept DevNoOps, les nouvelles technologies permettront de s'affranchir des OPS dans le sens où le code de l'infrastructure ne deviendra plus qu'une variable dans la chaîne ! En images
  • 12. CI, CD… KEZAKO ? CI: intégration continue, une pratique qui vise à faciliter la préparation d'une version CD: une livraison continue ou un déploiement continu
  • 13. ■Intégration continue consiste à fusionner les modifications dans la branche principale aussi souvent que possible. Les modifications du développeur sont validées en créant une génération et en exécutant des tests automatisés par rapport à la génération ■Livraison continue est une extension de l'intégration continue qui, en plus d'avoir automatisé les tests, automatise le processus de publication et de déploiement à tout moment en cliquant sur un bouton ■Déploiement continu va plus loin car chaque modification apportée à toutes les étapes de votre pipeline de production est transmise aux utilisateurs. Il n'y a pas d'intervention humaine, et seul un test échoué empêchera le déploiement d'un nouveau changement dans la production En détail
  • 15.
  • 16.
  • 23. ■Chaque micro service dispose de son datastore ■Cycle de vie indépendant pour chaque micro service ■Peu / pas d’adhérence entre micro services ■Scalabilité indépendante ■Déploiements plus petits, plus fréquents, plus nombreux ■Isolation des ressources Les micro services en bref
  • 24. ■Les architectures micro-services permettent des déploiements plus petits, plus fréquents et plus nombreux ■Cela qui induit une multiplication des conteneurs (Cattle) car une application pensée micro-services est découpée en de multiples services/composants ■L'orchestrateur sera révélera indispensable pour gérer cet ensemble de Cattle... Pour récapituler
  • 25.
  • 26. Transport de marchandises avant les années 60 Multiplicité des marchandises Est ce que je m’inquiète de l’interaction entre marchandises? Multiplicité des méthodes de transport et de stockage Est ce que je peux transporter rapidement et de manière fluide?
  • 27.
  • 28. Le conteneur a apporté une solution Multiplicité des marchandises Est ce que je m’inquiète de l’interaction entre marchandises? Multiplicité des méthodes de transport et de stockage Est ce que je peux transporter rapidement et de manière fluide?
  • 29.
  • 30. Et en IT, ça donne quoi ? Multiplicité des piles applicatives Est ce que les services et applications interagissent de manière appropriée ? Multiplicité des plateformes matérielles ou virtuelles Est-ce que je peux migrer rapidement et de manière fluide? User DB QA server Development VM Contributor’s laptop Customer Data Center Production Cluster Public Cloud Static website nginx 1.5 + modsecurity + openssl + bootstrap 2 Web frontend Ruby + Rails + sass + Unicorn Queue Redis + redis-sentinel Analytics DB hadoop + hive + thrift + OpenJDK
  • 31. Le conteneur apporte LA solution  32 Multiplicité des piles applicatives Est ce que les services et applications interagissent de manière appropriée ? Multiplicité des plateformes matérielles ou virtuelles Est-ce que je peux migrer rapidement et de manière fluide? User DB Analytics DB Queue Web frontend Static website QA server Development VM Contributor’s laptop Customer Data Center Production Cluster Public Cloud
  • 32. Consiste à reconstruire la vue qu’un processus a de son environnement d’exécution Lui donner l’illusion qu’il est le seul à s’exécuter sur la machine, avec une arborescence de fichiers limitée par le périmètre du container Le principe
  • 34. ■Les conteneurs permettent de conditionner l'application avec son environnement d'exécution complet, soit tous les fichiers nécessaires à son exécution. L'image de conteneur contient toutes les dépendances de l'application, elle est portable et cohérente au fur et à mesure qu'elle passe du développement au test et enfin à la production. Récapitulatif Fonctionnalité Conteneur VM Définition Virtualisation d'OS Virtualisation de serveur OS Partage OS hôte Chaque VM a son propre OS Taille Mo Go Démarrage secondes minutes Kernel Partagé avec l'hôte Chaque VM a son propre Kernel
  • 35. Bref, quels usages pour les conteneurs
  • 36. ■Configurer des environnements de développement locaux qui s'exécutent exactement comme un serveur de production ■Exécuter plusieurs environnements de développement à partir du même hôte avec un logiciel, des systèmes d'exploitation et des configurations uniques ■Permettre à quiconque de travailler sur le même projet avec les mêmes paramètres, quel que soit l'environnement hôte Et le DevOps la dedans ?
  • 37. En termes de part de marché, les technologies de conteneurs les plus largement adoptées ne sont pas étonnant: Docker à 52% et Kubernetes en tant d'orchestrateur à 30%. Un point intéressant révèle que 71% des personnes interrogées ont déployées des conteneurs dans une machine virtuelle, ce qui signifie que les machines virtuelles ne vont pas disparaître, mais la tendance est de réduire les coûts de licence. La tendance du marché Source: Diamanti
  • 38. ■Efficacité: la consommation (cloud) a lieu sur le conteneur plutôt que sur l'application ou la machine virtuelle, densité d’applications bien supérieure, sans sacrifier les performances, tout en réduisant le temps nécessaire pour effectuer des tâches courantes, en accélérant le déploiement en s'intégrant parfaitement dans une chaîne DevOps ■Flexibilité: plate-forme de conteneurs véritablement agnostique, offrant une véritable portabilité, basés sur des normes ouvertes et s'exécutent sur toute infrastructure (Cloud, virtuelle, ...) ■Sécurité: les plates-formes de conteneur isolent les applications de l'infrastructure, ainsi que des autres applications Trois principales caractéristiques
  • 39.
  • 40. ■Comme tout élément de l'infrastructure informatique, les conteneurs doivent être surveillés et contrôlés ■La courte durée de vie des conteneurs et leur densité accrue ont des implications importantes dans la surveillance des infrastructures qui doivent être surveillés individuellement ■La réponse réside dans les outils d’orchestration. Ceux-ci surveillent, gèrent le clustering et la planification des conteneurs L’orchestration, pourquoi faire ?
  • 41. ■Il existe trois solutions majeures d'orchestration de conteneurs dans le cloud : Docker Swarm, Kubernetes (K8s pour les intimes) et Mesosphere, mais Kubernetes est de loin le programme d'orchestration le plus répandu ■Docker intègre Kubernetes dans sa plateforme Docker, tout comme Microsoft avec Azure ou encore Mesosphere avec DC/OS ■54% des entreprises Fortune 100 utilisent Kubernetes.... Faites-le (bon) choix ! La tendance du marché
  • 42. ■Continuité - lorsqu'une application est composée de composants granulaires, il devient beaucoup plus facile de faire évoluer cette application en mettant à jour et en améliorant ces composants individuellement. ■Résilience - maintenir la disponibilité et la réactivité en cas d'échec d'un regroupement de conteneurs. Cela signifie qu'un Datacenter n'a pas besoin de répliquer l'application entièrement pour basculer vers l'application secondaire en cas de défaillance ! ■Évolutivité - capacité intégrée des charges de travail de se multiplier dans le système, afin de les redimensionner selon des règles définies Trois fonctions essentielles
  • 43.
  • 44. IaC permet de fournir une infrastructure reproductible, standardisée et extensible et est l'une des premières étapes de l'intégration des pratiques DevOps au sein d'une entreprise On gère la gestion de la configuration dans le pipeline d'intégration de de livraison continue La promesse
  • 45. ■Infrastructure as Code repose sur des outils offrant une abstraction haut niveau des ressources d'infrastructure, offrant une bien meilleure lecture qu'un fichier JSON ■La séparation de la configuration du code, et de sa variabilisation permettront de maximiser l'usage du template pour de multiples environnements (1 template servira à 4 environnements) ■Le code devient ainsi un build, qui est combiné avec une configuration pour créer une version Le principe de l’IaC
  • 46. Distinguer la différence entre l'orchestration de la configuration et le management de la configuration: ■le premier inclut des outils comme Terraform ou DsC qui automatise le déploiement ■le second inclut d'autres outils comme Ansible qui aide à configurer les systèmes (création de compte de services, ...) et applications (installation de SQL Server, ...) sur des infrastructures préalablement déployées avec Terraform Terraform, Chef, Puppet, Ansible… même combat ?
  • 47.
  • 48. ■Il ressort principalement 3 uses cases concernant le Serverless : des APIs "simple" et scalable, l'automation, et le Data Processing. Les avantages sont multiples: configuration minimale, support multi langages (python, NodeJS, Java, Powershell, ...), support de l'ALM et le streaming des logs ■Les applications sans serveur déployées sont fondamentalement sans administration et évoluent automatiquement avec la demande, ce qui évite de gérer des instances de serveur et centrées sur le CODE avec une tarification adaptée (paiement à l'exécution du code et non par instance) Serverless, FaaS, … Kézako ???
  • 49. ■On entend beaucoup de choses sur le Serverless, que c'est le NoOps par excellence, que cela va induire un "DEPRECATED" sur les conteneurs, etc... ■La technologie Serverless se limite à un déclenchement d'une exécution de code (fonction) selon un besoin (événement), sans qu'un serveur doive fonctionner en continu ■Point bloquant important, le Serverless est locké par Cloud Providers qui utilisent leurs propres services, API, ... Une portabilité n'est donc pas possible et nécessite une réécriture du code de la fonction (OpenFaaS, Kubeless, IronFunctions, ?) Quelques informations
  • 50. Analyse de données anormales toutes les 15 minutes Exemple d’une application Serverless
  • 51.
  • 52. ■Les APM modernes (orientés Cloud et/ou DevOps) permettent d'améliorer la performance, réduire le temps de résolution d'incident(s), d'anticiper les problèmes, d'identifier les "roots causes", d'améliorer l'expérience utilisateur, les tests, ... ■Les APM peuvent fournir des analyses prédictives pour identifier les anomalies et alerter les équipes DevOps avant que le service soit impacté ■Plus la solution APM sera capable d'identifier un problème rapidement, plus vite les équipes DevOps pourront mitiger l'impact ! La promesse des APM
  • 53. ■Outils d’analyse pour aider à diagnostiquer les problèmes ■Permettre d’améliorer continuellement les performances ■Large éventail de plates-formes, notamment .NET, Node.js et J2EE, … ■S’intègre au processus DevOps et offre des points de connexion à un large éventail d’outils de développement Azure Application Insights
  • 54. ■Lorsque nous parlons de Self Healing ou Auto Remediation, on parle d'un système capable de percevoir qu'il ne fonctionne pas correctement et, sans intervention humaine, de faire les ajustements nécessaires pour rétablir son fonctionnement normal ■On pourrait presque parler ici de "Autonomic Computing", mais ce terme sous-entends en plus que l'application est auto-configurable, auto-optimisée et auto-protégée ■Mais pas que !!! Pour qu'une application puisse s'auto-réparer, elle doit: détecter les échecs, répondre aux échecs et enregistrer et surveiller les défaillances pour obtenir des informations opérationnelles Quid du NoOps ?
  • 55.
  • 56. Une approche NoOps signifie l’ automatisation du déploiement, de la surveillance et de la gestion des applications On pourrait aussi avoir une approche uniquement NoOps sans DevOps ? Il faut garder à l'esprit d'avoir comme cible une transition totalement automatisée entre le développement et l'exploitation La promesse NoOps, c'est une infrastructure qui a atteint un tel niveau d'automatisation qu'aucune équipe OPS n'est nécessaire pour l'administrer… …pour le Cloud… NoOps… Un DevOps réussi ?
  • 57. ■On parle ici de "Secure by design", DevSecOps consiste à prendre en compte dans la démarche globale DevOps dès le début, l'intégration des équipes sécurité dans ce dispositif, pour prévenir et corriger plus facilement et rapidement des problèmes de sécurité, d'intégrer les contraintes sécurité client, ... ■Un certain nombre d'aspects liés à la sécurité peuvent être intégrés et automatisés dans la chaîne CI/CD DevOps comme la signature de code, test unitaires, dans le but, à minima de couvrir les problèmes de sécurité OWASP TOP10 Tiens, j’ai entendu parler de DevSecOps ?!
  • 58.
  • 59. ■Les opérations restent essentielles dans toute démarche DevOps mais le métier se transforme : les éléments serveurs, réseaux, etc doivent approcher une méthode Infra as Code, un administrateur ne provisionnera plus à la main une VM mais un docker ou une VM "Térraformée" et "Puppetisée" qui s'intègre dans une chaîne DevOps ■NoOps ne signifie pas forcément plus d'opérations, mais plutôt d'intégrer By Design toutes les méthodologies et technologies abordées ici pour pousser l'automatisation au maximum en vue de limiter, voir faire disparaître les interventions manuelles/humaines sans ou peu de valeur ajoutée Nous y voilà…
  • 60. ■Pour conclure, les sujet abordés ici permettront à coup sûr de tendre vers le NoOps ! ■comme l'Infra as Code et apportera des apports indéniables et mesurables rapidement ■Mais quoiqu'il en soit, NoOps est encore très jeune dans son approche, et il y aura toujours besoin des OPS pour maintenir les architectures et les infrastructures, à minima pour les superviser Le mot de la fin

Notes de l'éditeur

  1. Quelques exemples
  2. CD: une livraison continue ou un déploiement continu, et bien que ces deux pratiques aient beaucoup en commun, elles ont également une différence significative que nous allons détailler
  3. Les architectures micro-services permettent des déploiements plus petits, plus fréquents et plus nombreux mais ils doivent être fortement découplés, distribués et élastiques Ce qui induit une multiplication des conteneurs (Cattle) car une application pensée micro-services est découpée en de multiples services/composants qui sont faciles à updater, débugger, etc...
  4. Les containers sont isolés mais partagent l’OS et le cas échéant certaines librairies. Il en résulte un déploiement et un redémarrage plus rapide, moins d’overhead, ainsi qu’une grande facilité de migration
  5. Je prends l'exemple de mon blog où j'ai plus que divisé par deux les coûts de son hébergement en passant d'une VM à une solution de conteneur, en l'occurrence Docker. Donc les coûts Azure sont moindres, tout comme les dépenses de maintenance et de licence. Efficacité: la consommation (cloud) a lieu sur le conteneur plutôt que sur l'application ou la machine virtuelle, génère un impact mesurable à tout point de vue grâce à une densité d’applications bien supérieure à celle des machines virtuelles, sans sacrifier les performances, tout en réduisant le temps nécessaire pour effectuer des tâches courantes, en accélérant le développement et le déploiement en s'intégrant parfaitement dans une chaîne de déploiement continu DevOps Flexibilité: avec une plate-forme de conteneurs véritablement agnostique, les entreprises bénéficient d'une réelle flexibilité en libérant les applications de leur environnement et de pouvoir les héberger en fonction des besoins. De plus, les conteneurs offrent une véritable portabilité car ils sont basés sur des normes ouvertes et s'exécutent sur toute infrastructure (Cloud, virtuelle, ...). Ainsi, les entreprises n'ont plus besoin de s'engager à long terme sur leur infrastructure Sécurité: les plates-formes de conteneur isolent les applications de l'infrastructure, ainsi que d'autres applications, ce qui réduit la surface exposée
  6. Il existe trois solutions majeures d'orchestration de conteneurs dans le cloud : Docker Swarm, Kubernetes (K8s pour les intimes) et Mesosphere, mais Kubernetes est de loin le programme d'orchestration le plus répandu (anciennement BORG qui était utilisé par google pour ses propres besoins pour gérer ses charges de travail à l'échelle mondiale et sur des dizaines de milliers de nœuds). Il y a quelques temps, Mesosphere a intégré Kubernetes, en l'intégrant à DC/OS. Docker intègre Kubernetes dans sa plateforme Docker, tout comme Microsoft avec Azure... Les utilisateurs peuvent choisir d'utiliser Kubernetes et / ou Docker Swarm pour l'orchestration, mais il convient de noter que 54% des entreprises Fortune 100 utilisent Kubernetes.... Faites-le (bon) choix !
  7. La tâche principale de l'orchestrateur consiste à maintenir l'état de fonctionnement des applications dans son giron, il gère un cluster de nœuds faisant référence à des serveurs physiques ou virtuels. La tâche principale de l'orchestrateur consiste à maintenir l'état de fonctionnement des applications dans son giron, il gère un cluster de nœuds faisant référence à des serveurs physiques ou virtuels. 
  8. On pourrait presque parler de template dynamique s'inscrivant parfaitement dans une logique DevOps !
  9. pourrait ton parler de la mort de la documentation ? à condition de bien commenter son code)
  10. Bref, on pourrait presque parler de template dynamique s'inscrivant parfaitement dans une logique DevOps, car on va gérer la gestion de la configuration dans le pipeline d'intégration de de livraison continue. IMMUTABLE et FRYING !
  11. On entend beaucoup de choses sur le Serverless, que c'est le NoOps par excellence, que cela va induire un "DEPRECATED" sur les conteneurs, etc... On va plutôt dire que c'est du "Cloud Native" par excellence et que la réalité est que tout composant a besoin d'OPS même ceux sur lesquels où il y a peu de contrôle. Il ne faut pas confondre Serverless et NoOps. Si on prend le mot Ops (Opérations) cela ne signifie pas uniquement des opérations d’administration des systèmes. Cela signifie également à minima le suivi, le déploiement, la sécurité, la gestion du réseau, ... Mais la jeunesse de la technologie induit d'autres contraintes opérationnelles comme le debug, par exemple.
  12. NoOps peut s'inscrire essentiellement dans du PaaS mais pas seulement, on pourrait décorréler le NoOps de l'approche DevOps pour réduire les opérations d'exploitations telles que la remédiation basée sur de l'IA, par exemple. Certains diront que NoOps est un DevOps réussi... NoOps est très orienté Cloud par nature et non au Datacenter traditionnel, car dans ces derniers on aura toujours des tâches "bas niveau" comme le provisionning de serveur physique, switches réseaux, stockage, ... Il faut faire abstraction de ces éléments, les conteneurs abordés plus haut sont LA réponse pour du NoOps (mais DevOps aussi).
  13. Un certain nombre d'aspects liés à la sécurité peuvent être intégrés et automatisés dans la chaîne CI/CD DevOps comme la signature de code, test unitaires, intégration dans des Runtime Application Self Protection (RASP), ou encore paramétrer le WAF (Web Application Firewall) en mode apprentissage, ... dans le but, à minima de couvrir les problèmes de sécurité OWASP TOP10.
  14. A titre d'exemple, les Datacenters Azure, qui sont énormes ne sont maintenus que par une poignée de personnes, je pense que l'on peut parler ici de NoOps mais dans l'esprit "infrastructure management"...
  15. Mais bien entendu, toutes les structures ne sont pas des des GAFAM mais certains éléments abordés ici peuvent se mettre facilement en œuvre comme l'Infra as Code et apportera des apports indéniables et mesurables rapidement.