Assurance santé
et prévoyance
Nos guides RH
Notre sélection d'articles
Qu’est-ce qu’une mutuelle d’entreprise ?La mutuelle est-elle obligatoire ?Tous nos articles sur l’assurance santé
Baromètre Alan x Harris Interactive - édition 3
Evolution du bien-être mental au travail et décryptage des aspirations des salariés et managers par secteur
Mise à jour de l'hébergement de nos applications
- Pourquoi Heroku n'était plus approprié
- Vers quel fournisseur nous sommes nous tournés
- Comment nous avons géré la migration
- Pourquoi nous n'avons pas remis en question l'hébergement complet ?
En octobre 2020, nous avons publié un article de blog sur la raison pour laquelle nous avons décidé d'utiliser AWS comme fournisseur d'hébergement.
Nous avons également promis que nous allions remettre en question notre configuration tous les trois ans, la prochaine fois à la fin de 2021.
This Marmot was generated using Dall-E
Il y a quelques mois, nous avons analysé nos besoins et nos risques en termes d'infrastructure en fonction de différents critères : sécurité, efficacité, fiabilité, image publique…
En analysant nos outils, nous nous sommes rendu compte que l'une de nos faiblesses était que nous continuions à nous appuyer sur Heroku comme plateforme de déploiement.
Depuis notre début en 2016, Heroku, une Plateforme-en-tant-que-service (PaaS) détenu par Salesforce, nous a permis de faire fonctionner les applications d'Alan sur les serveurs AWS en déléguant la gestion de ces derniers, tout en nous permettant de pousser du code en production plusieurs fois par jour.
Pourquoi Heroku n'était plus approprié
Après des années de fidèle service, Heroku n'était plus approprié pour nous :
Heroku est cher. Bien que nous en n’avions pas une utilisation très importante, cela nous coûtait environ 200K€ par an. Nous devions souscrire à des plans annuels fixés à l'avance qui ne s'adaptaient pas à notre consommation : nous payions pour tout, même si nous n'utilisions que la moitié, et il était difficile d'obtenir plus de ressources.
Heroku est assez peu flexible. Il existe des limitations prédéfinies dans Heroku (telles que la taille des machines et des applications déployables) qui nous obligeaient à trouver des solutions pour contourner le problème à chaque fois, ce qui devenait gênant. Cela convient très bien à des petites start-ups, mais ce n’est plus adapté à notre utilisation.
Heroku a peu progressé ces dernières années. La majorité des mises à jour sont techniques et il n'y a pas de nouvelles fonctionnalités qui nous intéressent.
Notre engagement avec eux prenait fin en juillet 2022, c’était donc l’opportunité parfaite pour remettre en question notre utilisation.
Vers quel fournisseur nous sommes nous tournés
Pour remplacer Heroku, nous nous sommes tournés vers les offres prometteuses de Plateforme-en-tant-que-service (PaaS).
Comme nous avons une légère préférence pour les fournisseurs français, nous avons voulu essayer Qovery, qui semblait convenir.
Au moment de nos tests (début de 2022), Qovery était prometteur en termes de flexibilité, de tarification et de fonctionnalités. Malheureusement, il leur manquait notamment un outil solide d'infra-as-code avec Terraform, un composant très important pour nous afin de gérer notre infrastructure de façon saine.
Notre alternative était de concentrer notre hébergement chez AWS, qui proposait une alternative moins chère et plus flexible qu'Heroku, appelée ElasticBeanstalk.
En termes de réduction des coûts, ce déménagement nous permet d'explorer des opportunités telles que l'utilisation d'instances réservées, le passage aux machines ARM / Graviton, etc. Avec les instances à la demande, vous payez un prix mensuel mais il n'y a aucun engagement de temps. Avec les instances réservées, vous réservez des instances pour une certaine période de temps, à un prix réduit. En agissant ainsi, nous avons estimé que nous pourrions économiser au moins 5 % de notre facture AWS.
En termes de flexibilité, ElasticBeanstalk nous fournit la taille de machine et d'application dont nous avons besoin, ainsi qu'un meilleur contrôle de l'infrastructure et du build. Faisant partie de l'écosystème AWS, cette solution s'intègre bien à une variété de services, notamment avec les Virtual Private Clouds, qui sont essentiels à la sécurité des données de nos membres.
En termes de migration, la consolidation de tous nos outils d'hébergement chez un seul fournisseur (AWS) nous permet, bien que ce soit contre-intuitif, de plus facilement migrer à l’avenir. Moins de fournisseurs signifie moins de barrières à maintenir et à migrer si nous décidons de changer d’hébergeur.
En fin de compte, sa meilleure scalabilité convient mieux aux besoins de l'entreprise.
Comment nous avons géré la migration
Comme nous visions zéro temps d'arrêt, nous avons fait fonctionner les deux infrastructures en même temps, pour nous assurer que tout fonctionnait bien avant d’arrêter Heroku.
D'un côté, nos utilisateurs avaient accès aux applications d'Alan qui tournaient sur Heroku, comme d’habitude. De l'autre côté, nous étions en train de déployer les mêmes applications sur ElasticBeanstalk, sur une version de test.
Une fois la version tournant sur ElasticBeanstalk opérationnelle, nous avons basculé les utilisateurs sur cette version sans aucun temps d'arrêt, sans aucun impact sur l'expérience utilisateur.
En termes de sécurité, rappelez-vous qu'en coulisses, Heroku utilise AWS, nous n'avons donc pas eu à changer notre stratégie.
Cela nous a pris du temps, et comme nos crédits Heroku prenaient fin le 31 juillet, nous avons connu une petite période de rush.
En fin de compte, grâce aux efforts de notre incroyable Foundation Unit, la transition s'est déroulée sans heurts et nous avons fermé Heroku le 29 juillet (en réalité, nous avions déjà négocié une extension avec Heroku au cas où les choses ne se passeraient pas bien). Cette histoire mériterait son propre blog !
Pourquoi nous n'avons pas remis en question l'hébergement complet ?
Il y a plusieurs raisons pour lesquelles nous ne voulions pas remettre en question l'hébergement de nos applications (auparavant sur Heroku) et de nos données (sur AWS) en même temps.
Tout d'abord, notre nombre d’ingénieurs est limité et une migration complète de notre hébergement aurait eu un très lourd impact sur notre capacité à construire des produits pour nos membres (Member-First est l'une de nos valeurs !).
Nous avons également décidé qu'il serait plus efficace de migrer complètement vers le même fournisseur, afin d'avoir plus de flexibilité si nous voulions remettre en question notre configuration dans le futur.
En simplifiant le processus de migration vers un autre fournisseur, nous avons atténué le risque de devenir trop dépendants d'AWS. Cela peut sembler contre-intuitif, pourtant ce sont les interfaces entre les outils qui sont généralement les plus difficiles à gérer.
Et enfin, le concept de "clouds de confiance" est toujours en évolution en France. Nous ne pouvons pas nous permettre de parier sur une technologie qui n'a pas un historique solide (cf notre philosophie de “Boring Technology”), et qui ne résoudrait pas le problème sous-jacent lié à l'image. De plus, nous sommes toujours persuadés que nous utilisons la meilleure solution en termes de sécurité et de confidentialité, comme détaillé dans notre article précédent.
La prochaine remise en question de notre hébergement complet aura lieu en 2024. Nous serons heureux d'examiner les propositions à ce moment-là !
