Avec une expérience pratique dans AWS DevOps et Google SRE, j’aimerais offrir mes idées sur la comparaison de ces deux systèmes. Les deux se sont avérés efficaces pour fournir des services évolutifs et fiables aux fournisseurs de cloud. Cependant, une mauvaise gestion peut entraîner des équipes et des organisations non fonctionnelles. Dans cet article, je vais donner un bref aperçu d’AWS DevOps et de Google SRE, examiner quand ils fonctionnent le mieux, approfondir les pièges potentiels à éviter et fournir des conseils pour maximiser les avantages de chacun.
DevOps
DevOps est un terme largement utilisé avec de multiples interprétations. Dans cet article, je vais me concentrer sur AWS DevOps, qui, selon le blog AWS, fusionne les équipes de développement et d’exploitation en une seule unité. Dans ce modèle, les ingénieurs travaillent sur l’ensemble du cycle de vie de l’application, du développement au déploiement en passant par les opérations. Ils possèdent un large éventail de compétences plutôt que d’être limités à une fonction spécifique.
Par conséquent, les mêmes ingénieurs qui écrivent le code sont responsables de l’exécution du service, de sa surveillance et de la réponse aux incidents. En pratique, chaque équipe peut avoir sa propre approche, mais il existe un certain degré d’unification des pratiques, comme avec le CI/CD, la prévention des incidents et les autopsies irréprochables. Personnellement, je considère AWS comme ayant la culture opérationnelle la plus efficace parmi toutes les organisations avec lesquelles j’ai travaillé.
Avantages de l’approche DevOps
Lorsque DevOps est mis en œuvre efficacement, il peut offrir plusieurs avantages, en particulier dans les premiers stades de développement. Pour les start-up qui cherchent à commercialiser rapidement un nouveau produit, DevOps peut offrir rapidité et agilité. De même, les entreprises établies qui lancent un nouveau service ou produit peuvent également bénéficier du modèle DevOps.
Bien que la même équipe exploite le système, il peut y avoir une certaine spécialisation, certains membres de l’équipe se concentrant davantage sur les opérations et d’autres sur le développement. Au fil du temps, à mesure que le produit mûrit, les équipes peuvent se diviser, une équipe de plate-forme (semblable à SRE) travaillant aux côtés d’une équipe de développement (semblable à SWE).
Cependant, l’intégration et le chevauchement des activités opérationnelles par les ingénieurs de développement et la compréhension approfondie du système par les ingénieurs opérationnels restent étroits. Cette boucle de rétroaction étroite conduit à une meilleure compréhension du fonctionnement du système, de ses limites et de l’expérience client par tous les membres de l’équipe.
Ceci, à son tour, accélère la prise de décision et les cycles d’itération. C’est probablement un facteur qui contribue à la domination d’AWS sur le marché et au grand nombre d’offres qu’il propose.
Quand DevOps tourne mal
Généralement, les opérations peuvent être divisées en trois catégories principales :
- Opérations de service
- Prévention des incidents
- Réponse aux incidents
Alors que les opérations de service sont souvent considérées comme agréables par les ingénieurs logiciels, la prévention des incidents peut ne pas être aussi engageante et la réponse aux incidents peut devenir écrasante, en particulier lorsque les ingénieurs sont responsables du développement et des opérations. Plus ils passent de temps sur des tâches opérationnelles, moins ils ont de temps pour le développement et plus ils deviennent insatisfaits de leur travail.
Cela peut entraîner un cercle vicieux d’ingénieurs surmenés, un roulement élevé, une qualité de travail réduite et une charge de travail croissante pour les opérations.
Ingénierie de la fiabilité du site (SRE)
L’ingénierie de la fiabilité du site (SRE) est une discipline développée par Google pour améliorer la fiabilité et la disponibilité des systèmes logiciels. Cela implique une équipe dédiée de SRE qui se concentre uniquement sur ces objectifs, tandis que les ingénieurs logiciels (SWE) s’occupent de l’écriture du code. SRE apporte un ensemble formalisé de principes et de terminologie, tels que les indicateurs de niveau de service (SLI), les objectifs de niveau de service (SLO), les budgets d’erreur, le labeur et autres, pour garantir que le logiciel est évolutif et répond aux normes de performance.
Avantages de l’ingénierie de la fiabilité du site
Lorsque SRE est mis en œuvre efficacement, il offre un haut niveau de normalisation et de cohérence dans la mesure de l’expérience client. Cette approche ne se traduit pas nécessairement par des services plus fiables ou plus performants, mais elle garantit que les meilleures pratiques sont suivies sur plusieurs produits. En disposant d’équipes SRE dédiées, cela réduit la charge des opérations pour les ingénieurs logiciels, qui n’ont plus besoin de gérer les problèmes opérationnels à toute heure du jour et de la nuit. En conséquence, les ingénieurs logiciels peuvent avoir un meilleur équilibre travail-vie personnelle, tandis que l’équipe SRE s’assure que les besoins opérationnels sont satisfaits de manière cohérente et efficace.
Quand le SRE tourne mal
Dans le modèle SRE, les ingénieurs logiciels (SWE) sont libérés de la charge opérationnelle ; cependant, cela peut entraîner un manque d’exposition au fonctionnement du système, conduisant à de vagues évaluations des risques et à une compréhension limitée de la façon dont leur code se comporte dans différentes conditions. D’un autre côté, les SRE peuvent être surchargés par un nombre excessif de pages, ce qui peut ralentir le développement en devenant trop frileux. Ceci, à son tour, affecte les SWE qui deviennent alors averses au risque et ont du mal à obtenir les approbations des SRE.
Cette déconnexion entre les deux équipes, les SWE percevant le service comme une boîte noire et les SRE ne comprenant pas le code et l’intention, peut conduire à une organisation semi-fonctionnelle où le déploiement du code en production peut prendre des mois et la majorité des initiatives ne voient jamais la lumière du jour.
Quel est le meilleur?
La réponse n’est pas si simple. Ni DevOps ni SRE ne sont intrinsèquement meilleurs ou pires, ils ont tous deux leurs propres forces et faiblesses.
En ce qui concerne DevOps, il est crucial de s’assurer que les ingénieurs ne sont pas surchargés de tâches opérationnelles et qu’ils ont un bon équilibre entre vie professionnelle et vie privée. Ceci peut être réalisé en investissant correctement dans l’outillage et en mettant l’accent sur la qualité de la production. De plus, il est important de trouver un équilibre entre le développement et les opérations pour éviter une situation où l’un des deux devient plus dominant et entrave la progression de l’autre.
D’autre part, SRE est conçu pour alléger la charge opérationnelle des ingénieurs logiciels et les protéger des distractions liées à la gestion des incidents et à d’autres tâches opérationnelles. Cependant, il est important d’éviter une déconnexion entre les SWE et les SRE et de s’assurer que chaque équipe a une compréhension complète du système. De plus, les SRE ne doivent pas seulement se concentrer sur les mesures opérationnelles, mais également s’intéresser à la livraison et doivent avoir la peau dans le jeu.
En d’autres termes, DevOps et SRE ont leurs propres avantages et inconvénients, et la meilleure approche dépendra des besoins et de la culture de votre organisation. La clé est d’éviter les pièges de chaque système et de s’efforcer d’adopter une approche équilibrée et efficace de la livraison de logiciels.
Équilibrer vitesse et stabilité
Équilibrer vitesse et stabilité est un aspect critique dans le débat DevOps vs SRE. L’approche adoptée par une entreprise dépendra de son stade et de ses objectifs. Les start-up privilégient souvent la vitesse et l’agilité pour commercialiser rapidement leur produit, ce qui fait de DevOps le choix idéal. Au fur et à mesure que l’entreprise se développe, la stabilité et la fiabilité deviennent plus importantes pour maintenir la confiance des clients, ce qui fait de SRE une meilleure solution.
Cependant, la transition de DevOps vers SRE ne signifie pas renoncer aux principes de rapidité et d’agilité. Un modèle SRE efficace peut toujours trouver un équilibre entre fiabilité et rapidité en assurant une collaboration étroite entre les SWE et les SRE. Les SWE dirigent le processus de développement, tandis que les SRE s’assurent que le système est fiable et évolutif. Des rotations régulières d’échange de chapeaux et des réunions opérationnelles conjointes peuvent maintenir les deux équipes soudées et alignées sur les objectifs de livraison et de stabilité. Cette approche offre le meilleur des solutions des deux mondes.
Réflexions finales
Le choix entre DevOps et SRE n’est pas simple. La meilleure approche dépend de la situation de votre entreprise et de ses besoins. En combinant les avantages des deux, vous pouvez trouver le juste milieu entre vitesse et stabilité, vous assurant ainsi de continuer à fournir d’excellents logiciels. Pour rendre cela possible, il est essentiel que les ingénieurs de la technologie et des opérations collaborent étroitement. Le partage des responsabilités et des réunions régulières peuvent aider à garder tout le monde sur la même longueur d’onde, en mettant l’accent sur la livraison et le maintien du bon fonctionnement. Cela peut permettre à DevOps et à SRE de fonctionner efficacement.