FormationSpringBoot 6 DevOps

Orange septembre
2020
de Spring à Spring Boot

Spring Boot et la démarche DevOps
industrialiser ses développements Java
sommaire
– enjeux du DevOps
– du build au déploiement continu
– les niveaux de Cloud
– monolithe ou microservices ?
– twelve-factor apps
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

enjeux du DevOps

enjeux du DevOps
Le DevOps a pour avantages :
– de réduire le Time To Market :

- délai entre l'idée (fonctionnalité, correction de bug) et sa mise à disposition pour le client
- arrivée sur le marché plus rapide (adoption par les clients de nos produits plutôt que ceux des concurrents)
- réduction du stock de code qui végète avant qu'il soit mis en production
– d'apprendre des retours clients et des métriques :
- rectifier le tir si besoin et au plus vite
- éviter le coût important de réorientation/recentrage alors que le développement est très avancé
– de diminuer les risques et le stress :
- la mise en production devient une activité quotidienne et maîtrisée
- mise en production de petits morceaux de code bien identifiés
- ciblage rapide du code défectueux, avec retour en arrière facilité
- prise en charge des demandes (évolutions, corrections...) au fil de l'eau
- mises en production tous les 6 mois : les demandes affluent pour ne pas manquer ce train.
Comment mettre en place le DevOps ?
Il est nécessaire d'automatiser (donc d'outiller) au maximum les différentes tâches, qui vont du développement jusqu'au
déploiement sur une plateforme.

du build au déploiement continu

écosystème de développement

IDE
L'IDE (Integrated Development Environment) est l'outil le plus utilisé par le développeur. Il intègre beaucoup de plugins (Maven, Git...)
permettant de faciliter son travail.
Les plus populaires dans le monde Java sont :
– IntelliJ : l'équivalent d'Eclipse, avec un noyau et des plugins.

– Spring Tools : basé sur Eclipse, avec un ensemble de plugins orientés vers le développement basé sur la pile Spring
– Eclipse : IDE comportant un noyau et de nombreux plugins, que l'on peut ajouter suivant les besoins
– VSCode : IDE léger pouvant servir à beaucoup de langages.
Rappel : le plus important dans un projet, c'est le code en lui-même, pas l'outil avec lequel on l'écrit.

build automatique : Maven, Gradle
L'une des briques de base à mettre en place est la construction automatisée du logiciel.
Il faut que le processus de build :
– puisse être rejoué en un clic souris ou en une ligne de commande

– puisse s'exécuter sur différents environnements, y compris hors de l'IDE
– puisse être exécuté manuellement ou automatiquement par un outil
– exécute les tests (unitaires, d'intégration...).
Les 2 outils les plus populaires dans le monde Java sont :
– Maven : le plus répandu chez Orange

– Gradle : de plus en plus populaire.
Cet outil se situe au coeur du processus d'intégration continue car il est utilisé à la fois par :
– le développeur sur son poste (dans son IDE par exemple)

– l'outil d'intégration continue pour produire l'artefact de livraison (jar, war...).

gestion des sources : Git
L'autre brique fondamentale à mettre en place est le gestionnaire de sources.
Il permet :
– la gestion des versions des fichiers

– la gestion de la configuration du projet
– le travail collaboratif
– la traçabilité, l’historisation
– la gestion du cycle de vie (avec les branches)
– la qualité des livrables (conséquence des points ci-dessus)
– la reproductibilité du build.
Git est le gestionnaire de sources préconisé.
Voici un article intéressant pour une gestion efficace des branches avec Git.

plateforme de développement : GitLab
Les principales fonctionnalités de GitLab sont de :
– gérer des dépôts Git

– gérer les membres d'un projet et leurs droits
– déposer des Issues pour lister les bugs
– proposer des Merge Requests pour fusionner les branches
– lancer des pipelines d'intégration et de déploiement continus via le module GitLab CI/CD
– fournir un Wiki pour la documentation.

intégration continue
Plus on découvre une erreur tard, plus son coût de correction est élevé.
Une fois le build automatisé et les sources gérées en configuration, il est possible de passer à l'étape suivante : l'intégration continue
(continuous integration).
Elle doit :
– valider la capacité à construire le livrable à tout moment, à partir des sources placées en configuration
– lancer les tests (unitaires, de performance, de sécurité, d'intégration...)
– s'exécuter après chaque modification des sources en configuration (dans l'idéal).
Des environnements de tests sont créés à la volée puis supprimés lors de ces phases.

intégration continue : GitLab CI/CD
GitLab CI/CD (continuous integration/ continuous deployment) est un module de GitLab, qui permet de mettre en oeuvre facilement un
pipeline d'intégration et de déploiement continu, en ajoutant à la racine du projet un fichier au format yaml : .gitlab-ci.yml.
Jenkins est un autre outil d'intégration continue.

inspection continue
L'inspection continue (continuous inspection) fournit des tableaux de bord s'appuyant sur des métriques :
– les duplications de code

– le respect des règles de programmation, confrontées à des jeux de bonnes pratiques
– le calcul de la complexité du code (nombre de lignes par classes, couplage entre les classes…)
– le taux de documentation
– la couverture de code par les tests unitaires
– le bilan d'exécution des tests unitaires et d'intégration
– l'évolution dans le temps de la qualité de code du projet
– détection de failles de sécurité
– ...

inspection continue
Un certain nombre d'outils permettent d'analyser le code et les dépendances du projet :
– Dependency-Check : détection de dépendances comportant des vulnérabilités connues

– Fossology : vérification des licences utilisées dans le projet
– SonarQube : analyse de code pour évaluer sa qualité et détecter des problèmes de sécurité
– Coverity : détection de vulnérabilités dans le code
– CheckMarx : détection de vulnérabilités dans le code
– jaCoCo : couverture de tests.
Attention : ces outils permettent de s'assurer que le code est bien écrit (lisible, maintenable, évolutif, sans vulnérabilités
connues...), mais pas qu'il répond aux besoins. C'est le rôle des tests (unitaires, d'intégration, d'acceptance...).

inspection continue : SonarQube

livraison continue : GitLab CI/CD
Une fois le processus d'intégration/inspection continue maîtrisé, on peut envisager l'étape suivante : la livraison continue (continuous
delivery).
Le livrable généré peut être déployé automatiquement sur un serveur d'intégration, techniquement le plus proche possible de la plateforme de
production.
Il passera également des tests d'acceptation (acceptance tests) qui consistent à vérifier :
– les non-régressions fonctionnelles

– la bonne couverture du besoin.
Ces tests peuvent être manuels, mais le mieux est de les automatiser. Il serait dommage d'avoir des plateformes disponibles en quelques
minutes, mais que les tests manuels prennent 15 jours.
Une fois ces tests passés, le livrable peut être déployé sur la plateforme de production, soit :
– manuellement : lancement d'un script à la main

– automatiquement : on peut alors pousser le processus jusqu'au bout.

déploiement continu : GitLab CI/CD
Le déploiement continu (continuous deployment) consiste à déployer automatiquement le livrable en production, sans intervention manuelle.
Cela veut dire que :
– à chaque commit dans la gestion des sources (ou très régulièrement), la nouvelle fonctionnalité/la correction de bug se retrouve en
production en quelques minutes
– une application peut être mise en production plusieurs fois par jour
– en cas de problème, le retour en arrière est très simple.
L'ensemble contribue à rassurer au moment souvent stressant et critique de la mise en production.
Note : veiller à ce que l'application reste très intuitive car il n'est plus possible de former les utilisateurs à chaque mise en
production.

les niveaux de Cloud

contrôle ou abstraction ?

contrôle ou abstraction ?

du IaaS au SaaS
IaaS (Infrastructure as a Service) : le projet gère des machines virtuelles. Il doit installer toute la pile logicielle (OS, serveurs web, bases de
données, application...) et gérer tout le cycle de vie de la VM.
CaaS (Container as a Service) : le projet gère des conteneurs (Docker notamment). Il peut potentiellement déployer n'importe quelle techno,
et continue de gérer le cycle de vie (backup, versions, patchs).
PaaS (Platform as a Service) : le projet ne livre que l'application (qui doit être compatible avec les technologies supportées par le PaaS). Le
PaaS instancie rapidement et à la demande des environnements d'exécution. Il prend en charge également des problématiques telles que la
sécurité, la disponibilité, le dimmensionnement, la redondance... Les produits d'infrastructure utilisés (serveur d'applications, patchs de
sécurité, technologies supportées, services offerts...) sont gérés par le PaaS (une équipe dédiée).
FaaS (Function as a Service) : le projet livre de très petites unités exécutables. Le process démarre et s'arrête à la demande. Facturation a
l'execution time du process.
SaaS (Software as a Service) : l'utilisateur final accède (via abonnement en général) aux logiciels via le web, sans devoir les installer en local.
Il utilise donc toujours la dernière version disponible. Quand un projet consomme une API, cette API peut être vue comme un SaaS.

PaaS : Cloud Foundry
Cloud Foundry (CF) est un PaaS open source développé par Pivotal. Il supporte plusieurs langages et frameworks, tels que Java, Node.js,
PHP, Python, Ruby... On y manipule des packages applicatifs.
La configuration de l'application (environnement, services...) se fait dans un fichier manifest.yml situé à la racine du projet :
Une instance nommée AeroFoundry est déployée côté DTSI.
Une fois l'application construite (par l'intégration continue...), pour la déployer, le PaaS va :
– instancier l'environnement d'exécution

– instancier des services utilisables par l'application (persistance, MOM, messagerie, logs, monitoring...)
– gérer dans le temps les évolutions/contraintes : la scalabilité, la volumétrie, la QoS (certains services offrent plusieurs niveaux).

CaaS - PaaS : Kermit
Kermit est une autre offre PaaS-CaaS interne Orange. Il s'appuie sur l'outil Red Hat OpenShift (jouant le rôle de PaaS) qui est une usine à
images Docker (conteneurs), le tout orchestré par Kubernetes.
Le projet a plusieurs possibilités pour déployer son application. Il peut fournir à Kermit :
– le livrable (exemple .jar) en sortie de l'intégration continue => PaaS

– l'image Docker qu'il a construite => CaaS
– les sources du projet, Kermit se chargeant de construire lui-même l'application et l'image Docker qui convient et de l'instancier.

ça PaaS ou ça CaaS ? Cloud Foundry ou Kermit ?
Privilégier Cloud Foundry quand :
– l'application respecte les 12 factors

– l'application est basée sur les standards du marché en terme de :
- pile logicielle
- modèle de programmation : stateless, architecture évolutive
– l'application peut s'appuyer sur des services disponibles sur un marketplace de CF (SSO, base de données, cache, messaging...)
– l'équipe ne veut pas se préoccuper de l'infrastructure sous-jacente (et de ses évolutions).
Privilégier Kermit quand :
– l'application a des besoins spécifiques (sur les protocoles réseaux utilisés, les middlewares, le langage...)
– l'équipe doit garder un contrôle accru sur la plateforme
– l'équipe possède une large expertise sur toute la chaîne du build au run.

monolithe ou microservices ?

cas des applications monolithiques
Les applications monolithiques ont certaines propriétés qui peuvent être des avantages comme des inconvénients.
Un langage unique sur toute l'application :
– avantages :
- montée en compétences plus facile sur toute l'application
- entraide facilitée entre membres du projet
- homogénéité du code
– inconvénients :
- ce langage n'est peut-être pas le plus adéquat selon les modules
- fort couplage entre les modules
- même si les technologies évoluent sur le marché, on doit continuer à coder avec l'existant (langages ou frameworks
obsolètes) même pour les nouvelles fonctionnalités.

Toute l'application est déployée au même endroit :
– avantages :
- plus simple à déployer
- pas de problème réseau entre composants
- gestion des problèmes transversaux simplifiés (configuration, logs...)
- il faut souvent mettre en place une scalabilité verticale (augmenter la puissance des machines)
- on provisionne des machines surdimensionnées dont les capacités seront réellement utiles qu'à de rares moments
- il faut toujours + de CPU, de RAM... car les applications sont de plus en plus gourmandes
- la loi de Moore tendant à arriver à ses limites, on ne peut plus trop compter sur les progrès des machines pour scaler
verticalement dans le futur
- chaque modification mineure dans l'application entraîne son redéploiement complet
- en cas de problème, toute l'application tombe.

Or, dans une application, tout n'est pas uniforme et homogène. Certaines parties sont plus ou moins :
– critiques en terme de fonctionnalités et/ou de sécurité

– stables dans le temps
– difficiles à coder
– sollicitées (pics de charge...).
Dans une application monolithique, toutes ces contraintes sont appliquées de fait partout. On doit faire des compromis (répondre
globalement à la plupart des exigences).

cas des microservices
Pour les microservices, là encore, certaines propriétés peuvent être vues comme des avantages ou des inconvénients, qui sont à peu près
inverses à ceux des applications monolithiques.
Chaque module est spécialisé dans une fonctionnalité, en tenant compte de ses contraintes :
– avantages :
- organisation de l'équipe projet et efforts mis en place (tests, sécurisation) en fonction des modules :
- critiques, mises à jour fréquentes, données sensibles : les meilleurs développeurs, beaucoup de tests, sécurisation renforcée,
automatisation...
- très sollicités : tests de charge, monitoring + poussé...
- non critiques, peu de charge : montée en compétence des débutants, gestion en best effort...
- ouverture sur internet, 24/7 : métriques d'usage de l'application, tests avec les outils du public...
- utilisation de la technologie la mieux adaptée au contexte (à un instant T)
- réécriture/migration simplifiée des modules écrits avec des technologies obsolètes dans des nouvelles technologies
- plusieurs langages à apprendre
- code très hétérogène
- difficultés d'entraide entre collègues.

Architecture distribuée :
– avantages :
- favorise la scalabilité horizontale
- instanciation à la demande de petites machines (conteneurs...)
- chaque noeud d'un module est identique à son voisin
- seuls les microservices très sollicités sont répliqués
- il faut s'appuyer sur une infrastructure solide (plateformes, réseau...)
- ajout de nouveaux outils pour orchestrer toute l'application
- vue d'ensemble de l'application plus complexe
- moins de lisibilité sur qui appelle quoi, difficulté de tracer le parcours client
- plus de composants donc plus de risques que l'un d'eux plante
- un problème insignifiant sur un module peut faire tomber un autre module, et difficulté d'en trouver la cause
- problèmes réseau : latence réseau possible (temps de réponses dégradés), coupures...

Pour les applications monolithiques, on fait tout pour qu'aucune panne n'intervienne.
Pour les microservices, il faut intégrer le fait que les pannes adviendront inévitablement du fait de la multiplication des composants. Il faut
faire en sorte que l'application réagisse bien dans ces cas là (Design for Failure) :
– redondance et décentralisation des composants : physiques, virtuelles (VM), de datacenters

– chaque composant doit être prêt à une panne d'infrastructure sous-jacente
– passer en mode dégradé ponctuellement
– traiter automatiquement la défaillance (arrêt/redémarrage du composant...)
– savoir détecter rapidement les problèmes et remonter à leur source
– analyser à froid les causes pour améliorer le système (pas besoin d'être dans l'urgence)
– ...

quand passer aux microservices ?
Toute application n'est pas éligible pour passer aux microservices.
Voici quelques points à prendre compte :
– investissement non négligeable au début du projet (outillage, organisation, pratiques de développement...)

– la maturité de l'équipe sur les microservices : ne pas être trop ambitieux dès le départ
– les avantages des microservices s'accompagnent aussi de gros inconvénients
– l'apport des micro-services est surtout valable à moyen et long terme :
- si la durée de vie de l'application est courte (sortie d'un film...), il n'y aura pas d'évolutions dans le temps et sa taille sera assez
petite à priori
– si l'application est assez simple :
- commencer par isoler le frontend (s'il y en a un) du backend, qui expose une API REST
- côté backend, démarrer par un monolithe puis isoler et sortir des fonctionnalités précises au fur et à mesure que le besoin s'en fait
sentir (gestion de la sécurité, des logs, un domaine fonctionnel...)
– si des domaines marqués sont identifiables dès le début, les séparer en mini-applications, pas forcément tout de suite en microservices
– ...

twelve-factor apps

twelve-factor apps
objectifs des twelve-factor apps
Les 12-factor apps sont des applications respectant 12 règles ou critères dans le but d'être délivrées en tant que (micro)services.
Ces applications sont conçues pour :
– offrir une grande portabilité entre les environnements d'exécution

– être déployées sur des plateformes Cloud
– minimiser les divergences entre les plateformes de développement, tests, production
– permettre le déploiement continu
– pouvoir augmenter la scalabilité de façon rapide
Note : ces 12 facteurs sont indépendants de tout langage de programmation, utilisant tout type de services externes (base de
données...).

microservices et twelve-factor apps
les 12 facteurs
1. base de code
Une base de code unique par application/microservice, gérée dans un gestionnaire de sources (avec des branches...). A partir de cette
base de code, on peut avoir plusieurs instances de l'application déployées (en développement, en test, en production...).
2. dépendances
Les dépendances doivent toujours être déclarées explicitement, sans dépendre de l'existence implicite de packages ou librairies fournis
par le système.
3. configuration
Avoir une stricte séparation entre le code et la configuration (portée par l'environnement). Ainsi, on peut déployer le même code sur
plusieurs environnements différents, en modifiant seulement la configuration (fichiers externalisés, variables d'environnement, serveur de
configuration...).
C'est un prérequis au facteur 5 (build, release, run).

les 12 facteurs
4. services externes
Il faut gérer les services externes locaux ou distants de la même manière. Chaque service externe est une ressource ayant un faible
couplage avec l'application. Ces ressources peuvent être attachées/détachées/remplacées à la demande suivant les situations.
5. build, release, run
Avoir une séparation stricte entre les étapes de build, release et run :
– build : transformation du code en un paquet autonome et exécutable

– release : ce paquet exécutable + la configuration du déploiement courant
– run : exécution de l'application dans un environnement.
6. processus
Le(s) processus d'une application est (sont) sans états (stateless) et ne partage(nt) rien. Toute donnée à persister (même les sessions
HTTP utilisateurs) doit l'être dans un service externe statefull comme une base de données (mais pas en mémoire ni sur le disque dur local,
qui peuvent être effacées par redémarrage du serveur...). Si un noeud tombe, un autre peut prendre le relais.

les 12 facteurs
7. associations de ports
L'application est auto-contenue (standalone) et expose ses services (ex : par HTTP) en les associant à un port qu'elle écoute pour
traiter les requêtes. Une application peut ainsi devenir le service externe d'une autre en lui fournissant son URL d'accès.
8. concurrence
Structurer l'application afin d'assigner à chaque service son processus. Cela permet de gérer au mieux le dimensionnement d'une
application, service par service, suivant leurs propres contraintes. Ainsi, il est simple d'ajouter/supprimer des processus (serveurs) en fonction
de la charge (scalabilité horizontale).
9. jetable
Les processus doivent être jetables : démarrés rapidement et arrêtés gracieusement. Les arrêts doivent terminer le travail en cours et
stopper la prise en charge de nouveaux travaux, mais aussi être robustes aux arrêts brutaux (via une file de messages...).

les 12 facteurs
10. parité développement/production
Garder le développement, la validation et la production aussi proches que possible pour favoriser le déploiement continu. Les
mêmes personnes développent et déploient, ceci de façon régulière et automatisée (toutes les qques heures, voire jours). Les développeurs
doivent utiliser au maximum les mêmes ressources externes que la production (base de données...).
11. logs
Une application ne doit pas gérer le stockage de ses logs (dans des fichiers) mais les considérer comme des flux de sortie. Ces flux
seront capturés par l'environnement qui pourra les aggréger avec les logs d'autres processus, les archiver...
12. processus d'administration
Les processus ponctuels d'administration devraient être lancés dans un environnement identique aux processus standards de
l'application. Le code d'administration doit être livré avec le code de l'application pour éviter les problèmes de synchronisation.

Spring Boot et les 12 facteurs
Spring Boot permet de répondre (ou au moins d'aider) à certains des 12 facteurs :
– 2. dépendances : les starters définissent la grande majorité des dépendances utiles au projet
– 3. configuration : facilité de lire des valeurs définies dans des fichiers properties (avec profils) ou des variables d'environnement grâce
aux classes et annotations adéquates
– 4. services externes : l'approche microservice de Spring Boot pousse à considérer toute ressource (locale ou distante) de la même
manière (notamment via des APIs)
– 7. associations de ports : une application Spring Boot est standalone grâce au serveur embarqué, et expose ses services sur un port
HTTP configurable (application.properties externalisé)
– 8. concurrence : Spring Boot est orienté microservices, chacun ayant son processus avec ses contraintes et ses spécificités, et la
possibilité de faire de la scalabilité horizontale fine (par microservice)
– 9. jetable : une application Spring Boot démarre en quelques secondes et peut s'arrêter gracieusement (endpoint /shutdown fourni par
Actuator)
– 10. parité développement/production : grâce au serveur embarqué, le même fat jar/war peut-être déployé en développement, test,
qualification et production.
– 12. processus d'administration : Spring Actuator offre des endpoints (URLs) de monitoring.

liens utiles
– Maven, Gradle
– Eclipse, Spring Tools, IntelliJ, VSCode
– GitLab, Git
– Jenkins
– Dependency-Check, Fossology, SonarQube, Coverity, CheckMarx, jaCoCo
– Spring Cloud
– Cloud Foundry
– Red Hat OpenShift, Kubernetes
– Docker

merci

FormationSpringBoot 6 DevOps

Transféré par

Droits d'auteur :

Formats disponibles

FormationSpringBoot 6 DevOps

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

FormationSpringBoot 6 DevOps

Transféré par

Droits d'auteur :

Formats disponibles

Orange septembre

de Spring à Spring Boot

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– de réduire le Time To Market :

Comment mettre en place le DevOps ?

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Les plus populaires dans le monde Java sont :

– IntelliJ : l'équivalent d'Eclipse, avec un noyau et des plugins.

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Il faut que le processus de build :

– puisse être rejoué en un clic souris ou en une ligne de commande

Les 2 outils les plus populaires dans le monde Java sont :

– Maven : le plus répandu chez Orange

– le développeur sur son poste (dans son IDE par exemple)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– la gestion des versions des fichiers

Git est le gestionnaire de sources préconisé.

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– gérer des dépôts Git

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Jenkins est un autre outil d'intégration continue.

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– les duplications de code

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– Dependency-Check : détection de dépendances comportant des vulnérabilités connues

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– les non-régressions fonctionnelles

– manuellement : lancement d'un script à la main

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Cela veut dire que :

L'ensemble contribue à rassurer au moment souvent stressant et critique de la mise en production.

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Une instance nommée AeroFoundry est déployée côté DTSI.

– instancier l'environnement d'exécution

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– le livrable (exemple .jar) en sortie de l'intégration continue => PaaS

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– l'application respecte les 12 factors

Privilégier Kermit quand :

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

Un langage unique sur toute l'application :

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– critiques en terme de fonctionnalités et/ou de sécurité

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)

– redondance et décentralisation des composants : physiques, virtuelles (VM), de datacenters

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)