Continuons les discussions ouvertes par ce sujet : comment faire cohabiter le mouvement DevOps avec l’introduction des datastore NoSQL ?
Carl Quinn, anciennement chez Netflix, aujourd’hui chez Riot Games commence par définir le terme "DevOps". En résumé, le mouvement vise à :
- faire prendre conscience aux devs des problématiques des ops,
- informer les ops des contraintes des devs (TTM notamment),
- parfois avoir un ops dans chaque équipe de devs,
- avoir une vision du produit d’un bout à l’autre (mentalité end-to-end).
Ce mouvement est aujourd’hui très en vogue car les problématiques qu’il met en avant sont soulignées par le continous delivery.
Le problème est que les devs ne savent pas forcément de quels outils les ops auront besoin pour assurer l’exploitation d’un système. De ce fait, si les ops ne sont pas inclus dans les choix architecturaux d’une application, ils peuvent se retrouver à administrer un datastore NoSQL sans avoir les outils appropriés.
Kirk Pepperdine souligne qu’en ce moment c’est l’expérience des développeurs qui est prise en compte sur les bases de données NoSQL. Il faut alors choisir entre investir le temps de développement dans les fonctionnalités du système ou dans le développement d’outils pour les ops. Par exemple, Netflix a développé Priam, un outil (open-source) d’administration et de backup de cluster Cassandra.
Un retour d’expérience est fait sur la mise en production hasardeuse d’un datastore Cassandra :
- Pour les devs, le monde se termine le vendredi soir,
- Pour les ops, les astreintes sont 24h/24,
- Cassandra a été choisi par les devs sans impliquer les ops dans le choix d’architecture,
- L’effort de documentation sur l’exploitation du datastore n’a pas été assez conséquent,
- Un problème survenu le week-end a rendu impossible toute écriture dans le datastore, sans que les ops puissent rétablir la situation avant le lundi matin.
Pourtant, pour faciliter la vie de nos ops, il suffit simplement de discuter avec eux et de les considérer comme des clients :
- Quels sont leurs attentes (requirements) ?
- Comment vont-ils utiliser le système ?
Cette vision est surprenante, mais elle est tout à fait appropriée. Netflix considère tous les utilisateurs internes de ses composants comme des clients.
Kruno Markotic explique que nous sommes simplement en train d’inverser un système déjà utilisé. Dans un environnement bancaire, nous travaillons déjà avec :
- Les DBA dont l’objectif est que la base Oracle ait un uptime proche de 100%, qu’elle soit performante et que son intégrité soit assurée,
- Les ops qui s’assurent que l’application est toujours en cours d’exécution et qui gèrent les problèmes de production,
- Le support qui gère les remontées d’anomalies (niveau 1, 2 et plus).
On peut considérer les développeurs comme des clients de tous ces "services". Si nous voulons pouvoir demander la même chose d’un "DBA NoSQL", il faut lui en donner les moyens et donc le considérer comme notre client avant de nous considérer comme le sien.