Options d'architecture

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).

Database as a Service

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.

Je veux surtout que vous soyez au courant des désavantages cachés 😉

Option Self Hosting

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

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 😄

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)