SRE et DevOps peuvent avoir un impact différent sur la structure et la culture d’une organisation. Il est donc essentiel de bien comprendre les différences entre Site Reliability Engineering (SRE) vs DevOps afin de partir du bon pied, que vous adoptiez l’un ou l’autre.
De mon expérience, la plupart des confusions sur le sujet viennent d’une incompréhension de l’origine et des principes fondateurs de chaque approche. Trop souvent, on ne se souvient que des outils et écosystèmes construits autour du DevOps et SRE et non leur essence.
Commençons par dissiper les confusions courantes et plongeons au cœur de ces approches. Découvrez l’histoire, les objectifs et les rôles de SRE vs DevOps, ainsi que les techniques et outils essentiels des meilleures pratiques.
Une brève histoire DevOps et SRE
Entre 2001 et 2008, le développement logiciel en mode Agile était dans tous les esprits et son adoption gagnait énormément de terrain au fil des années. Cependant, les départements d’opérations logicielles (Ops) agissaient comme un goulot d’étranglement dans le cycle de livraison de logiciels. Même si une équipe de développement travaillait par petits incréments, à la fin, un déploiement en production pouvait prendre des semaines, voir des mois.
En 2008, lors de la Conférence Agile (Toronto), Patrick Dubois présentait Agile Infrastructure & Operations, deux idées clés pour résoudre l’impasse Agile avec les opérations informatiques : déployer souvent et créer des équipes multidisciplinaires. C’était la naissance du DevOps, et ces deux idées sont toujours des valeurs fondamentales.
À cette époque, le DevOps était davantage un sujet de conférence, qu’une pratique bien répandue. Mais cela allait changer ; en 2010, David Farley et Jez Humble publiaient Continuous Delivery et donnaient ainsi le ton sur ce qu’une équipe DevOps multidisciplinaire devait faire pour déployer des applications aussi souvent que possible. C’est ainsi que l’âge d’or du DevOps a commencé.
Le SRE (Site Reliability Engineering) a précédé le DevOps de plus de 5 ans (créé en 2003 chez Google) en développant une fonctionnalité qui consistait à construire un framework pour gérer des systèmes à grande échelle. Cette bonne méthode était nécessaire pour assurer la fiabilité et la haute disponibilité promises à leurs clients, en accordant une attention supplémentaire.
Entre 2003 et 2016, l’approche SRE a été principalement adoptée par de grandes entreprises telles que Google, Facebook, Uber et Netflix. L’idée était de créer une équipe entre le développement et les opérations pour s’assurer que les systèmes étaient toujours accessibles (disponibilité) et à l’épreuve des pannes (fiabilité). Le SRE est à la fois une équipe, les outils et les pratiques que l’équipe utilise pour atteindre son objectif.
DevOps et SRE ont évolué presque en parallèle ; certains bataillant pour savoir lequel est meilleur. Cela a duré jusqu’en 2016, jusqu’à ce que les ingénieurs chez Google publient le livre SRE qui affirme :
“Class SRE implements interface DevOps.”
En bref, SRE est une variante du DevOps.
Je recommande de lire Team Topologies pour découvrir les différentes nouvelles fonctionnalités disponibles dans le domaine du DevOps. En effet, SRE représente uniquement l’une des nombreuses options, qui pourrait éventuellement ne pas être adaptée à votre organisation.
Quels sont les objectifs et les domaines
d’intérêt du DevOps et du SRE?
Si nous récapitulons notre leçon d’histoire, le DevOps est un état d’esprit et une culture. Le DevOps valorise la collaboration (multidisciplinaire) pour accélérer le rythme des déploiements en production tout en optimisant le temps.
La collaboration DevOps a abouti à des pratiques telles que la livraison continue et les chaînes d’outils associées qui permettent des cycles rapides de déploiement.
SRE est un cadre opérationnel, ce qui signifie un ensemble de pratiques pour assurer la disponibilité, la sécurité et la fiabilité des systèmes à grande échelle. Avec le recul, on s’est rendu compte finalement que SRE est une implémentation opinionée du DevOps. Le but ultime du SRE est d’assurer la meilleure expérience utilisateur. Pour un SRE la disponibilité, la mise à l’échelle et la fiabilité sont des procurations pour mesurer l’expérience utilisateur.
Les SREs réunissent autour d’une même table les parties prenantes, les Devs et les Ops pour identifier les métriques qui reflètent le mieux une bonne expérience utilisateur (vous avez peut-être entendu parler de SLO/SLI/SLA). Ils collaborent avec ces mêmes acteurs (parties prenantes, Dev et Ops) pour atteindre les objectifs fixés (par exemple, une disponibilité de 99,99 %).
Les deux approches, DevOps et SRE, visent toutes deux à améliorer la communication entre le développement et l’exploitation. Le but est de supprimer les obstacles et de garantir une qualité de service optimale pour les utilisateurs finaux.
Cependant, de par leur histoire parallèle, leur objectif diffère énormément :
- Pour le DevOps, on se concentre sur la vitesse de livraison en petit incrément (livraison en continu).
- Pour les SRE, on se concentre sur la disponibilité et fiabilité des services.
Voici une infographie qui résume tout ce que vous devez savoir :
Les rôle(s) du DevOps et du SRE
Abordons le sujet qui fâche. Le DevOps n’est pas un rôle ni une équipe ! Alors que SRE fait référence à la fois à un rôle et à une équipe d’ingénieurs assumant ce rôle.
Le DevOps valorise les équipes transverses, comme on l’a déjà dit. Le DevOps ne définit pas de rôles et cela va donc varier d’une entreprise à l’autre en fonction de leur taille. Mais, en général, vous trouverez ces types de rôles :
- Plus Dev : ingénieurs frontend, ingénieurs backend et assurance qualité (QA). Ce sont les rôles historiques du Dev.
- Plus Ops : ingénieurs Cloud, administrateurs de bases de données (DBA) et ingénieurs réseau. Ce sont des rôles historiquement plus Ops, mais qui ont tendance à disparaître dans les petites entreprises en raison des offres SaaS et IaaS.
- Au milieu : ce sont de nouveaux rôles nés de l’idée de faciliter la collaboration entre Dev et Ops. Certaines personnes se sont spécialisées au niveau de l’automatisation. Avec le temps, cette spécialisation s’est transformée en un rôle à part entière. La plupart de ces rôles se chevauche, car ils sont nés de différentes visions de ce qui fait un bon écosystème DevOps :
- Ingénieurs en automatisation : ils travaillent sur l’automatisation des pipelines et des cycles de vie des applications pour automatiser autant que possible chaque processus.
- Ingénieurs expérience de développement (DevXP) : ils travaillent sur les outils de développement et l’automatisation pour simplifier la vie des développeurs logiciel.
- Ingénieurs plateforme : ils travaillent à la construction d’abstractions (plateforme) entre le développement et les opérations.
- Ingénieurs SRE : ils passent 50 % de leur temps à effectuer des tâches Ops telles que la résolution d’incidents, l’astreinte et les interventions manuelles et le 50 % restant sur des tâches de développement de systèmes pour augmenter la résilience du système, la fiabilité et l’automatisation.
Et dans notre cas, nous avons également enregistré un entretien avec l’un de nos ingénieurs SRE afin de mieux comprendre leur rôle essentiel dans la garantie de la fiabilité et des performances du système.
Techniques notables en DevOps et SRE
Dans cette section, vous trouverez des articles relatifs aux bonnes pratiques de chaque approche. Maintenant, vous pouvez vous pencher sur les pratiques et les outils. Mais, ne faites pas l’erreur d’oublier l’origine du DevOps et SRE, ainsi que leur culture et leur focus.
Techniques du DevOps
Intégration continue en DevOps : méthodes et outils | Gologic
Liste des outils DevOps indispensables ∣ Gologic — Experts en DevOps
Plonger dans le torrent DevOps… et vaincre les courants contraires — # 1 | GOLOGIC
Techniques du SRE
SRE (ingénierie de la fiabilité des sites), c’est quoi ? — GOLOGIC
Google — Site Reliability Engineering
Les points clés DevOps vs SRE
Les deux concepts DevOps vs SRE ont évolué en parallèle, mettant tous deux l’accent sur l’optimisation du temps et de la production. Cependant, l’ingénierie SRE se présente comme une mise en pratique du DevOps. Ces approches partagent un objectif commun : briser les silos entre les équipes de développement et d’opérations, favorisant ainsi un environnement de travail collaboratif et efficient.
Essentiellement, la distinction SRE vs DevOps réside dans leur focus sur le niveau de qualité offert aux utilisateurs finaux. Le DevOps met fortement l’accent sur la livraison rapide, permettant aux organisations d’itérer et de publier rapidement des mises à jour. D’autre part, SRE accorde la priorité à la disponibilité et la fiabilité, garantissant que les systèmes logiciels sont toujours opérationnels en réduisant les risques d’incident.
Il est important de noter que le DevOps n’est pas un rôle, mais plutôt des équipes DevOps multidisciplinaires. Parfois, des personnes se réfèrent d’elles-mêmes comme étant « DevOps » lorsqu’elles sont en fait des évangélistes du DevOps ou des spécialistes techniques qui ont fait la transition loin des rôles d’exploitation traditionnels après la rupture des silos.
SRE, quant à lui, est un rôle concret clairement défini dans un cadre du même nom, que nous traiterons dans notre prochain article où nous parlerons des meilleures pratiques inventées par les équipes SRE les plus performantes.
N’hésitez pas à nous contacter pour en savoir plus sur la mise en pratique de DevOps et SRE. Rejoignez-nous dès aujourd’hui pour optimiser votre temps et votre production !
Par Gologic en collaboration avec Alexandre Couëdelo.
FAQ
Est-ce qu’un SRE fait de la programmation ?
Oui, le rôle de SRE (Site Reliability Engineer) comprend souvent de la programmation. Les SRE utilisent des compétences en programmation pour automatiser des tâches récurrentes, créer des outils et des scripts pour surveiller et gérer les systèmes, et résoudre les problèmes de fiabilité. La programmation est donc une compétence clé pour les SRE.
Quelles sont les meilleures pratiques pour intégrer les principes SRE dans un projet existant ?
Pour intégrer les principes SRE vs DevOps dans un projet existant, il est recommandé de procéder comme suit : évaluer l’infrastructure et les processus en place, favoriser la collaboration entre les équipes de développement et d’exploitation, et automatiser les tâches récurrentes. L’utilisation de l’infrastructure en tant que code (IaC), l’intégration continue (CI) et le déploiement continu (CD) sont également des pratiques essentielles pour améliorer l’efficacité et la fiabilité du projet.
Quels outils et technologies sont couramment utilisés par les équipes SRE et DevOps ?
Les équipes SRE et DevOps utilisent couramment des outils tels que Kubernetes, Docker, Ansible pour la gestion de l’infrastructure. Elles utilisent également des outils de surveillance comme Prometheus, ELK et Grafana, ainsi que des outils d’automatisation des pipelines CI/CD tels que Jenkins, GitLab CI/CD, ou Travis CI. Enfin, des outils de gestion de configuration comme Puppet, Chef ou Ansible sont également utilisés.
