Motoriste de vos plateformes et agitateur de séries temporelles

Un client m’a dit récemment : “Nicolas, tu es pénible - jusqu’à présent, je pensais que la solution X était bien, mais quand je vois les mises à jour à faire ici et là, ça devient pénible” et un de ces développeurs de me dire “Mais pourquoi mettre à jour, ça marche !”. Effectivement, ça marche jusqu’au jour où cela ne marche plus.

Souvent, on dépeint les développeurs comme voulant toujours des nouveautés et les ops comme voulant la stabilité et idéalement ne rien changer. Sauf que ne rien changer, ce n’est pas apporter de la stabilité mais juste de l’immobilisme. Darwin sait comment cela se finit, à la fin, le serveur ou l’application, ils meurent. Par ricochet, le projet et l’équipe projet peuvent aussi y passer.

Par ailleurs, nous sommes dans un monde qui évolue. Des nouveautés sont apportées, ainsi que des améliorations de performance mais aussi ne les oublions pas des failles. Dès lors, lorsque l’on fournit un service quelconque, la stabilité prend un autre sens à mon avis : il ne s’agit plus de figer le service dans un état donné mais plutôt de fournir un environnement qui permet au service de s’exécuter avec la même stabilité. Votre service vit dans un écosystème et celui-ci évolue. Dès lors, la stabilité de votre service implique d’être toujours en phase avec votre écosystème. Si votre service s’interface avec le fournisseur Y, vous devez toujours être en mesure de vous interfacer avec plutôt que de dire à votre client : “Le fournisseur Y a changé son API ou je ne sais quoi, vous ne pouvez plus utiliser le service”. Dans ce cas, ce n’est pas de la stabilité que vous apporter à votre client mais une régression. D’ailleurs, la littérature informatique a un terme pour cela “Le Maintien en Conditions Opérationnelles (MCO)” (à ne pas confondre avec “Le Maintien à bout de bras” ou “Le Maintien à flot”).

Et sinon, les projets d’upgrade tous les X ans qui prennent Y mois pendant lesquels on n’apporte aucune valeur au client le temps de faire cette fichue mise à jour, c’est d’un pénible et d’un frustrant. Et faut-il encore que ce budget d’upgrade - qui ne cesse de grossir par nombre de fois où il est reporté - soit un jour accordé.

Donc tout comme il est plus facile de ranger sa chambre chaque jour un petit peu plutôt qu’une fois par mois ou trimestre, la stabilité de votre plateforme, vous l’assurez en mettant à jour régulièrement vos composants. Il y a certes un petit effort régulier à faire. Certains pourront trouver ça pénible - mais vaut mieux ça que le “plus jamais ça” après un chantier d’un an de mise à jour. Les premiers rangements, vous allez les sentir passer car ils sont encore un peu gros. Mais au fur et à mesure, ils vont diminuer et être tout à fait acceptables. En faisant aussi des petites mises à jour incrémentales et pour les bugs que vous allez découvrir, il est aussi plus facile de voir ce qui a pu créer un bug dans le cadre de la mise à jour du fait de sa taille. Dans les grosses mises à jour, il y a tellement de coupables possibles que c’est une véritable partie de Cluedo que vous allez devoir mener pendant des semaines.

De plus, avoir des composants à jour vous permet d’être supporté par les éditeurs ou les communautés d’utilisateurs. Vous éviterez la réponse “Mettez à jour - passer à la version X pour être supporté - Je ferme le ticket”.

Donc oui, je vais fortement encourager mes clients à maintenir leur système à jour car je veux leur apporter la stabilité dont ils ont besoin. Au delà du fait aussi que je ne veux pas me retrouver dans une situation dantesque en cas de pépin majeur, c’est tout autant ma tranquillité que la leur dont je m’assure de façon régulière. Cerise sur le gâteau, ils bénéficient aussi des avancées des composants et peuvent à leur tour fournir un meilleur service à leurs clients et contribuer ainsi à la pérennité de leur entreprise.

Contexte

Dans le cadre du passage en production de son application, la SAFT se pose la question des performances de sa plateforme. Suite à des premiers tests insatisfaisants, la SAFT nous a sollicité pour identifier les points bloquants et trouver des solutions à court et moyen terme.

Notre réponse

• Revue et extension de la collecte de métriques et des dashboards associés pour améliorer l’observabilité de la plateforme
• Revue et mise en place des bonnes pratiques Drupal
• Exécution de tests de performance et identification des points bloquants
• Profiling de l’application via Blackfire permettant d’avoir une vue applicative et d’identifier l’authentification et plus particulièrement la phase de controle des mots de passe comme point de contention de l’API.
• Mise en place de pgbouncer pour découpler les connections réalisées par PHP à Postgresql pour ne pas la surcharger inutilement et améliorer les délais de réponse du fait du pool de connection
• Tunning de PHP-FPM
• Recommendation du remplacement de l’outil des tests de performance vegeta par k6 pour permettre d’avoir des tests plus dynamiques au niveau des données et avec une gestion des vagues de tests plus fine.
• Recommendation d’architecture ultérieure en vue d’améliorer la scalabilité et la disponibilité de la plateforme (scaling vertical et horizontal)

Bénéfices pour le client

• Expertise sur les plateformes web
• Connaissance prélable du contexte suite à la précédente mission.

Cloud

• AWS costs every programmer should know : l’article donne le coût moyen d’un vCPU, de la RAM et du stockage chez AWS pour permettre de définir rapidement une estimation de votre infrastructure.

(Big|Open) Data

• Lancement de schema.data.gouv.fr : Etalab lance schema.data.gouv.fr - une démarche de référencement et de validation des schémas des données pour améliorer la qualité des données mises à disposition

Containers et orchestration

• Kubernetes multi-nodes cluster with k3s and multipass : solution qui peut être intéressante pour monter un lab k8s sur MacOS avec multipass et k3s.
• polaris : Polaris est un outil qui valide que vos déploiements sur k8s respectent bien les bonnes pratiques.
• Kubernetes 1.15: Extensibility and Continuous Improvement : La version 1.15 semble surtout axé sur de la stabilisation et l’extensibilité des CRD avec l’apparition d’une gestion de schema plus évoluée, le support de la haute disponibilité et une meilleure gestion des certificats dans kubeadm et la poursuite de la sortie des plugins de stockage de la base de code vers les plugins CSI. Au passage, les plugins CSI gagnent une fonctionnalités : le clonage de volume (alpha).

Infrastructure

• LCC 211 - Interview sur la virtualisation avec Quentin Adam : Quentin Adam part du CPU et remonte les couches pour expliquer la (para) virtualisation et les conteneurs. Un nouveau monde s’est découvert devant mes yeux, je ne regarde plus mon CPU de la même façon.
• HAProxy 2.0 and Beyond et [ANNOUNCE] haproxy-2.0.0 : la version 2.0 du célèbre reverse proxy est sortie avec un nombre impressionnant de nouveautés/améliorations. On apprend aussi qu’une nouvelle version de l’ingress controller kubernetes devrait sortir sous peu.

Langages

• Pythonic Ways to Use Dictionaries : C’est tout de suite plus joli avec get() ou setdefault().

Sécurité

• RAMBleed, Reading Bits in Memory Without Accessing Them : les failles dans le CPU, c’est “so 2018”, en 2019, on innove et on découvre des failles dans la RAM. Pas de mitigation sans racheter des barrettes DDR4 et en activant la fonctionnalité TRR (Targeted Row Refresh).
• Security Advisory 2019-06-13 – Reduced initial randomness on FIPS keys : la déclinaison FIPS des clés Yubikey a une alerte de sécurité sur le niveau d’aléatoire fourni par lé clé pour certaines versions du firmware. Les propriétaires des clés éligibles peuvent les échanger auprès de Yubico en suivant une procédure.

SRE

• Friday Deploy Freezes Are Exactly Like Murdering Puppies : réflexion intéressante sur le “On ne déploie pas en production le vendredi” ; on peut ne pas le faire mais pour les bonnes raisons. Si vous n’avez que les mauvaises raisons, alors il faut travailler votre outillage et vos habitudes. Cela rend ce site obsolète.
• Reliability That Works : Le TL;DR est trop limitatif à mon sens : “TL:DR; Prefer investing in recovery instead of prevention” : si faire trop de prévention est illusoire et trop cher pour être acceptable, surtout quand elles sont hors de notre contrôle. Il convient plutôt de s’assurer que les erreurs ont un impact le plus petit possible quand elles surviennent et de pouvoir revenir à un état normal le plus rapidement/facilement possible. Il faut bien entrendre recovery comme retour à la normale et pas comme restauration/retour en arrière pour bien apprécier l’article.

Contexte

Le projet Mov’InBlue est un projet commun Valeo / Cap Gemini de dématérialisation de clé de voiture à destination des gestionnaires de flottes et des loueurs de voitures. Au travers d’une application mobile, vous pouvez ouvrir/fermer puis démarrer la voiture.

Notre réponse

• Architecture transverse au projet - support aux équipes produit, de développement et de production.
• Cartographie applicative
• Identification des SPOF et des scénarios d’amélioration de la résilience de la plateforme
• Collaboration à la définition de l’offre API/SDK et à la réflexion autour de l’API Management
• Participation aux réponses à appels d’offre
• Travaux autour des tests et de l’industrialisation de la plateforme

Bénéfices

• Expertise Web et Infrastructure permettant de vulgariser les activités et les concepts de développements et les aspects infrastructure auprès de l’équipe produit et/ou de l’équipe développement
• Expérience préalable en API Management

Contexte

Compta-online.com est une startup qui anime une communauté en ligne autour des problématiques comptables. Depuis 2008, elle souhaite déléguer l’infogérance de ses serveurs afin de bénéficier d’une expertise et pouvoir se focaliser sur son activité de développement du site et de sa communauté.

Notre réponse

• Réalisation d’un audit de sécurité de la plateforme, rédaction d’un plan d’action, implémentation d’une partie du plan d’action
• Infogérance du serveur (supervision, sécurisation, sauvegardes, optimisation, mises à jour, etc)
• Recommendation d’un hébergeur plus adapté aux besoins de la startup puis migration vers cet hébergeur
• Proposition puis implémentation de nouvelles architectures adaptées aux besoins et évolutions du site

Bénéfices

• Plateforme performante et évolutive pour rester adaptée aux besoins du site
• Plateforme sécurisée et résiliente
• Gestion de l’obscolescence technique
• Coûts d’hébergement maitrisés et au plus juste grâce au choix d’un hébergeur ayant une offre flexible
• Focus de la startup sur ses activités de développement