Options d'architecture
Dernière mise à jour
Dernière mise à jour
Lorsqu'on commence à mettre en place une nouvelle architecture, on est souvent confronté à beaucoup de choix.
En plus, il n'est pas rare que notre choix d'architecture influence le design d'autres modules de notre plateforme (en théorie, cela ne devrait pas être le cas, mais en pratique, on n’échappe pas toujours ce cas).
Aujourd'hui, l'option d'utiliser les "services", notamment une Database As A Service (DBAS) est très attractive pour plusieurs raisons :
On n'a pas à s'occuper du niveau "physique" de nos données : le système d'exploitation, les mises à jour, le stockage, les périphériques physiques. Tout est à la charge de l'hébergeur.
Moins de temps sur la maintenance et les opérations.
Moins de compétences techniques
Attention, par contre, il y a fréquemment des pièges. Notamment au niveau de facturation, on se trouve parfois avec des factures énormes :
Le DBAS facture par quantité de données transférées en dehors de leur service (exemple Firebase)
Si on ne maîtrise pas ses transferts (par exemple, notre API fait systématiquement select *) on se trouve vite avec une facture inabordable.
Le DBAS facture par quantité de données stockées
Souvent, pour avoir du contrôle plus fin sur les utilisateurs et les droits d'accès, il faut payer un abonnement plus cher
Est-ce qu'il faut payer plus cher les sauvegardes automatiques ?
En plus, vérifiez bien que les connexions au service sont bien cryptées ! Il n'est pas toujours le cas, ou il faut payer plus cher !
Pour contourner le problème du prix de transfert, souvent, on conseille d'héberger chez le même fournisseur les applications qui consomme les données. La plupart du temps, la communication sur le même réseau interne n'est pas facturée.
Mais attention ! Vous êtes maintenant totalement dépendant du même hébergeur. Attention aussi, les autres désavantages n'ont pas été traités (coût du stockage, contrôle d'accès).
Il n'est pas mon but de vous décourager l'utilisation d'un DBAS ! Aujourd'hui il est difficile de s'en passer.
Pour les petites entreprises qui ne peuvent pas assumer des factures surprises, pour un développeur qui veut expérimenter tout seul, ou bien pour les plus grandes entreprises qui veulent maîtriser mieux leurs coûts, il reste encore la solution d'hébergement autonome.
Je vais passer par cette option pour ce cours, parce que
il y a plus de choses à apprendre et apprécier en faisant soi-même
le prix est moins cher pour un étudiant
L'architecture qu'on va utiliser dans ce cours est le suivant :
Nous allons déployer manuellement un SGBDR (notamment MariaDB) en utilisant Docker. Toute connexion avec la base en dehors du même hôte (ou réseau hébergeur) doit être sécurisé par un Tunnel SSH.
Nous avons donc entièrement la main sur le SGBDR :
On peut gérer toutes les options de déploiement et opérations
On peut gérer finement le contrôle d'accès
On peut configurer nous-mêmes notre stratégie de sauvegarde et restauration
Nous maîtrisons les coûts (le prix de location d'une instance)
Je veux surtout que vous soyez au courant des désavantages cachés
Vous pouvez ensuite passer sur un DBAS dans vos vies professionnelles, mais vous apprécierez tout ce que vous payerez ! Ou bien apprécier les limitations
