"c'est dingue, la BdD MySQL ou PostgreSQL sur mon VPS pourtant surdimensionné rame !!" Effectivement, c'est un mauvais choix....Pourquoi ? Car la plupart des VPS (ex OVH, Scaleway et autres..) utilisent des disques durs réseaux de type Block Storage (ex AWS EBS) qui ont une latence (réseau) beaucoup plus grande que des disques SSD NVMe attachés localement. Et au final, les écarts de performance sont très importants : Burak Yücesoy a écrit un article très détaillé là-dessus (cf commentaire). Malgré les optimisations, il estime que le rapport de performance est d'environ x3 en faveur des disques locaux. "Oui, mais justement le block storage, c'est bien pratique : on peut l'attacher à un autre VPS, en faire des snapshots, changer sa taille à la volée.." Tout cela est vrai, mais au détriment de la performance. "Comment, dans le cas de disques physiques, assurer la haute disponibilité et reprise d'activité de la DB sans perte ?" Par la réplication synchrone et asynchrone au niveau de la BdD. C'est complexe à mettre en place et à maintenir, c'est pourquoi la plupart des opérateurs Cloud proposent des bases de données managées *avec des disques locaux* incluant la gestion de serveurs replica.

2025 et toujours ce "statefile" #Terraform fragile et monolithique.... Pas l'impression qu'#Opentofu avance véritablement sur ce sujet....

#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

Cette feature dans #K8s v1.33 va réduire drastiquement la latence réseau : le flux vers un service ClusterIP sera envoyé vers le Pod le plus proche : plus d'aller et retours entre les Worker Nodes. Inconvénient : cela va nuire à la réparation égale des flux entre les Pods d'un même service. Après tout, ce n'est pas plus mal : c'est la responsabilité de l'architecte ou de l'administrateur de savoir si cela sera bénéfique ou pas à son application.

#Bitnami : report de la date d'effacement de leurs images Docker au 29 sept ! https://lnkd.in/dXXF94MH