Évoluer intelligemment, dépenser moins : comment Oleksandr Leonhard et DashDevs ont transformé l'infrastructure cloud avec AWS

Lorsque Oleksandr Leonhard réfléchit au projet qui a marqué un tournant dans sa carrière en infrastructure cloud, il ne parle pas seulement de serveurs ou d’architectures. Il parle d’élan — pour le produit, pour les clients et pour l’entreprise elle-même.

À l’époque, Oleksandr faisait partie de l’équipe d’ingénierie de DashDevs, où ils construisaient une plateforme interne pour la gestion des processus d’affaires adaptée aux entreprises informatiques.

L’idée était simple : donner aux organisations un moyen d’automatiser les flux de travail, de visualiser les opérations et d’améliorer la coordination interne. Mais à mesure que la plateforme mûrissait et que l’intérêt des clients grandissait, il est devenu clair que l’infrastructure existante n’était pas prête à gérer la pression — financièrement ou techniquement.

« Nous commençions à rencontrer des obstacles, » dit Oleksandr. « L’infrastructure était coûteuse à maintenir, surtout à mesure que le nombre d’utilisateurs augmentait et que la charge de données augmentait. Nos coûts de calcul étaient imprévisibles, et nous passions beaucoup de temps d’ingénierie juste à maintenir la stabilité du système sous charge. »

Reconnaissant que cela ne ferait qu’aggraver le problème à mesure que l’entreprise se développait, Oleksandr a proposé une évaluation complète de leur stratégie cloud. L’objectif était de réarchitecturer le système en tenant compte de l’efficacité des coûts, de l’évolutivité et de la rapidité de développement.

L’équipe a décidé de migrer leur infrastructure vers Amazon Web Services (AWS), en se concentrant sur des services qui réduiraient les frais généraux et leur permettraient de croître sans augmenter constamment les coûts d’infrastructure.

La première étape a été de s’attaquer au composant le plus gourmand en ressources : les bases de données. En les déplaçant vers Amazon RDS, l’équipe a gagné des sauvegardes automatisées, une mise à l’échelle facile et des correctifs de sécurité gérés.

Cela a éliminé une grande partie du travail manuel qu’ils avaient précédemment géré, économisant du temps et réduisant le risque d’erreur humaine. « Avec RDS, nous pouvions compter sur AWS pour gérer la maintenance essentielle, » explique Oleksandr. « Cela a immédiatement réduit notre charge opérationnelle. »

Ensuite, l’équipe s’est penchée sur leur stratégie de calcul. Au lieu de garder un nombre statique de machines virtuelles en fonctionnement, indépendamment de la demande, ils ont mis en œuvre l’Auto Scaling pour les instances EC2.

Cela a permis au système d’ajuster automatiquement le nombre de serveurs en fonctionnement en fonction du trafic en temps réel, garantissant que les ressources n’étaient utilisées que lorsque nécessaire. Cela a aidé à lisser les pics et les creux de l’activité des utilisateurs sans encourir de coûts inutiles pendant les périodes creuses.

Cependant, la transformation la plus significative est survenue lorsque l’équipe a commencé à intégrer l’informatique sans serveur via AWS Lambda et AWS Fargate. En déplaçant des charges de travail spécifiques vers des fonctions Lambda, ils ont pu éliminer complètement le coût des serveurs inactifs.

Ce passage d’un modèle basé sur des serveurs traditionnels à une approche fonctionnelle en tant que service signifiait qu’ils ne payaient que pour le temps d’exécution réel, et non pour des serveurs inactifs attendant des requêtes.

« Lambda a fondamentalement changé notre façon de penser à l’évolutivité, » dit Oleksandr. « Nous n’avions plus besoin d’estimer le nombre de serveurs dont nous aurions besoin à l’avance. Au lieu de cela, nous avons construit des services qui pouvaient évoluer automatiquement et de manière rentable. »

Mais adapter l’application à l’informatique sans serveur nécessitait plus qu’un simple changement technique — cela exigeait une nouvelle approche du développement.

Pour accélérer le processus et éviter de réingénier chaque adaptation client, l’équipe de DashDevs a créé son propre cadre interne sur les services AWS.

Ce cadre leur a permis de développer et de déployer rapidement de nouvelles fonctionnalités et flux de travail, chacun construit comme une fonction Lambda modulaire.

« Avec le cadre, nous pouvions déployer de nouvelles fonctionnalités en quelques semaines au lieu de mois, » note Oleksandr. « C’était un énorme avantage, surtout lorsque les clients demandaient des personnalisations ou de nouvelles capacités. Nous pouvions répondre plus rapidement que nos concurrents, et cela a également considérablement réduit les coûts de développement. »

Après avoir prouvé la plateforme en interne, DashDevs a commencé à l’offrir à d’autres entreprises, adaptant la solution pour s’adapter aux processus d’affaires uniques de chaque client.

Grâce à la conception modulaire du cadre, chaque déploiement était plus rapide et plus rentable que le précédent. Cette adaptabilité a transformé la mise à niveau initiale de l’infrastructure en une nouvelle source de revenus pour DashDevs.

Au cours du processus de réarchitecture, l’équipe a également évalué s’il fallait utiliser Terraform, notamment en raison de sa flexibilité pour l’infrastructure en tant que code à travers les fournisseurs de cloud.

Bien que puissant, le champ d’application plus large de Terraform s’accompagnait d’une complexité qui n’était pas nécessaire pour leur pile axée sur AWS.

Au lieu de cela, ils ont opté pour AWS CloudFormation, qui offrait une intégration plus étroite avec les services AWS et simplifiait l’intégration des nouveaux ingénieurs.

« CloudFormation nous a donné tout ce dont nous avions besoin sans les frais généraux supplémentaires associés à Terraform, » déclare Oleksandr. « Cela a rationalisé nos déploiements et réduit la courbe d’apprentissage pour l’équipe. Pour nos objectifs, le compromis avait du sens. »

Bien sûr, passer à l’informatique sans serveur et à l’auto-scaling n’était pas sans défis. L’équipe a rencontré des limites de concurrence dans AWS Lambda, surtout pendant les phases de test lorsque des pics soudains de requêtes pouvaient pousser le système au-delà de ses seuils configurés.

La surveillance et l’ajustement sont devenus critiques. En utilisant Amazon CloudWatch, ils ont suivi les performances des fonctions, l’utilisation de la mémoire et les temps d’exécution, ajustant les paramètres pour optimiser à la fois la vitesse et le coût.

Pour garder le contrôle financier serré, ils ont mis en œuvre AWS Cost Explorer ainsi qu’un système de balisage détaillé pour surveiller les coûts à travers différents services, environnements et projets clients.

Cette visibilité était essentielle non seulement pour le budget, mais aussi pour apporter des améliorations continues à leur infrastructure.

Au final, les résultats étaient clairs. DashDevs a réduit les coûts d’infrastructure de 25 %, a livré un produit plus rapide et plus fiable, et a considérablement diminué le temps nécessaire pour personnaliser des solutions pour de nouveaux clients.

Peut-être plus important encore, l’équipe a récupéré la bande passante pour se concentrer sur l’innovation produit plutôt que sur la lutte contre les incendies d’infrastructure.

« Nous n’avons pas seulement réduit les coûts, » réfléchit Oleksandr. « Nous avons créé un système qui nous a permis de croître à la fois techniquement et commercialement.

La combinaison des services AWS et de notre cadre interne nous a permis d’aller plus vite, de dépenser moins et de rester en avance sur la courbe. »

Aujourd’hui, ce travail continue de rapporter des dividendes. La plateforme qu’Oleksandr a aidé à réingénier est devenue une base pour plusieurs solutions clients, chacune adaptée mais rentable grâce aux bases que l’équipe de DashDevs a posées.

« Lorsque vous construisez une infrastructure, vous ne résolvez pas seulement les problèmes d’aujourd’hui, » dit-il. « Vous préparez la capacité de votre entreprise à croître sans être piégée par des coûts opérationnels. C’est ce qu’AWS nous a permis de faire, et c’est une approche que je porte avec moi dans chaque projet que j’entreprends. »

Cette histoire a été publiée à l’origine le 3 septembre 2022.