• 4 novembre 2015

    Velocity 2015 | One goal, one way to make it happen : Dev-Ops collaboration

    Velocity Amsterdam 2015 : « Build resilient system at scale »

    Velocity nous éveille aux bonnes pratiques dans les développements pour accélérer la livraison, comprendre finement le fonctionnement des plateformes et finalement livrer une expérience adaptée, utile et stable à l’utilisateur final.

    User centric : ne pas oublier l’utilisateur

    when_you_assume

    Il ne faut pas perdre de vue que tout le monde ne possède pas une connexion internet stable et haut-débit que se soit fixe ou mobile. Par exemple, nous sommes très minoritaires dans le monde à posséder un iPhone dernier cri connecté à la 4G. La plupart des personnes dans le monde utilisent de vieux Smartphones, souvent connectés à des réseaux 2G/3G. Ces pays comme l’Inde ou la Chine représentent un nouveau marché très important, et la rapidité d’un site (ou même l’affichage dans un navigateur tel qu’Opéra Mini) est décisive pour leur adoption dans ces pays. Facebook par exemple oblige tous ses salariés à utiliser la 2G les mardi. (Valérian Beaudoin) Le double enjeu est donc :

    •  Avoir les meilleurs performances possibles pour donner un sentiment d’instantanéité sur des smartphones modernes
    •  Rendre le site utilisable sur des téléphones anciens afin de ne pas manquer des marchés en plein développement

    « Nous ne sommes pas des magiciens mais des illusionnistes. » Pour palier à des latences que peuvent induire les infrastructures (computing, réseau, applicatif … ), il est très fortement conseillé d’utiliser des astuces pour faire patienter le client comme des barres de chargement, des animations de transition, des previews. Ainsi le temps d’attente total pour l’affichage complet de l’information à l’écran met plus de 4s mais grâce à ces astuces le client a patienté agréablement en voyant se construire progressivement l’information souhaitée. Le ressenti est donc plutôt positif. (Adrien Le Priol)

    Faut–il une interface utilisateur « riche » ou rapide ? « Don’t assume », c’est le constat qui revenait souvent. Il est préférable de savoir ce que les clients veulent plutôt que d’essayer de le deviner.

     Monitoring : technique + business

    Nous observons que les infrastructures monolithiques se font plus rares, elles se découpent en micro-services et les changements sont de plus en plus fréquents et rapides. Ces constats apportent une nouvelle vision sur le business. D’un côté cela permet d’adapter votre système à chaque projet, contexte, situation, et de livrer plus vite de nouvelles fonctionnalités. Mais de l’autre, les relations et potentiellement les dépendances se multiplient.

    La collecte de métriques est nécessaire pour mettre en évidence le goulot d’étranglement. Sans passer par l’ajout d’une sonde dans le code, surveiller l’application est impossible. Elle est le pont entre le monde du Dev et celui de l’Ops. Elle est construite de concert avec différents entrants métier, Dev et Ops, comme par exemple l’entrée d’un nouveau job, la sortie d’un nouveau job, le temps de traitement du job…

     » Mais tout surveiller est utopique et le temps nécessaire manque. Alors que faire ? Mettez plus l’accent sur la surveillance de métriques business.  » (Jeremy Smadja)

    We are all devops : une même direction où le service rendu est l’affaire des acteurs de la chaîne et pas d’une seule personne

    « Nous sommes tous DevOps » Le DevOps n’est pas l’affaire d’une personne mais de l’ensemble des collaborateurs. La communication et le partage de la connaissance est la pierre angulaire de la philosophie DevOps. Il est important pour chaque personne de comprendre les enjeux métier des collaborateurs, cela permet ainsi de mieux agir avec un objectif commun. On comprend alors mieux pourquoi il est nécessaire de partager les mêmes métriques métier concrètes. Ce n’est pas en diffusant que le serveur load à 15 que l’on peut mesurer la performance mais bien avec des métriques business. (Adrien Le Priol)

    DevOps : pas seulement des outils mais surtout une culture du partage

    Au delà des déploiements rapides ou encore des outils, la démarche DevOps s’organise autour :

    • D’une culture : try, fail and succeed, don’t use blame language
    • De stratégies partagées comme par exemple :
      • Comment orchestrer ses déploiements (git, chef, jira, selenium…) ?
      • Comment gérer ses données d’identification ?
      • Que se passe-t-il si l’application est down ?
      • Quelles sont les menaces qui pourraient réellement impacter votre processus métier et donc votre business ?

    Pour profiter pleinement de cette culture  :

    •  Les outils décloisonnent le monde du Dev et Ops et mettent en commun le KPI pour favoriser la cohésion des équipes et les feedbacks
    •  Le rapprochement Dev et Ops implique d’avantage les Dev dans une démarche de performance, d’analyse et de sécurité

    Voici les conférences auxquelles nous avons assistées + les liens vers les présentations pour certaines (quand elles sont disponibles).

    DevOps Culture/Management

    • Blame Language – slides
    • We are all Devops – slides
    • One year later: How Marks & Spencer revolutionized PerfOps after Velocity 2014 – program
    • Velocity Amsterdam 2015 – Burnout in Tech – program
    • Velocity Amsterdam 2015 – Optimizing Teams in a Distributed World

    Monitoring

    • Alert Overload – slides
    • Building Realtime metrics pipelines – slides
    • Forensic tools for in-depth performance investigation – slides
    • Measuring CDN performance and why you’re doing it wrong – slides
    • Statistics for engineers – program
    • The definition of normal – an introduction and guide to anomally detection – slides
    • Service instrumentation, monitoring and alerting with Prometheus – slides 

    Performance :

    • Demystifying SPDY and HTTP/2 – slides
    • Extreme web performance for mobile devices – slides
    • Fake it until you make it: Interface design to the rescue of performance – slides

    Security :

    Infrastructure

    • Blazing Bits – networking’s journey to being open – program
    • Designing good infrastructure tools – program
    • Testing Infrastructure – an introduction – program

Newsletter

Inscrivez-vous et tenez vous au courant de l’actualité Oxalide