5 différences fondamentales entre DevOps et SRE que vous devez connaître
Publié: 2021-02-22Le monde des technologies de l'information et du développement de logiciels confond souvent DevOps et SRE pour signifier une seule et même chose. Cependant, il existe de grandes différences entre les deux. Alors que l'ingénierie de la fiabilité du site (SRE) a gagné du terrain ces dernières années, DevOps existe depuis bien plus longtemps (avant même que le terme DevOps n'existe).
Pour faire simple, DevOps et SRE sont deux pratiques mises en place pour livrer des logiciels plus rapidement. La seule différence entre les deux réside dans leurs approches ; DevOps se concentre sur la réduction du cycle de vie du développement logiciel, et SRE se concentre sur l'élimination des faiblesses du système pour atteindre le même objectif.
Dans cet article, nous examinerons les différences fondamentales entre DevOps et SRE. Avant de faire cela, commençons par comprendre ce que sont DevOps et SRE.
Table des matières
Qu'est-ce que DevOps ?
Selon les mots de Gene Kim, auteur de The DevOps Handbook et The Phoenix Project,
"DevOps est [l']ensemble de normes culturelles et de pratiques technologiques qui [permet] le flux rapide des travaux planifiés, entre autres du développement, des tests aux opérations tout en préservant une fiabilité, un fonctionnement et une sécurité de classe mondiale. DevOps ne concerne pas ce que vous faites, mais quels sont vos résultats. »
Ainsi, DevOps se concentre principalement sur la transformation des pratiques culturelles au sein d'une organisation pour accélérer le cycle de vie du développement logiciel (SDLC). Il ne cible pas une personne, un groupe ou un poste. DevOps vise à renforcer la collaboration entre les opérations des technologies de l'information et les équipes de développement de logiciels.
Ce qu'il fait et comment il le fait n'est pas important ; seul le résultat du processus est reconnu.
DevOps utilise un ensemble de principes pour intensifier l'exposition des équipes d'ingénierie logicielle aux systèmes de production et permet à l'équipe des opérations informatiques de faire remonter plus efficacement les divergences à l'équipe de développement. En fait, SRE joue un rôle crucial dans une organisation DevOps en facilitant les tests proactifs, la rapidité, l'observabilité et l'amélioration de la fiabilité des services. DevOps encourage chaque organisation centrée sur DevOps à fonctionner selon les principes culturels décrits dans son modèle CALMS.
Qu'est-ce que le SRE ?
SRE, abréviation de Site Reliability Engineering, est un terme inventé par le vice-président principal de Google, Ben Treynor, chargé de superviser les opérations techniques.
Drew Farnsworth (de Green Lane Design) explique : « J'aime généralement penser au SRE comme à un système dans lequel le développement contrôle les opérations. Il s'agit d'un système dans lequel l'environnement est décomposé en composants les plus élémentaires de la pile informatique et déployé avec les meilleures pratiques intégrées au matériel. »
Essentiellement, l'équipe SRE ayant une expertise en développement de logiciels est chargée de résoudre les problèmes de production du système tout en maintenant un équilibre entre la vitesse de livraison et la fiabilité du système. De cette manière, l'approche SRE rassemble le personnel de développement de logiciels sous des rôles d'exploitation pour appliquer des pratiques d'ingénierie structurées pour faire respecter les politiques d'une organisation.
Ils s'assurent que les systèmes sont disponibles et fonctionnent efficacement à tout moment pour que les équipes logicielles développent des services techniques pour augmenter la fiabilité du système. Il incombe au SRE d'identifier toute faiblesse potentielle avant qu'elle ne se transforme en problème majeur.
DevOps vs SRE : Principales différences entre DevOps et SRE
En pratique, DevOps et SRE doivent être considérés comme des disciplines complémentaires où les SRE, dans le cadre d'une structure centrée sur DevOps, se concentrent sur l'amélioration de la fiabilité de leurs services techniques. Donc, essentiellement, il n'y a pas de DevOps contre SRE.
Par conséquent, ce que nous faisons dans cette section consiste à évaluer les différences fondamentales entre DevOps et SRE.
Mise en œuvre du changement
Afin que les mises à jour soient fréquentes et que les utilisateurs aient accès à une technologie plus récente et plus pertinente, DevOps et SRE ont l'intention d'évoluer rapidement. Cependant, DevOps avance progressivement, avec prudence, tandis que SRE prend en compte le coût d'un échec pour aller plus vite.
Les deux mettent en œuvre l'automatisation et utilisent des outils pour atteindre cet objectif.
Considérer les échecs comme normaux
DevOps est énorme pour accepter les échecs et les considérer comme une oppression d'apprentissage. Pour cette raison, il encourage une culture irréprochable en acceptant que les échecs fassent partie du processus et ne se concentre pas sur la fabrication de systèmes 100 % tolérants aux pannes. Un exemple de ceci est Netflix avec son armée simienne.
SRE, d'autre part, soutient un post-mortem irréprochable. Le but derrière cela est d'identifier la cause de l'échec, d'attribuer des responsabilités et de travailler pour éviter des échecs similaires à l'avenir. Le nombre de pannes qu'un système peut subir est inclus dans le budget d'erreur. Les métriques SLI, SLO et SLA déterminent cela pour réduire le coût de production. Fondamentalement, SRE adopte des pratiques proactives de surveillance et d'alerte pour éviter une défaillance potentielle.
Apprenez des cours de développement de logiciels en ligne dans les meilleures universités du monde. Gagnez des programmes Executive PG, des programmes de certificat avancés ou des programmes de maîtrise pour accélérer votre carrière.
Automatisation vs innovation
DevOps accorde la plus haute importance à l'automatisation. Dans un environnement axé sur DevOps, cela se traduit par des systèmes automatisés autant que possible, ce qui entraîne des versions ennuyeuses. Une fois qu'un développeur a validé le code, la plupart des activités suivantes, sinon toutes, doivent être automatisées.
Par conséquent, la raison DevOps de poursuivre le CI/CD est de développer des systèmes de haute qualité à une vitesse plus élevée.
Les raisons de SRE de poursuivre CI/CD sont différentes, elles visent à réduire le coût de l'échec. Toutes les tâches courantes, génériques ou répétitives dans les opérations telles que le déploiement et les sauvegardes sont considérées comme moins dignes d'attention. Par conséquent, les SRE réservent un laps de temps spécifique pour éviter les difficultés opérationnelles. Ceci est fait afin qu'ils puissent poursuivre des tâches plus attrayantes telles que l'exécution ou l'innovation de nouvelles technologies ou des activités liées à l'architecture.
Checkout : Projets DevOps pour les débutants
Briser les silos organisationnels
Les développeurs et les opérateurs entrent en conflit lorsqu'il s'agit du processus de déploiement. Alors que les développeurs bénéficieraient du déploiement des fonctionnalités dès leur codage, les responsables des opérations se concentrent sur la mise à disposition des systèmes, ce qui entrave le processus de déploiement.
DevOps et SRE diffèrent dans la manière dont ils suppriment les silos dans une organisation.
DevOps, comme expliqué dans The DevOps Handbook, aborde ce problème en incluant des pratiques telles que le fonctionnement par lots plus petits et une meilleure gestion des configurations.
Les SRE ne visent pas seulement à optimiser les flux entre les équipes mais aussi à aider les systèmes en production. Ils le font en s'intégrant aux équipes en tant que consultants et en accompagnant les développeurs en partageant la responsabilité de l'exploitation des systèmes. C'est ainsi que les SRE décomposent les silos dans une organisation.
Mesurer une mise en œuvre réussie
Les métriques DevOps concernent la vitesse des opérations ; cela inclut la fréquence des déploiements, le temps nécessaire pour le faire et la fréquence à laquelle ils rencontrent des problèmes.
Selon le rapport 2017 de Puppet et DORA, la mesure d'une implémentation réussie dans DevOps dépend des éléments suivants :
- la fréquence à laquelle les déploiements se produisent
- la durée entre un commit de code et son déploiement
- la fréquence à laquelle les déploiements échouent
- le temps nécessaire pour se remettre d'un échec de déploiement
Ces boucles de rétroaction sont mises en place pour aider DevOps à améliorer la qualité du système tout en facilitant un changement lors de l'expérimentation.
SRE, quant à lui, travaille à l'amélioration des systèmes tout en gardant à l'esprit leur fiabilité. Il prend en compte les mesures clés suivantes pour déterminer une mise en œuvre réussie :
- objectif de niveau de service (SLO)
- indicateur de niveau de service (SLI)
- accord de niveau de service (SLA)
Les métriques mentionnées ci-dessus sont des indicateurs de la fiabilité d'un système. Ces métriques déterminent à l'avance si une release for change atteindra ou non la production.
Dans SRE, ces mesures de vitesse et de qualité sont utiles pour établir un budget d'erreur et améliorer la fiabilité des systèmes plutôt que de travailler sur de nouvelles fonctionnalités.
Lire : Salaire d'un ingénieur DevOps en Inde
Conclusion
Google avait publié un livre électronique sur la façon dont ils implémentent l'ingénierie de la fiabilité du site dans leurs systèmes de production dans lequel Treynor a expliqué que SRE était,
"SRE est ce qui se passe lorsque vous demandez à un ingénieur logiciel de concevoir une équipe d'exploitation."
En ce qui concerne les différences entre DevOps et SRE, tout ce que vous devez retenir est que SRE est piloté par des développeurs plutôt que par une équipe d'exploitation. La maintenance et la surveillance sont principalement sous le contrôle des développeurs. C'est d'abord ce qui différencie les deux disciplines.
Si vous souhaitez en savoir plus sur les grands DevOps, le développement de la pile complète, consultez le programme exécutif PG de upGrad & IIIT-B en développement de logiciels - Spécialisation en développement de la pile complète qui est conçu pour les professionnels et offre plus de 500 heures de formation rigoureuse, Plus de 9 projets et affectations, statut d'ancien de l'IIIT-B, projets de synthèse pratiques et aide à l'emploi avec les meilleures entreprises.
