Faut-il vraiment encore se casser la tête avec des bases de données self-managed en 2024 ?

Non absolument pas. Sauf si vous êtes une licorne avec des besoins ultra spécifiques et une équipe de 10 DBA sous la main vous n'avez aucune raison de gérer des bases de données self-managed en 2024. Le temps SRE c'est ce qu'il y a de plus cher.

Les services managed comme RDS ou Aurora gèrent l'HA les backups les patchs de sécurité le scaling tout est automatisé. C'est une commodité dont il faut profiter.

C'est d'une naïveté déconcertante. Les bases de données managed c'est une boîte noire. Tu perds tout contrôle sur l'OS le système de fichiers les paramètres kernel même certains paramètres Postgre essentiels.

Et le vendor lock-in avec les fonctionnalités spécifiques à Aurora par exemple c'est un piège. Bon courage pour migrer hors d'un cloud provider après ça. C'est juste déplacer le problème vers un autre type de complexité.

Les deux ont leurs avantages et inconvénients. Pour des applications web classiques avec des CRUD le managed c'est le nirvana. Mais pour des systèmes transactionnels à très haute performance ou des bases de données analytiques self-managed avec un tuning expert ça peut faire une énorme différence de coût et de performance.

On peut optimiser l'I/O avec io_uring sur Linux ou des paramètres système spécifiques. Ce genre de tuning est impossible avec une base de données managed.

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.swappiness=1

C'est ce genre de détails qui sauvent des coûts à très grande échelle.

Le scaling horizontal avec les read replicas en managed c'est en quelques clics. La réplication cross-région pour la résilience c'est une option dans l'interface.

Monter une réplication streaming avec Patroni et repmgr sur des VMs c'est une épreuve. Ça pète régulièrement c'est une source d'incidents majeure et le RTO est souvent catastrophique.

Le coût des managed services ça monte vite. Les IOPS le trafic réseau les backups les métriques custom. Tu te retrouves avec une facture monstrueuse alors que tes serveurs étaient à moitié vides.

Le FinOps des managed DBs est souvent un piège si tu ne surveilles pas tout. Le self-managed avec des VMs bien dimensionnées coûte souvent moins cher à terme.

Pour PostgreSQL les paramètres comme `shared_buffers` `work_mem` `wal_buffers` `max_connections` sont cruciaux. Sur RDS tu as des groupes de paramètres mais tu ne peux pas aller aussi loin que sur une installation bare metal.

Tuner ton système de fichiers ton contrôleur RAID ta carte réseau même le scheduler CPU pour la base de données c'est de l'orfèvrerie. Ça n'existe pas en managed.

Mes SREs ne sont pas des DBAs. Ils sont généralistes. Passer des jours à débugger un WAL segment corrompu ou un problème de réplication logique c'est une perte de temps pour l'entreprise.

Il faut déléguer ces complexités aux experts des fournisseurs cloud. C'est leur métier. Le mien c'est de délivrer des fonctionnalités pas de faire le pompier sur des bases de données.

Vous externalisez vos compétences critiques. Le jour où il y a une panne massive sur RDS vous êtes impuissants. Avoir une expertise en interne c'est vital pour la souveraineté de vos données et votre capacité à réagir.

Ne devenez pas juste des revendeurs de services cloud sans comprendre ce qui se passe sous le capot.

Pour le monitoring Prometheus avec pg_exporter pour PostgreSQL self-managed c'est le top. Tu as une visibilité incroyable sur tout ce qui se passe dans ta base.

# Exemple de scrape config pour pg_exporter
- job_name: 'postgres_db'
  static_configs:
    - targets: ['10.0.0.10:9187', '10.0.0.11:9187'] # Vos instances de bases de données
  relabel_configs:
    - source_labels: [__address__]
      regex: '([^:]+):.*'
      target_label: instance
      replacement: '$1'

Les métriques des services managed sont souvent plus agrégées moins granulaires difficiles à corréler avec des problèmes spécifiques.

La conformité et la sécurité. Les services managed sont certifiés SOC2 HIPAA GDPR. Les patchs et les mises à jour de sécurité sont automatiques. Moins de risques de CVEs.

Sur du self-managed tu dois avoir une équipe SecOps dédiée pour l'hardening les audits les scans réguliers. C'est une charge énorme.

Pour la souveraineté des données ou des régulations spécifiques il est impératif de garder le contrôle total de l'infrastructure et de l'emplacement physique des données. Les clouds providers ne sont pas toujours la solution.

Le self-managed reste la seule option pour beaucoup d'organisations soumises à des contraintes strictes.

La facilité de provisioning pour les développeurs est un point à considérer. En managed ils peuvent souvent créer une base de données en quelques minutes via une API ou une console.

En self-managed ils doivent passer par les Ops créer une VM installer PostgreSQL configurer les utilisateurs. C'est un goulot d'étranglement pour la vélocité des équipes.

Exactement. Le self-service c'est la clé pour accélérer le développement. On ne peut plus se permettre d'attendre des jours pour avoir une base de données de test ou de dev. Ça ralentit toute la chaîne de valeur.

Moins de friction moins de tickets moins de temps perdu.

Le problème avec les services managed c'est aussi l'over-provisioning forcé. Tu paies souvent pour une instance bien plus grosse que nécessaire juste pour avoir les vCPU ou la RAM dont tu as besoin.

En self-managed tu peux dimensionner ta VM au plus juste pour ton workload. C'est de l'optimisation pure.

On ne parle pas assez de l'intégration avec le kernel Linux pour l'optimisation I/O. io_uring peut apporter des gains de performances massifs pour les workloads de bases de données intensifs en I/O.

Ce genre d'optimisation bas-niveau est inaccessible sur une base de données managed.

// io_uring for fast async I/O (conceptual C code)
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, fd, buf, len, offset);
io_uring_submit(&ring);

C'est la différence entre une voiture de série et une voiture de course tunée.

Pour les transactions distribuées ou les architectures microservices complexes vouloir gérer des bases de données self-managed c'est juste de la folie. Tu ajoutes une complexité exponentielle.

Les solutions modernes ou les patterns comme Saga sont faits pour ça pas des setups auto-gérés qui vont partir en vrille au premier incident.

Soutenir l'open source ça compte aussi. Utiliser PostgreSQL MySQL ou d'autres bases de données open source c'est contribuer à un écosystème qui n'est pas contrôlé par un seul acteur. Et tu peux voir le code.

Les solutions cloud sont souvent des fork propriétaires ou des boîtes noires.

L'argument du CSI (Container Storage Interface) en Kubernetes est intéressant. Avec des bons drivers CSI tu peux avoir du stockage persistant performant des snapshots etc.

Mais ça ne remplace pas l'opérateur de base de données comme CrunchyData PGO pour Postgre qui gère la réplication le failover le backup le restore dans un contexte K8s. Ça réduit la charge mais ça reste une infrastructure à gérer.

Les optimisations de coûts. Avec les managed services tu peux bénéficier des Savings Plans des Reserved Instances qui peuvent réduire drastiquement la facture globale.

Les instances self-managed sont souvent sur des VMs génériques qui ne sont pas spécifiquement optimisées pour les bases de données et coûtent plus cher à la longue si on ne fait pas attention.

Tu peux aussi avoir des serveurs bare metal dédiés moins chers que des VMs cloud avec des meilleures performances pour certaines charges de travail.

Pas de frais d'egress pas de coûts cachés. Tu as un contrôle total sur ton matériel et tes licences. Le FinOps c'est mieux avec du self-managed si tu es rigoureux.