Infrastructure
L’infrastructure, un sujet passionnant que l’on se doit de revisiter régulièrement pour mettre ses techniques au goût du jour…
Chaque équipe métier acquière avec le temps des préférences en fonction de ses choix, ses contraintes et de son niveau de maturité devOps:
un choix de cloud provider ?
un service de cloud managé ?
de l’infra en mode « Do it yourself ». vps? machines virtuelles? serveurs baremetal?
Il y a pléthore de solutions, aucune d’entres elles n’est meilleure qu’une autre, chacune répond à un contexte précis.
Quelque soit la solution adoptée, construire une infrastructure résiliente et hautement disponible a un coût financier ainsi qu’un investissement en temps humain.
Dans ce projet, j’ai cherché à modeler l’infrastructure pour répondre à ces contraintes:
l’infrastructure doit être déployée très rapidement.
elle doit être multi fournisseurs (c’est la tendance actuelle, on parle de multicloud partout).
qui dit multicloud, dit multi régions (voir multi régions chez un même fournisseur).
l’infrastructure doit pouvoir « scaler » horizontalement et verticalement.
L’infrastructure se doit d’être, autant que possible, « as code ».
Toute ma R&D a consisté à résoudre ces problèmes structurels pour éviter de remettre en question les bases de l’infrastructure à chaque révolution marketing et/ou technologique.
Ce que j’ai personnellement compris avec le temps c’est que la finalité n’est pas l’infrastructure mais la capacité de celle-ci à porter des logiciels. C’est le logiciel le service produit, c’est lui qui apporte la valeur, le reste ne doit être que de la commodité…
En construisant une infrastructure générique, sur du matériel commun (common hardware), on s’offre de la flexibilité pour traverser les évolutions.
Le but étant d’apprendre, j’ai choisi d’éviter les solutions SaaS pour ne pas enfermer mes réflexions dans un produit propriétaire.