SRE vs DevOps – concurrents ou amis
DevOps
- Le mouvement DevOps est né de développeurs qui se sont mis à écrire du code sans trop savoir comment il fonctionnerait en production. Ils balançaient ce code à l’équipe d’exploitation, qui était ensuite chargée d’assurer le bon fonctionnement des applications.
- DevOps est apparu comme une culture et un ensemble de pratiques visant à réduire le fossé entre le développement de logiciels et leur exploitation.
- Cependant, le mouvement DevOps ne définit pas explicitement comment y parvenir.
- En ce sens, DevOps fait figure de classe ou d’interface abstraite dans la programmation. Il définit le comportement général du système, mais les détails d’implémentation sont laissés à l’appréciation de l’auteur.
Site Reliability Engineering (SRE)
Site Reliability Engineering (SRE) est un terme (avec la fonction ou le Job Role associé) inventé par Ben Treynor Sloss, vice-président de l’ingénierie chez Google.
SRE est une fonction, un ensemble de pratiques considérées comme efficaces par Google, et des convictions qui animent ces pratiques. Si l’on considère DevOps comme une philosophie et une approche du travail, SRE a alors pour mission d’en mettre en œuvre une partie.
«SRE est ce que vous obtenez lorsque vous demandez à un ingénieur logiciel de concevoir des fonctionnalités opérationnelles.»
Ben Treynor, vice-président de l’ingénierie chez Google
Comment SRE aborde concrètement DevOps
SRE incarne la philosophie de DevOps, mais est beaucoup plus normatif dans la façon de mesurer et d’atteindre la fiabilité à travers le travail d’ingénierie et d’exploitation. En d’autres termes, SRE prescrit la manière de réussir dans les différents domaines DevOps. Le tableau ci-dessous illustre par exemple les cinq piliers DevOps et les pratiques SRE correspondantes:
Ainsi, d’une certaine manière, la classe SRE implémente l’interface DevOps.
Différences DevOps <-> SRE
Il existe toutefois des différences significatives. DevOps est en quelque sorte une philosophie et une culture au sens large.
Cette approche ne précise pas la façon d’exécuter les fonctions opérationnelles à un niveau détaillé. Par exemple, elle n’établit pas de règles normatives quant à la gestion des services. Elle s’attache plutôt à éliminer les barrières dans l’organisation, ce qui est également très utile.
SRE, de son côté, a des responsabilités relativement bien définies et sa mission est en général orientée sur les services (et l’utilisateur final) plutôt que sur l’entreprise dans son ensemble. Il apporte donc un cadre intellectuel subjectif (y compris des concepts comme les error budgets au problème de l’exploitation efficace des systèmes. Bien que SRE soit, en tant que profession, très conscient des incitations et de leurs effets, il est en revanche peu précis sur des sujets comme la siloïsation et les barrières d’information. Il vient soutenir le CI (Continuous Integration) et le CD (Continuous Delivery) pas nécessairement à cause du Business Case, mais en raison de l’amélioration des pratiques opérationnelles que cela implique.
En d’autres termes, SRE croit aux mêmes choses que DevOps, mais pour des raisons un peu différentes.
Ressources
Cet article de blog est en grande partie basé sur SRE vs. DevOps: competing standards or close friends?
Un article de:
Michael Ludwig
Tribe Chief
Plus d’articles getIT
Prêts pour Swisscom
Trouve le Job ou l’univers professionnel qui te convient. Où tu veux co-créer et évoluer.
Ce qui nous définit, c’est toi.
