Je ne vais pas m’attarder sur cette partie, on connait la chanson. On fait du DevOps pour casser les silos car "les ops veulent de la stabilité alors que les dev eux veulent développer et innover le plus rapidement possible."
Cette définition est assez incomplète selon moi et laisse entendre que les ops ne savent pas innover ou que les dev ne sont que bon à pisser du code sans soucis de qualité, et à force de la répéter les gens peuvent intégrer ces définitions.

Bref, on casse les silos en créant des OKR communs, en facilitant la communication et en faisant intervenir l’ensemble des équipes lors de la conception d’un nouveau projet.

Si vous me suivez depuis un moment vous connaissez probablement ma position sur tout ça. Je milite depuis longtemps pour rapprocher les dev et les ops, sur le travail en commun mais aussi sur les pratiques et connaissances techniques: des dev qui gèrent de A à Z leurs services (déploiements en production et astreintes inclus) et ont des connaissances qui ne s’arrêtent pas au code, et des ops qui incluent l’ingénierie logicielle dans leur quotidien en ayant une vraie approche produit pour l’infrastructure (voir un de mes talks sur le sujet, et sans scripts shell svp).

Mais donc, pourquoi recréer les silos ?

Une notion revient souvent quand on parle de SRE: le fait de pouvoir scale fortement des équipes de développement sans avoir à recruter à la même vitesse des gens côté infrastructure.
Le monde de l’infrastructure a énormément évolué ces dernières années (produits de plus en plus performants, automatisation, cloud…​) et il est tout à fait possible de gérer des productions assez conséquentes (j’inclus dans "production" la gestion de l’infrastructure et de l’abstraction qu’on construit pour le reste de la tech) avec des équipes réduites. Il est donc très commun d’avoir un ratio par exemple de 1/15, 1/20 ou plus encore entre SRE et le reste du département tech, alors que le scope porté par les SRE peut être extrêmement vaste.

Comme dit précédemment ce déséquilibre est bon signe: ça veut dire que l’infra tourne bien et est assez efficace pour que la tech "scale" sans l’impacter.

Mais cela peut aussi vite créer un déséquilibre: quand la petite équipe essaye d’influencer d’une manière ou d’une autre la plus grosse, c’est David contre Goliath. A l’inverse, une mauvaise pratique semblant peu dérangeante pour la grosse équipe au niveau local peut fortement impacter la petite qui elle se retrouve en bout de chaîne.

Vous allez me dire que dans ce cas on manque d’alignement et on ne travaille pas aux mêmes objectifs, et c’est vrai. Mais c’est là où la réalité rattrape la théorie. Il arrive en effet que cette différence d’objectif soit assumée, et forcer les gens à travailler ensemble dans ce contexte ne peut conduire qu’à de la frustration.

Imaginons que votre infrastructure soit hébergée dans le cloud, chez Amazon Web Service (AWS) par exemple.

AWS vous fournit des produits que vous pouvez ensuite consommer, via du tooling ou une interface web. C’est à vous de définir comment vous allez l’utiliser. Vous pouvez très bien ignorer l’ensemble des bonnes pratiques du cloud ou fournies par AWS (dans sa documentation par exemple), démarrer n’importe quoi, saturer des services…​ AWS s’en fiche complètement ! Eux se contentent de fournir le produit, le tooling, et un cadre:

Ensuite, vous êtes libre. Vous assumez les conséquences de vos choix, qu’ils soient bons ou mauvais (incidents, facture lourde…​).

Est ce que ce ne serait pas le bon modèle en interne à appliquer dans certains cas ? Est ce que votre équipe infrastructure ne devrait pas être considérée comme une autre entreprise, complètement décorrélée du reste, et fournissant un produit mais très spécifique (avec ce que cela implique en terme de conception produit et discussion avec les "clients finaux") ? Est ce qu’un découplage total dev et ops n’est pas en fait la solution aux problèmes d’alignement et d’objectifs contraires ? Est ce que ce modèle peut vraiment marcher sur le long terme ?

Est ce que peut être ce n’est pas ça le vrai platform engineering ?

Je ne répondrai pas à ces questions, à vous de me dire ;)