Konubinix' opinionated web of thoughts

Devops

Fleeting

Mode de pensée le développement avec le déploiement en tête et de penser les outils de déploiement avec le développement en tête.

Penser devops permettrait d’éviter des conflits entre l’équipe dev qui construit le code et l’équipe ops qui amène ce code en production.

Ce mode de pensé est rendu possible grâce au paradigme “conteneur” permettant à l’équipe dev d’échanger un programme ET son contexte d’exécution. Ainsi, l’équipe ops peut se concentrer sur l’infrastructure à mettre en place. Ce changement de paradigme est étendu par l’usage d’outils de clustering, comme nomad ou k8s, pour ne plus penser un programme dans son contexte d’exécution, mais toute l’application, composée de plusieurs conteneurs en interaction, de règles d’ingress, de contraintes réseau etc.

Le mode de pensée devops implique que les dev et les ops partagent un vocabulaire et des objectifs communs, comme l’intérêt pour des petites images limitant la surface d’attaque, les pratiques zero trust et l’analyse de sécurité des images.

Avec les mises en place de cluster k8s locaux, comme k3d et les outils d’aide au développement, comme tilt et earthly, le développeur peut reproduire un modèle de l’environnement de production, permettant de réduire encore la frontière avec l’équipe ops et faciliter les échanges.

i suppose what lots of people heard when people started talking about devops was we need a devops team so instead of two silos dev and ops we now have three dev ops and devops this became quite a big thing and people with devops skills became a hot commodity in the job market they probably still are a bit this is a problem because the whole point is to remove friction to smooth the path for changes

—

surprisingly often what they take it to mean is ops is now called devops so the ops team gets renamed but carries on working in the same old way did you raise a ticket for that

—

our aim is to create great work but to do it quickly and efficiently the state of devops reports lists some of the technical practices that allow us to measurably achieve that aim loosely coupled architecture trunk based development continuous testing continuous integration use of open source technologies monitoring and observability practices management of database changes deployment automation

—

prefer my continuous delivery terminology rather than that of devops sure the devops folk worry about all of this stuff too but the focus on only dev and ops doesn’t say so so my final devops bad is a somewhat personal one i really do dislike the term as i said earlier but it has become common currency

—

usage ordinaire du mot devops

Les développeurs que je côtoient semblent penser qu’il n’est pas possible de se concentrer sur son développement tout en ayant en tête les considérations de son contexte d’exécution.

En effet, k8s étant très jeune et très populaire, on voit une explosion d’outils permettant d’exploiter un cluster. La jeunesse de ces outils fait qu’on voit encore beaucoup de concepts internes à k8s.

De plus, comme tout changement de paradigme, des résistances apparaissent et les gens qui ont « signé » pour faire du code ne veulent pas entendre parler de cluster.

On voit donc apparaître une nouvelle classe, les ingénieurs devops. Il s’agit en général d’ops renommés.

En conclusion, le mouvement devops cherchait à amoindrir la barrière entre les dev et les ops. Le résultat et qu’on a renommé la barrière devops.

Notes pointant ici