SRE ou FinOps en 2024 où faut-il mettre l'effort et les ressources ?

Le SRE d'abord sans aucune hésitation. Si ton service est en panne H24 ou que tu as des incidents majeurs toutes les semaines l'optimisation des coûts c'est de l'argent jeté par les fenêtres. Tu perds des clients tu perds du business.

Sans fiabilité tu n'as pas de base pour quoi que ce soit d'autre. L'uptime et la stabilité sont la priorité absolue.

Argument fallacieux. Si ton business est en faillite à cause des coûts tu n'as plus de business non plus. On peut être fiable mais ruineux.

L'optimisation des coûts c'est pas juste réduire. C'est maximiser la valeur pour chaque euro dépensé. Un service ultra stable qui coûte 10x son revenu c'est une hérésie économique.

C'est un faux dilemme ça. Un bon SRE fait aussi du FinOps. Le SRE gère la capacité le provisioning l'élasticité. La capacité c'est des coûts. Tu dimensionnes correctement tu utilises des instances spot tu automatises les shutdowns pour les environnements de dev.

C'est juste une partie du job SRE bien fait. Le SRE c'est pas juste over-provisionner.

C'est pas la même mentalité. Le SRE c'est comment éviter la panne comment gérer le risque. Le FinOps c'est comment réduire la facture comment gérer le budget.

Parfois pour éviter une panne tu over-provisionnes un peu. Le FinOps va te dire de réduire coûte que coûte. C'est une tension structurelle entre les objectifs.

L'over-provisionnement c'est de la paresse ou un manque de connaissance de la charge. C'est pas du SRE intelligent. Le SRE doit définir des SLO précis et s'efforcer d'atteindre ces SLO au coût minimum.

C'est la base du FinOps être efficient avec les ressources.

Et l'observabilité est absolument clé pour les deux. Tu ne peux pas optimiser tes coûts si tu ne sais pas ce qui consomme réellement. Tu ne peux pas débugger si tu ne vois rien.

Prometheus Thanos tracing distribué logs centralisés tout ça nourrit à la fois le SRE et le FinOps. C'est le socle commun.

On parle de priorisation. On peut pas tout faire à 100% en même temps. Si tu passes 6 mois à réduire ta facture de 10% mais que tu as une panne majeure qui te coûte 20% de tes clients ton ROI est clairement négatif.

La perte de confiance des utilisateurs c'est inestimable.

Et si tu dépenses 2x ce que tu devrais pour garantir un uptime 99.999% pour un service dont le SLO peut être 99% c'est de l'argent jeté par les fenêtres. Ce coût aurait pu financer une nouvelle fonctionnalité ou de la R&D cruciale.

Faut contextualiser le SLO et le coût associé.

L'erreur c'est de voir ça comme des silos. Les équipes doivent avoir des objectifs partagés. Quand une équipe SRE est responsable à la fois de ses SLO et de son budget elle intègre naturellement le FinOps.

C'est une culture pas juste un rôle.

Dans la réalité c'est rarement ça. Le SRE va toujours privilégier la résilience la sécurité. Le FinOps va toujours privilégier le right-sizing la réduction des coûts. On l'a vu sur les clusters Kubernetes.

L'autoscaler horizontal HPA et vertical VPA sont là. Mais personne ne les optimise vraiment si le SRE n'est pas poussé sur le coût. On met des limites trop hautes par confort.

Kubernetes internals c'est un bon exemple. Combien de CPU et de RAM on alloue par pod ce n'est pas juste du SRE c'est aussi du coût pur. Un pod qui request 2 CPU mais n'en utilise que 0.2 c'est du gâchis.

Le FinOps va traquer ça remonter l'information et pousser pour l'optimisation. Le SRE va s'assurer que ça tourne.

Et le storage CSI. Quelle classe de storage quelle taille IOPS provisionnés. Si tu prends du gp3 avec 3000 IOPS pour un truc qui fait 50 IOPS c'est du FinOps mal géré.

Le SRE s'assure que le disque tient la charge. Le FinOps s'assure que ça coûte pas un bras pour rien.

Mais la base c'est la stabilité. On commence par là. Tu stables l'infra tu gères tes incidents et ensuite tu optimises. Tu peux pas optimiser un truc qui pète tout le temps. C'est improductif.

Non tu stables *et* tu optimises. C'est un cycle continu. Si tu attends la stabilité parfaite tu ne feras jamais d'optimisation. C'est comme le refactoring code. Tu le fais tout le temps pas juste une fois par an.

Le FinOps doit être présent dès le début du cycle de vie du produit.

IaC avec Terraform Ansible c'est aussi un moyen d'optimiser. Des templates standardisés moins d'erreurs moins de sur-provisionnement manuel. La gestion de l'identité mTLS c'est de la sécu qui a aussi un coût si mal implémenté.

Le tout est lié.

Le FinOps c'est un mindset c'est une culture. Le SRE c'est un rôle et un ensemble de pratiques bien définies. Ce n'est pas comparable directement.

On a besoin d'équipes SRE fortes pour être stable. Après le FinOps peut venir optimiser ce qui est déjà stable.

Non. Le FinOps doit être intégré dès le design et l'architecture du service. Pas en post-mortem ou une fois que tout est en prod.

Sinon tu as des architectures intrinsèquement coûteuses que personne n'ose toucher après coup et qui te bouffent tes marges.

Ok c'est une distinction claire et un aperçu intéressant de leur interdépendance. Il semble que les deux sont absolument critiques.

Le consensus penche vers la nécessité des pratiques SRE pour la stabilité et ensuite des principes FinOps pour garantir la rentabilité dans ces objectifs de stabilité.

Intégrer le FinOps dès la conception plutôt qu'en afterthought me semble être la bonne approche. On va commencer par solidifier nos SLO et l'observabilité puis intégrer les métriques de coût dans les responsabilités des équipes SRE. Merci pour le débat musclé.