Ceci est le premier épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.
“Pourtant, ça marchait bien quand on l’a testé, et en prod ça ne marche pas !” (MJ, chef de projet, penaud et grosses cernes sous les yeux)
A combien de reprises ai-je été confronté à des mises en production chaotiques, parce que - quand on creuse pour trouver la raison principale - l’environnement sur lequel on a testé le système n’est pas exactement équivalent à la production ? En général, hors cloud, l’environnement sur lequel on teste une application n’est pas le même : il est a priori sous-dimensionné (parce que c’est moins cher) ; certains éléments d’infra sont simplifiés (règles de cloisonnement réseau plus limités car l’environnement n’est pas exposé à l’extérieur, autre stockage, clusters remplacés par des instances uniques…). Et en plus, ce sont parfois des organisations différentes qui gèrent ça (environnement de développement géré par des équipes hors prod, ou par des sous-traitants). Sans compter que la config réseau est gérée par l’équipe réseau, la config des pare-feux par l’équipe pare-feux, la config du SAN par l’équipe stockage…
Quand on monte une infra sur AWS, on peut gérer ça complètement différemment. L’outil vraiment épatant, c’est cloudformation. En un mot, c’est le fait de décrire son infrastructure dans un script, qu’on peut exécuter pour monter son infrastructure. C’est extraordinairement puissant. Il faut réaliser qu’on peut monter une infrastructure complète (config réseau, sécurité, base de données, stockage, cache, script de boot des serveurs, certificats SSL, répartition de charge, …) en définissant un script et en le lançant. Par exemple, pour construire un environnement de référence pour l’hébergement de wordpress avec haute disponibilité des frontaux et de la base répartis sur plusieurs datacenters, connexion SSL, CDN, cache, …, on peut trouver un script standard ici.
Et c’est là que ça trouve tout son intérêt : besoin de tester ? On fabrique l’infra de test le temps du test. Et on l’efface après. Même si l’infra est grosse, ça ne coûte presque rien, parce qu’on ne paye l’infra que le temps du test. Du coup :
- finie la galère de l’environnement de test qui n’est pas iso-prod. Copier, coller. Pas plus compliqué.
- et en plus, c’est moins cher ! au lieu d’avoir un environnement de test sous-dimensionné en permanence, on a un environnement de test parfaitement iso-prod, juste le temps du test.
Bon, on peut évidemment aller beaucoup plus loin, avec par exemple de l’intégration et de la mise en production continue, on aura l’occasion d’en reparler.