Stabilité vs immobilisme


11/01/2021 stabilité production service qualité performance résilience pérénnité sérénité

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.

Acteur de l'énergie


01/05/2020 performance optimisation scalabilité résilience architecture

Contexte

Dans le cadre du passage en production de son application, cet acteur se pose la question des performances de sa plateforme. Suite à des premiers tests insatisfaisants, cet acteur 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.

Web, Ops & Data - Aout 2017


30/08/2017 cloud docker microsoft aws cncf lambda serverless kubernetes linux windows elasticsearch kibana index search fullstack rethinkdb flash openweb api sécurité checklist certificat hpkp revocation performance tiers publicité

Cloud

Container & Orchestration

Documentation

  • Read & Write The Doc : les slides d’un talk donnant de bonnes pratiques sur la manière et les pratiques à adopter/éviter en matière de documentation.

Elasticsearch

  • Installing the Elastic Stack on Windows : Dans le cadre de la sortie de Elasticsearch 5.5, le support de l’installateur Windows est officiel. Ce billet montre comment installer Elasticsearch, Kibana et Filebeat sous un environnement Windows.
  • Taking A Look At Kibana’s Time Series Visual Builder : la future version 6 de Kibana va se doter d’un visualisateur orienté données temporelles (time series). L’auteur du billet rappelle que c’était un point faible de Kibana jusqu’à présent (vis à vis de Grafana notamment), que les essais avec Timelion ne répondaient que partiellement à ce besoin mais que là, Elastic semble être sur le point de rattraper son retard. A évaluer même si une plateforme TICK+Grafana (Telegraf, InfluxDB, Chronograf, Kapacitor) demandera moins de ressources qu’une stack Elastic/Kibana avec certes des capacités d’indexation moins forte mais le besoin n’est pas forcément là…
  • Elasticsearch: la grande migration : retour d’expérience des équipes Tech de M6 Web sur la migration de leur cluster Elasticsearch de la version 1.7 vers 5.2.
  • Small, Medium, or Large - Scaling Elasticsearch and Evolving the Elastic Stack to Fit : Elastic publie un billet intéressant donnant différents types de configuration & architectures pour des besoins autour d’ELK allant de simple à très complexe et fournir des pointeurs vers différentes ressources utiles.
  • Starting Down the Path of APM for the Elastic Stack : les prémices de la fonctionnalité APM (Application Performance Monitoring) d’Elastic suite au rachat d’Opbeat. Pour le moment, il s’agit de la pré-sortie des version serveurs et des clients ; pour la nouvelle UI, il va falloir attendre encore un peu mais des dashboards sont déjà accessibles via Kibana.
  • Introducing Index Sorting in Elasticsearch 6.0 : Dans sa version 6.0 à venir, il sera possible de définir des index triés dans Elasticsearch. Cette définition du tri se fera lors de la création de l’index. Si cela doit permettre de sortir des résultats plus rapidement, dans certains cas, cela peut pénaliser sérieusement la performance d’Elasticsearch. A utiliser à bon escient !

Full Stack

  • Développeur full stack ? Oui… mais… : enfin un bon article démystifiant le concept parfois fumeux de “full-stack” : “Quand nous parlons de profil full stack, cela signifie que le développeur est spécialisé dans certains domaines, tout en ayant des connaissances sur d’autres sujets. En général, nous considérons un développeur full stack comme maîtrisant au moins 3-4 sujets. Mais cela ne couvre pas l’ensemble des besoins."

NoSQL

Open Web

Sécurité

  • API Security Checklist : une check-list pour les aspects sécurité d’une API qui reprend les principaux points: authentification, traitement des entrée/sorties, infrastructure, etc.
  • CSP Cheat Sheet : Une page de présentation rapide et consise des options de configuraiton liée à CSP (Content Security Policy)
  • Revocation is broken : excellent billet sur les problèmes liés à la révocation de certificats et les nouvelles pistes à venir pour mieux traiter ce sujet.
  • I’m giving up on HPKP : l’auteur explique en quoi HPKP (HTTP Public Key Pinning) est compliqué et dangereux à mettre en place ; à la fin, le jeu n’en vaut pas la chandelle et qu’il vaudrait mieux ne pas tenir compte de cette pratique pour donner une bonne note aux configurations de sécurité des sites web. Il indique aussi les alternatives à venir et leurs avantages sur la solution actuelle.

Web Performance

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)

Nuage de tags

kubernetes docker influxdb timeseries traefik grafana kafka ansible elasticsearch postgres python warp10 aws sécurité mysql redis terraform tick cassandra cloud helm ovh git swarm telegraf rancher résilience test timescaledb chronograf docker-compose flux gitlab ptsm architecture arm confluent dashboard devops ksql log machine-learning microservice monitoring prometheus s3 serverless spark angularjs api bilan cert-manager cncf container cérénit dns gcp graphql hashicorp iac ingress java javascript opensource operator optimisation perspective raspberrypi service-mesh sql ssh stream vscode warpscript windows csp documentation elastic flows gke hpkp influxace jenkins kafka-streams kapacitor kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx npm orientdb performance pipeline redhat rest rethinkdb reverse-proxy rook sauvegarde scaleway agile apm automatisation azure bash big-data bigdatahebdo ceph certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie deployment diff fluxlang forecast framework gdpr gitlab-ci grav hsts http/3 https hypriot hébergement influxdata influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup molecule mongodb nosql nvidia openebs percona php pip podman postgresql reaper registry replication rootless rpi rsyslog runc scale secrets société solr sre systemd timezone tls vault virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme akka alerte alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arima arrow audit bastion beam beat bounded-context branche brigade browser buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart checklist chrome ci cilium cloud-init cloud-native cloud-storage clusterip cnab cni cockroachdb code codeurs-en-seine commit confluence conftest consul context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data data-engineer data-pipelining data.gouv.fr datacenter dataviz date date-scientist ddd debezium debian delta deprek8 desktop devoxx dig distributed-systems dive docker-app docker-hub docker-registry docker-swarm dockershim documentdb dog dokcer données-personnelles draft drop-in duration déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frontend fsync fullstack github gitignore glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud infrastructure-as-code ingénierie inspec iot jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel letsencrypt linky liste-de-diffusion loadbalancer logstash logstatsh loi mailing-list management maturité mesh mesos message metallb micro-service mot-de-passe mqtt multi-cloud médecine métrique network newsletter nodeport nomad null object-storage observability observabilité opa opendata openmetrics openshit openssh openstack openweb over-engineering ovhcloud packaging pandas parquet partiql password persistent-volume-claim pipenv pod portainer portworx prediction prescience production ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quasardb quay questdb queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rgpd rhel rkt rolespec root rpo rto rust rwd safe-harbor scalabilité scanner schema scp sdk search select serverless-architecture service service-account service-worker setuptools sftp sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl stabilité stash statistique storage superset suse sympa syslog-ng sérénité terracost terrascan test-unitaire tidb tiers timer timescale timestream training travail tsl ubuntu unikernel unit ux vector vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc warpstudio web yaml yq yubikey