Hébergement - Partie 1 : Du garage au nuage

Lorsqu’on conçoit un produit digital, on se concentre beaucoup sur les questions de marketing, l’UX, et on passe très vite sur des questions plus techniques comme le choix de l’hébergement. En fin de compte, ça devient un non-choix pour le client qui se voit imposer un hébergeur par le prestataire qui va développer la solution, ou pire…, un non-choix de l’équipe de développement qui se voit imposer ce choix par un client sans même comprendre l’impact que cela va avoir sur le produit ou sur le coût de développement. On va essayer d’y voir plus clair avec cette série d’articles en allant de plus en plus loin dans le détail.

Je vous propose de retracer ici les différentes étapes qui nous ont menés au Cloud et ses solutions pour bien comprendre l’état de l’art actuel. Si c’est quelque chose que vous maîtrisez déjà, n’hésitez pas à aller directement aux parties suivantes: Hébergement - Partie 2 : les différents niveaux & Hébergement - Partie 3 : Ce que le cloud fait pour nous

Pour illustrer mes propos, prenons le cas d’un produit digital reposant sur une application mobile qui va offrir divers services en utilisant un serveur centralisé. Par exemple l’application “Où sont les toilettes” qui permet de trouver les toilettes publiques les plus proches de votre position, mais aussi de les noter, etc.

Mais au fait c’est quoi un serveur ?

Avant de commencer il faut clarifier ce que veut dire serveur. Dans la vie de tous les jours, on imagine bien ce qu’est un “Serveur”. C’est la personne qui vous apporte les plats quand vous êtes au restaurant. Regardons un peu les interactions que vous avez avec lui.

→ Le Serveur circule entre les tables en attendant qu’un client l’interpelle

← Vous êtes à votre table, vous lui faites un signe

→ Il vient vous voir et vous demande comment il peut vous aider

← Vous lui formulez une requête, par exemple : “Pourrais-je avoir une carafe d’eau s’il vous plaît”

→ Il va chercher la carafe, vous la rapporte et vous demande s’il peut faire autre chose pour vous.

← Comme vous êtes poli vous lui dites que c’est parfait et vous le libérez pour qu’il puisse aller voir un autre client.

Dans le cadre d’une application mobile, c’est un peu la même chose sauf que le Client est l’application mobile, la parole ou les signes sont des communications réseau et la carafe d’eau est généralement de la donnée.

→ Le serveur attend de nouvelle connexion

← L’application initie une connexion avec le serveur

→ Le serveur l’accepte et écoute la requête

← L’application demande la liste des toilettes

→ Le serveur récupère cette liste dans sa base et la renvoie

← L’application récupère la réponse puis ferme la connexion

Ici je parle de serveur mais dans le sens application serveur. C’est différent du “serveur”, la machine qui va faire tourner cette application. Tout comme le client qui peut à la fois désigner l’application mobile et qui communique avec le “serveur”, que la personne qui vient nous voir pour qu’on lui développe l’application 🤯.

Pour simplifier la lecture, je vais donc appeler “Backend” l’application et “Serveur” la machine qui exécute les requêtes du backend. En théorie, n’importe quelle machine qui fait tourner un backend devient un “Serveur”. Que ce soit une vieille tour que vous n’utilisez plus, ou bien votre laptop, ou même votre téléphone.

Où mettre ce serveur ?

Le garage

Tous les grands, Google, Microsoft, Apple, Hp, etc, ont commencé par le même endroit pour mettre leur premier serveur… Leur garage !!! Bon d’accord, les plus récents comme Facebook et compagnie sont directement passés à l’étape d’après.

Au début c’était suffisant, il a fallu acheter une machine un peu puissante, prendre un abonnement à un fournisseur internet comme Wanadoo 👴 Et hop, c’était parti. ✌️

Le problème avec cette première version c’est que s’il y a des travaux dans ma rue et qu’ils coupent le courant, ou si SFR ou Orange vient fibrer mon voisin et me débranche au passage 🤬, mon serveur n’est plus accessible ! On va aller le mettre ailleurs pour plus de sûreté.

L’hébergeur version 1

En cherchant un peu, je tombe sur une société qui fournit une prestation d’hébergement. C’est-à-dire que je prends ma machine, je vais la poser littéralement chez eux et ils me fournissent le courant et la connexion internet. De plus ils font ça bien, donc le courant arrive de plusieurs fournisseurs d’électricité tout comme la connexion internet pour garantir que même s’il y a des travaux dans le coin et qu’on coupe un câble, il y aura toujours du courant et une connexion internet. Ouf je suis rassuré

C’est pas mal mais j’ai encore besoin de me déplacer pour aller mettre ma machine. En plus il faut que j’achète une machine plus puissante parce que je commence à avoir un peu plus de trafic sur mon backend, que faire de l’ancienne ?

L’hébergeur version 2

Plutôt que d’acheter une nouvelle machine, l’hébergeur me propose de lui en louer une. Je vais donc le laisser gérer complètement mon matériel. Pour ça il faut que je passe par un formulaire, que je paie, une fois que le paiement est validé, le fournisseur regarde s’il a ça en stock ou va le commander puis aller le mettre en place. Bref, 2 semaines après je reçois un mail avec les informations de connexion et je peux enfin commencer à aller l’installer. Ça a été long, mais ça y est, mon backend est déployé dessus. 🤟

Comme je loue assez cher cette machine, je vais aussi y mettre le backend d’une autre application que je développe.

Je ne suis pas fan de cette approche parce que s’il y a une faille sur le backend d’”Où sont les toilettes” et qu’un hacker pirate mon serveur via ce backend, ça compromet aussi mon autre application. En plus je commence à avoir pas mal de monde sur cette application et ça impacte le temps de réponse de mes autres applications. On doit pouvoir faire mieux !

L’hébergeur version 3

Le fournisseur me propose une autre solution, plutôt que louer une machine physique comme je pourrais avoir chez moi, il me propose de louer une machine mais Virtuelle. Grosso modo, un ordinateur dans un ordinateur. Pour le coup je peux en prendre une petite pour mon autre application et une plus grosse pour mon premier backend. Mes backends sont isolés donc plus de risque de compromission entre eux. En plus comme c’est du virtuel et qu’elles tournent sur tout un tas de machines gérées par le fournisseur, j’ai ma machine tout de suite. Trop content 😍

J’ai fait un peu de pub pour mes application et je commence à avoir pas mal d’utilisateurs avec leurs données, s’il y a un tremblement de terre ou le feu dans le DataCenter de mon hébergeur, je perds tout. Il faut que je sauvegarde toutes mes données ailleurs régulièrement et en plus si jamais ça arrive, redéployer mes backends sur un nouveau serveur va me prendre du temps, peut être plusieurs jours. Comment faire pour que ça n’arrive pas ? En plus tous les mois il faut que je repasse sur toutes mes machines virtuelles pour mettre à jour les patchs de sécurité de systèmes d’exploitation.

Ça me prend pas mal de temps et il faut que je développe des outils pour ça. J’ai vraiment mieux à faire 😞

Le cloud ☁️

Pour le coup j’ai regardé du côté du “Cloud” il semble pas mal mais pour profiter réellement de ses avantages j’ai dû revoir un peu le code de mon backend pour pouvoir utiliser les services qu’ils proposent. Sans quoi ça n’apporterait pas grand-chose de plus que mon ancien hébergeur. J’ai donc modifié mon backend pour utiliser la base de données et le système de stockage du “Cloud Provider”. Mais au moins maintenant je suis tranquille, je peux dormir sur mes 2 oreilles. Le fournisseur gère pour moi les backup, les patchs de sécurité et la disponibilité des différents services. Dans le cas où le serveur ne répondrait plus, j’ai pu utiliser leur système de surveillance automatique pour faire en sorte qu’un nouveau serveur soit automatiquement déployé. En plus j’ai pu faire tout ça avec l’outil “Terraform” qui utilise les API du Cloud Provider pour configurer tout ça a ma place. Je peux donc me concentrer sur l’ajout de fonctionnalités pour mon application et pas sur de l’outillage qui n’apporte pas de valeur à mes utilisateurs. 🙌

Conclusion

Héberger un backend n’est pas si simple. Si nous voulons le faire en s’assurant qu’il soit toujours disponible cela nécessite de prendre en compte plusieurs aspects comme les backups, le temps de rétablissement, la sécurité etc. Plus nous allons vers des hébergeurs avancés, moins nous aurons à nous en occuper et plus nous pourrons nous concentrer à apporter de la valeur au produit digital que nous sommes en train de développer.

Maintenant que nous avons bien vu les différentes problématiques qui nous ont amenées vers le Cloud, je vous propose de repasser rapidement sur les différents acronymes en allant voir cette article Hébergement - Partie 2 : les différents niveaux ou bien de voir, sur une architecture concrète, ce qu’AWS fait pour nous dans cet article Hébergement - Partie 3 : Ce que le cloud fait pour nous