Passer d'un écosystème baremetal à un univers micro services et dynamique

1. 1
PASSER D'UN ÉCOSYSTÈME BAREMETAL À UN
UNIVERS MICRO SERVICES ET DYNAMIQUE
POSS
05/12/2018
Thibaut Démaret – CTO
thibaut.demaret@worteks.com

2. 2
Cette présentation ne parlera pas
●
Les normes de codes
●
La refonte d'applications
●
Architecture logicielle
●
Comment faire du micro service :
https://fr.wikipedia.org/wiki/Philosophie_d%27Unix

3. 3
Cette présentation parlera
●
De la vision d'un Ops sur des problématiques
d'Ops dans un monde qui change

4. 4
Problèmatique d'Ops
●
Tout voir
●
Tout savoir
●
Ne pas être réveillé la nuit
●
Empêcher qu'un Dev est un accès Root

5. 5
Il n'y a pas longtemps, pas loin d'ici
Temps d'initialisation pour un projet :
●
Repository SVN (ca existe encore) : 2j
●
VM de développement (sans perf) : 3j
●
VMs de production : 2 semaines
●
D'autres environnements : on n'a pas la place
●
MEP : oulà il faut sortir le calendrier

6. 6
Sans justifier mais pourquoi ?
●
Seul un Ops peut toucher aux repositories
●
Il faut trouver de la place sur les serveurs
●
Il faut l'intégrer à :
-> la supervision
-> les logs
-> Installation les prérequis(cf pas de root/sudo)

7. 7
Le drame
Le DevOps arrive :

8. 8
Le changement
Les Dev et les Ops travaillent ensemblent

9. 9
La libération de l'Ops
Côté Ops :
●
Responsabiliser les Dev : Pollueur payeur
●
N'être plus les seuls réveillés la nuit
Côté Dev :
●
Enfin les droits Root
●
Des livraisons plus rapide

10. 10
La vérité sur les droits root

11. 11
En revanche
●
Intégrer les Ops dès le début
●
Fournir les outils CI / CD
●
Une MEP n'est pas un événement
●
Tous les jours, c'est permis :
https://www.estcequonmetenprodaujourdhui.info/

12. 12
Ce qu'il faut mettre à disposition
●
Les logs des environnements
●
Les métriques
●
Les bonnes pratiques sur l'allocation des
resources
●
Un moyen de tester
●
Un moyen de déployer

13. 13
Partons par l'exemple : avant
●
Une plateforme
●
L'exposition des logs
●
Une CI/CD
●
Métrique
●
Déploiement
●
Notifications

14. 14
Partons par l'exemple : maintenant
●
Une plateforme
●
L'exposition des logs
●
Une CI/CD
●
Métrique
●
Déploiement
●
Notifications

15. 15
Inutile si ?
●
L'information n'est pas transmise
●
Les logs ne sont pas formalisés (pas en debug)
●
Les métriques ne sont pas exposées
●
Les gens ne savent pas où regarder
●
Pas d'alerte
●
Pas les droits de se connecter...

16. 16
Ce qui reste souvent aux Ops
●
La PKI
●
Le réseau / Le parefeu
●
La gestion des mots de passes
●
La capacity planning
●
La gestion des allocations de ressources

17. 17
Peut-on aller plus loin ?
●
La PKI :
●
Le réseau / Le parefeu : Cloud Provider
●
La gestion des mots de passes
●
La capacity planning : Cloud Provider
●
La gestion des allocations de ressources

18. 18
Besoin des Ops ?

19. 19
Hélas non
●
Qui va gérer sous les cloud providers ?
●
Qui va gérer la CI/CD et les services annexes ?
●
Qui va gérer le capacity planning du cloud ?
●
Qui a les droits root ? :)

20. 20
Le bilan pour les Ops
●
Offrir un maximum de services aux Dev
●
Responsabiliser
●
Discuter et intégrer les équipes
●
Comprendre les besoins

21. 21
Le bilan pour les Dev
●
Intégrer vos Ops au plus tôt
●
Ne sortez pas une technologie de l'espace
=> Pollueur Payeur
●
Vous n'aurez pas les droits Root

22. 22
Questions