Ce billet explique la différence fondamentale entre les Message Queues (files d'attente de messages) et les systèmes Pub/Sub (publication/abonnement), souvent confondus. Les Message Queues, comme RabbitMQ ou SQS, utilisent une structure FIFO où les messages sont traités une fois et supprimés, idéales pour des tâches uniques comme l'envoi d'emails ou des jobs CI/CD. Les systèmes Pub/Sub, comme Kafka, utilisent un log append-only où les messages restent disponibles pour être relus, parfaits pour l'analytics en temps réel ou le traitement d'événements. Choisir le mauvais outil peut entraîner des problèmes techniques majeurs. L'auteur détaille les cas d'usage et les avantages de chaque système.
Aukfood présente une analyse comparative de quatre solutions open source de bastions SSH (Teleport, The Bastion d’OVH, Warpgate, JumpServer) dans le cadre d’un projet R&D visant à sécuriser les accès administratifs exposés sur Internet. L’étude évalue les critères clés : traçabilité des accès, gestion centralisée des utilisateurs, intégration LDAP/SSO/MFA, audit, haute disponibilité, et maintenabilité. Teleport se distingue par sa polyvalence et son adoption par des grands comptes, The Bastion (OVH) par sa conformité ANSSI et sa robustesse SSH pure, Warpgate par sa modernité (Rust) et sa légèreté, et JumpServer par son approche PAM complète et multi-protocole. Une matrice détaillée compare leurs forces (audit, RBAC, durcissement) et limites (complexité, documentation, scalabilité). L’article souligne l’importance d’une approche Zero Trust, du durcissement des infrastructures et de la centralisation des logs pour garantir la sécurité, tout en insistant sur l’adéquation du choix final aux besoins spécifiques (Cloud, souveraineté, mobilité). Une phase de tests virtualisés est prévue avant déploiement.
L’article passe en revue les principaux formats audio (sans compression comme WAV/AIFF, sans perte comme FLAC/ALAC, et avec perte comme MP3, Vorbis, Opus, AAC) et leurs usages : archivage, stockage quotidien ou streaming. Il explique l’importance du débit binaire (CBR/VBR) et de la compatibilité des formats avec les appareils. Pour l’archivage, le FLAC est recommandé pour sa qualité et son ouverture, tandis que pour un cloud musical, l’Opus (128 kbps VBR) est privilégié pour son équilibre qualité/taille et sa rapidité d’encodage. Un benchmark illustre les différences de taille entre formats, et un glossaire clarifie les termes techniques. L’auteur partage son choix : FLAC pour l’archivage, Opus pour le cloud.
Diomidis Spinellis explique pourquoi il privilégie l’email aux messageries instantanées : une boîte unifiée (plus besoin de jongler entre Teams, WhatsApp, Slack, etc.), un archivage pérenne (ses emails remontent à 1986 !), des fonctionnalités avancées (filtrage, étiquetage, recherche), une communication asynchrone préservant la concentration, et une maîtrise totale de ses données (protocoles ouverts, stockage local, confidentialité). Contrairement aux plateformes propriétaires, l’email offre liberté, interopérabilité et protection contre la publicité ou l’obsolescence. Un plaidoyer pour un outil intemporel, productif et respectueux de la vie privée.
Thibault Buze explique dans ce troisième volet de Sous le capot du cloud le choix de Proxmox VE comme hyperviseur pour leur cloud interne, après une analyse des besoins clés : haute disponibilité (HA), automatisation, interopérabilité et simplicité d’opération. Parmi les alternatives (vSphere, Hyper-V, OpenStack), Proxmox s’impose pour son approche ouverte (KVM/QEMU, LXC), native HA (migration à chaud, bascule automatique), flexible (stockage iSCSI/NFS/ZFS, intégration TrueNAS) et automatisable (API, Terraform, cloud-init). L’architecture repose sur 3 hôtes minimum, des réseaux dédiés (management, stockage, données) et une intégration fluide avec Kubernetes (via Longhorn). Le tout est industrialisé en Infrastructure as Code (Terraform), garantissant reproductibilité et traçabilité. Points clés : séparation des plans de trafic, sauvegardes testées (Proxmox Backup Server), et monitoring rigoureux. Une solution souveraine, économique et scalable, idéale pour des clusters hébergeant 500 à 2000 pods.
La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
L’article explique pourquoi l’auteur a abandonné Docker pour Podman, mettant en avant plusieurs avantages clés : Podman est sans démon, ce qui améliore la sécurité (moins de vulnérabilités liées à un processus root permanent) et réduit la consommation de ressources. Il s’intègre nativement avec systemd et Kubernetes, facilitant la gestion des conteneurs comme des services système et permettant une transition fluide vers des environnements de production. La migration est simple, car Podman utilise les mêmes commandes et fichiers Dockerfile que Docker, tout en offrant une approche plus sécurisée (mode rootless par défaut) et une meilleure alignement avec les pratiques Linux modernes. L’auteur souligne aussi que Podman encourage une architecture plus propre, comme l’utilisation d’un reverse proxy plutôt que l’exposition directe de ports privilégiés. En résumé, Podman se présente comme une évolution naturelle pour les développeurs cherchant plus de sécurité, de légèreté et de cohérence entre le développement et la production.
Un comparateur de distributions basées sur Android
L'article compare 2 manières de sérialiser des données : JSON et Proto (Protocol Buffer). Il conclue en donnant une règle : si des humains vont devoir lire les données échangées, préférer le JSON. Si ce sont des machins, préférer Proto.
L'article compare trois outils HTTP : Fetch API, Axios et Alova. Fetch API, intégré nativement dans JavaScript, est léger et idéal pour des requêtes simples mais nécessite une gestion manuelle pour des fonctionnalités avancées. Axios, bien que plus lourd, offre des fonctionnalités automatisées comme la gestion du JSON et des intercepteurs, le rendant adapté pour des applications complexes. Alova, quant à lui, combine la simplicité des requêtes avec des fonctionnalités avancées telles que la gestion de l'état et la mise en cache, ce qui en fait un choix optimal pour des applications front-end lourdes nécessitant une optimisation des performances.
Un comparatif des navigateurs (desktop, mobile) sur le respect de la vie privée
L'article explique ce qu'est un monolithe modulaire et quand il doit être préféré à une architecture de microservices.
Un article concis sur les différences entre WebSocket et Socket.IO pour la communication en temps réel
Un comparateur très complet sur les méthodes d'offuscation de mail
Tout est dans le titre
Une exploration de l'écriture d'un serveur HTTP minimaliste dans différents langages : Rust, Golang, Vlang, Ziglang, C et ASM
L'auteur expose des critiques envers bash, et pourquoi il se tourne à présent vers fish
Tout est dans le titre
Tout est dans le titre