Profile picture of Steve Fermat
Steve Fermat
Spécialiste Performance Web, Expert Cloudflare | AWS | Cloud | Observabilité
Follow me
Generated by linktime
August 26, 2025
2025 et toujours ce "statefile" #Terraform fragile et monolithique.... Pas l'impression qu'#Opentofu avance véritablement sur ce sujet....
Stay updated
Subscribe to receive my future LinkedIn posts in your mailbox.

By clicking "Subscribe", you agree to receive emails from linktime.co.
You can unsubscribe at any time.

7 Likes
August 26, 2025
Discussion about this post
Profile picture of Maxime V.
Maxime V.
Staff Cloud Operations Engineer
3 days ago
Ça fait partie des problème qu'essaie de résoudre Terramate. Mais fondamentalement, comme beaucoup de produits open source backés par une unique entreprise, il garde des défauts que la version "entreprise" résout...
Profile picture of Guillaume Tristani
Guillaume Tristani
Chief Technology Officer chez OpsVox
3 days ago
This state is stored by default in a local file named "terraform.tfstate", but we recommend storing it in HCP Terraform to version, encrypt, and securely share it with your team. Ce qui en soit est légit pour les amateurs de OSS == Free money. Ceci dit en se bougeant un peu il y a pas mal de backends ou mieux, d'architectures envisageables pour être safe et rester hors version d'entreprise. Après TF si on sors du scope du state, il dépend en grande partie de ses providers qui eux même dépendent des évolutions des API, donc bon courage. L'outil parfait n'existera jamais. Enfin peut être que si avec l'IA :-/
Profile picture of Thomas Trividic
Thomas Trividic
Lead data engineer GCP - Freelance
3 days ago
oui c’est abusé que sur ce sujet on soit toujours au même point depuis des années. SQLMesh qui s’inspire fortement de terraform ( pour les data pipeline) au moins stocke son state sur une database….
#OpenTelemetry Collector : l'ombre d'un doute.. OpenTelemetry (Otel) est un ensemble open source de standards, bibliothèques et outils permettant de collecter, corréler et exporter des données de télémétrie (traces, métriques, logs, profiles) afin de faciliter l’observabilité des applications et systèmes. Dans une chaîne d’observabilité, l’OpenTelemetry Collector reçoit, transforme et exporte les données de télémétrie depuis les applications avec un protocole standardisé (OTLP), tandis que le backend (ex. stack Grafana LGTM, Datadog, Dynatrace, New Relic, Splunk, Elastic , Honeycomb ... ) les stocke, analyse et visualise pour l’observation et le diagnostic. La promesse pour les utilisateurs est d'utiliser un Collector neutre et standardisé et de le conserver même en cas de changement de backend, et ainsi éviter des opérations lourdes de décomissionnement, déploiement, etc.. Or je viens de voir 2 contenus (sources plus bas): - Datadog explique que le composant logiciel OpenTelemetry-Collector-contrib n'est pas destiné à être utilisé tel quel en production, et doit être repackagé (de façon assez complexe) - Grafana Labs recommande clairement d'utiliser son agent Alloy pour faire office de collecteur opentelemetry Mais donc... cela veut dire qu'il faudrait utiliser le collecteur de l'éditeur de votre backend or c'est exactement ce que OTel était censé éviter !! J'y vois un glissement de narratif et une prise en main d'Otel par les éditeurs... Est-ce du FUD ? Oui bien est-ce que le opentelemetry-collector-contrib n'a pas le même niveau de qualité que celui des éditeurs ? Qu'en pensez-vous ? Avez-vous le même sentiment ? PS : Ce post traite bien uniquement du composant Opentelemetry Collector et pas des SDK OpenTelemetry d'instrumentation des langages (Java, .Net, C++, Python, Golang, PHP..) -- Sources Datadog : https://lnkd.in/eYztZjgi Grafana Labs: https://lnkd.in/e8CYSAyc Recommandation Otel-collector-contrib : https://lnkd.in/exUsTacf Schema Otel : https://lnkd.in/eA4nPknH
10 comments
August 14, 2025