Bilan

Que de chemin parcouru depuis le premier chapitre et l’installation standalone de notre application ! De l’infrastructure jusqu’à l’application en passant par les accès, tout est maintenant redondant et tolérant aux pannes. Nous avons atteint l’objectif : notre application est en haute disponibilité.

Au-delà des mécanismes techniques mis en place, l’atteinte de cet objectif est le résultat d’une proche collaboration entre le développeur de l’application eni-todo et l’opérateur chargé de la plateforme, autrement dit entre le Dev et l’Ops. Le développeur doit prendre en compte les remarques de l’Ops sur l’architecture de son produit : intégrer un mécanisme de session, penser que plusieurs instances applicatives devront tourner, permettre à l’application de tourner dans un container… L’Ops doit prendre en compte les besoins du développeur : correctement dimensionner les ressources, gérer des mécanismes d’affinité, proposer le stockage nécessaire, etc.

Et on voit à quel point la frontière semble parfois devenir floue sur certains aspects ! Kubernetes, par exemple, nécessite de profondes connaissances système et réseau pour son installation et sa maintenance, mais aussi de grandes compétences fonctionnelles pour manipuler ses objets. Dev et Ops disposent au final d’une...

Pour consulter la suite, découvrez le livre suivant :
couv_EPHADIS.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
eni-todo
Suivant
Introduction