Infrastructure Serverless – Partie 5 : Micro-services et conclusion (Patreon)

Comme vous le savez sûrement, au fil du temps le blog korben.info est devenu un site conséquent et par son nombre de page que par sa sollicitation.Régulièrement,  nous cherchons et mettons en place divers outils ou méthodes dans le  but d’optimiser son exploitation, c’est à dire le rendre plus  performant, plus rapide, mais aussi plus stable. Inévitablement il arrive que soit l’infrastructure elle-même qui nécessite une optimisation.

Ces derniers temps, nous avons étudié la possibilité d’une  transition vers une nouvelle forme d’infrastructure. Cette forme,  récemment popularisé sous le nom un peu buzzword de  « serverless », propose de distinguer les différentes parties d’une  structure web classique pour les placer dans des environnements qui leur  sont adaptés et ainsi optimiser à chaque étape.

De manière générale, nous avons définis les objectifs avec les points suivants.

Optimiser le rendu web pour gagner en performances et en dynamisme ;

Bénéficier d’un dimensionnement dynamique pour absorber le trafic tout en économisant des ressources ;

Réduire la surface d’attaque pour maximiser sa sécurité ;

Favoriser la portabilité pour simplifier le changement de solution ou de prestataire.

Dans ce dossier, nous vous proposons d’explorer et de mettre en place un schéma d’infrastructure serverless, étape par étape.

Notre dossier sur l’infrastructure serverless

Infrastructure Serverless – Partie 1 : Générateur de site

Infrastructure Serverless – Partie 2 : Hébergement statique

Infrastructure Serverless – Partie 3 : Gestion de contenu

Infrastructure Serverless – Partie 4 : Fonctions cloud

Infrastructure Serverless – Partie 5 : Micro-services et conclusion (cet article)

<figure></figure>

Micro-services et conclusion

Les micro-services

Si vous avez suivi notre cheminement dans cette découverte  d’une infrastructure serverless, vous avez probablement remarqué que  chaque partie est fortement distinguée des autres.

Ainsi, le templating (Partie 1), l’hébergement (Partie 2), la base de  contenu (Partie 3), et le rendu dynamique (Partie 4), vivent tous dans  un environnement singulier des autres. Ils communiquent entre eux bien  sûr, mais cette distinction offre une certaine modularité.

En comparaison, WordPress par exemple, nécessite un serveur configuré  pour l’hébergement et tente de faire le café : routage, templating,  génération, gestion de contenu, pre/post-processing.Utile mais lourd, et pas forcément si pratique que ça sur le long terme.

L’approche serverless résume bien la tendance derrière ce que l’on  appelle les micro-services. Cette vision d’architecture tend à diviser  les responsabilités pour les ouvrir plus facilement aux changements et  aux optimisations.Même si on la rapproche plus fréquemment à une  structure logicielle, notre cas l’illustre bien par rapport à un CMS  monolithique.

La vue globale

Prenons un peu de hauteur, avec une vision globale de notre  infrastructure, où il est plutôt facile de distingues les différents  acteurs.Voici le schéma d’une infrastructure telle que nous pouvons la concevoir sur une base serverless.Ici, dans le cadre de notre travail sur korben.info, le CMS est WordPress, en mode headless, et donc déployer sur un vrai serveur (on triche un peu du coup, mais à peine).

<figure></figure>

Le flux de données suit le trajet suivant :

Les visiteurs tout-venant, demande une page du site, et génère une requête HTTP. Du bon gros standard, quel que soit la source.

Un  système de gestion des routes aiguille la requête vers le bon services.  La majorité des prestataires permet une configuration assez fine du  routage, mais très souvent, par défaut rien à faire.Dans notre cas,  il peut être utile de placer ici d’un côté un par feu pour applications  web sur la partie publique et un intermédiaire d’authentification sur la  partie privée.

Sur le CDN, au plus proche physiquement possible  du visiteur, les fonctions cloud qui assurent le traitement du  « dernier kilomètre ».

Toujours en edge, le plus proche possible, l’hébergement des fichiers statiques.

Beaucoup  plus loin, le gestionnaire de contenu permet aux rédacteurs et aux  gestionnaires de manipuler le contenu brut. À chaque édition,  l’évènement est propagé vers le générateur.

Stocké dans dépôt,  le générateur est manipulé par les développeurs. Point bonus s’il  s’intègre à une plateforme qui permet de monitorer les compilations et  les déploiements.

Entre 5. et 6., à chaque évènement, une  compilation est lancée et les fichiers statiques générés. Ils sont  ensuite déployés sur l’hébergement.

Conclusion

Au final, qu’obtenons-nous vis-à-vis de nos objectifs initiaux ? Reprenons nos points d’introduction.

Optimiser le rendu web pour gagner en performances et en dynamisme

Par l’utilisation de l’hébergement statique, il est aujourd’hui  difficile d’offrir de meilleures performances sur les réponses HTTP.Bien  sûr, il faut garder en tête que l’hébergement et le type de rendu ne  résous pas tout. Si la réponse n’est pas optimisée, contient une  montagne de JavaScript ou de lourdes images non traitées, le chargement  dans le navigateur restera laborieux.

Bénéficier d’un dimensionnement dynamique pour absorber le trafic tout en économisant des ressources

N’ayant plus aucun travail de rendu à faire à chaque requête, le  serveur derrière l’hébergement est minimal. Les CDN offrent généralement  tout le nécessaire pour être efficace quel que soit la charge.Cela s’applique aussi aux fonctions cloud, lancées unitairement à chaque requête est se dimensionnant très facilement.

<figure></figure>

Réduire la surface d’attaque pour maximiser sa sécurité

Avec la mise en place d’une telle infra, la partie publique et la  partie privée (CMS) sont bien isolés. Il est donc plus compliqué pour un  attaquant d’atteindre la base de données.Aussi, les fichiers étant statiques, aucune injection vers le serveur n’est possible.Les fonctions quant à elles sont isolées, elles-aussi. La sécurité absolue n’existe pas, mais la surface est bien réduite.

Favoriser la portabilité pour simplifier le changement de solution ou de prestataire

Cerise sur le gâteau, pour presque chaque étape, migrer vers une autre solution est un jeu d’enfant.Un  autre générateur ? Aucun problème, on sélectionne la source de donnée  qui va bien et on n’a plus qu’à se concentrer sur le « thème ».Un autre hébergeur ? Les stockages de fichiers statiques pavent nos rues numériques.Un autre CMS ? Ici il reste à traiter la base de données, mais techniquement les autres parties n’y verraient que du feu.Un autre presta pour la fonction cloud ? Il commence à avoir beaucoup de choix, et une standardisant des API.

Qu’en pensez vous ? Chez korben.info, on est convaincus ! 😊

Ainsi s’achève notre petite aventure dans la méandres d’une  infrastructure serverless. Si vous des questions ou souhaitez faire un  retour, n’hésitez pas à me contacter sur Twitter, ou à me suivre sur GitHub.