Skello Tech Team
Published in

Skello Tech Team

Notre migration sur AWS

Au lancement de Skello en 2016, nous avons choisi une solution PAAS pour héberger notre plateforme.

A l’époque, l’équipe technique était réduite, nous nous sommes concentrés sur la livraison de valeur à nos clients sans nous occuper des aspects d’infrastructure.

Début 2021, le nombre de clients augmentant énormément, nous nous sommes rendu compte que cette plateforme PAAS nous coûtait très cher et que les possibilités étaient restreintes techniquement.

Nous avons donc lancé la migration de notre plateforme vers AWS à l’été 2021.

Organisation AWS

Pour créer nos environnements, nous nous sommes basés sur l’AWS Well Architected Tool pour créer différentes Unités Organisationnelles.
Un des enjeux du cloud est la sécurité.
Nous avons donc isolé les comptes selon leur domaine de responsabilité (IAM, Billing, Network…).
Notre compte AWS IAM est le point central qui gère nos utilisateurs (ajout, modification, suppression …) . Il est impossible de créer des utilisateurs à partir du compte de prod , rec ou autres …

Plateforme AWS

Après avoir crée nos environnements AWS nous étions prêts pour migrer nos applications. Nous avons commencé par notre monolithe qui est le composant principal puis nous avons continué en déplaçant nos micro services.

Network

Durant la migration il était important de renseigner les flux réseaux internes et externes (https, inter services …). Il était ensuite plus simple de mettre en place la partie réseaux et tout particulièrement les pare-feux gérés via le service security group.

Le déploiement des services et l’accès à nos applications passent par une bonne gestion de notre réseau. Nous avons un compte dédié qui nous permet de gérer l’ensemble du réseau de notre organisation en utilisant la transitgateway. Celle-ci autorise la communication entre les environnements de notre organisation à condition d’être sur la même région. Le vpc peering permet quant à lui de communiquer entre différentes régions.

La migration nous a permis de prendre en main la gestion de notre réseau en cloisonnant nos données et services via des sous-réseaux privés.

Le sous-réseau public nous permet de communiquer vers l’extérieur à travers la nat gateway qui est portée par un environnement spécifique.

Ec2

Le déploiement des applications repose sur un réseau privé avec des accès restreints aux machines.

Nous avons utilisé l’approche Lift and Shift . En effet, il était important de rester sur une infrastructure simple à maîtriser.

Cela nous a permis de gagner du temps car nous avons juste répliqué les mêmes configurations et aussi évité une refonte sur l’architecture.

L’objectif était de migrer en moins de 4 mois !

Cette méthode nous a donné la possibilité d’une meilleure maîtrise de l’infrastructure sur AWS. Toute l’équipe n’étant pas forcément mature sur la gestion des containers, nous avons préféré le faire par étape.

Un des challenges de cette migration était d’avoir une résilience et une haute disponibilité. La gestion des services AWS a répondu à ce besoin :

  • Gestion des zones de disponibilité des machines avec mise en réseaux sur toutes les zones
  • Gestion de l’autoscaling à 2 machines minimum en production selon les besoins du service et la charge des machines

L’infra as code, partie prédominante de la migration

Et la CICD dans tout ca ?

La plateforme PAAS nous proposait une intégration continue très simple côté développeur avec github, pas grand chose à paramétrer.
Une fois sur AWS, nous avons adapté notre CI en fonction de nos orientations techniques.

Bien qu’il soit possible d’intégrer en continu notre code via github action nous avons décidé d’utiliser codebuild et codepipeline car ils proposaient un accès direct à notre base de données via le VPC (la base de données étant utilisée pour nos tests d’intégration).

Notre stack infra terraform est versionnée sur gitlab. La pipeline applicative dépose l’artefact de notre build. Une notification est envoyée à notre pipeline d’infra, celle-ci lance l’applicatif ciblé .

Des méthodes de migrations différentes selon les cas

Pour sécuriser notre périmètre de déploiement applicatif nous sommes partis sur l’automatisation de nos ressources Cloud. Cela nous est utile afin de répliquer nos environnements identiques sans erreurs humaines. Toute notre infrastructure est codée et versionnée.

Chez Skello nous adoptons une approche DevOps en impliquant les devs et l’infra au développement du produit. Pour cela nous utilisons Cloudformation et Terraform.

Terraform

Terraform est un outil open source provenant de l’écosystème Hashicorp. Il a de plus en plus de fonctionnalités facilitant le déploiement des ressources sur différents providers (AWS, GCP, Azure, Datadog, Postgres, Cloudflare …). Nous utilisons Terraform pour déployer du IAAS (Infrastructure as a Service : ec2, networking …). Ces ressources bougent peu et sont gérées par l’équipe Cloud, le code est facilement maintenable si on part sur une bonne organisation dès le début (ça sera l’occasion d’en parler lors d’un prochain article). Certains micro services restent identiques et sont basés sur une stack assez simple (ec2,asg, rds). Ces ressources sont déployées via des modules Terraform développés par AWS en amont ce qui nous permet de gagner du temps sur le code et de pouvoir déployer plusieurs micro services à la volée. Nous utilisons également Terraform pour déployer des ressources managées telles que S3, Rds, Athena, Opensearch …

CloudFormation

Nous exploitons au maximum la pluridisciplinarité de nos développeurs et de notre équipe cloud avec 2 approches différentes.

CloudFormation via Cdk

Nous nous sommes rendus compte au fur et à mesure de nos déploiements que nous avions une certaine complexité sur la gestion de notre infra notamment l’utilisation de DMS .
Dans notre code nous avons plusieurs boucles et des conditions de paramètres à appliquer en fonction de la source de données et de l’environnement.
Il est tout à fait possible de le réaliser via terraform qui comprend plusieurs fonctions (foreach, count, conditions ternaires …). Cependant c’est assez périlleux bien qu’on puisse optimiser nos modules terraform pour réutiliser selon nos projets. En échangeant avec les développeurs nous nous sommes laissés le choix de pouvoir déployer l’infrastructure via cdk car celui-ci permet plus de souplesse sur la gestion des boucles, conditions, héritages. Lors des projets à déployer c’est donc l’ingénieur Cloud qui se portera owner et verra la pertinence pour déployer sur une stack terraform ou cdk selon ses appétences. C’est également un moyen d’évangéliser nos équipes de développement sur l’infra as code tout en ayant un skills de programmation pour l’infra !

CloudFormation via le framework Serverless

Ce parti pris est plus orienté pour les développeurs responsables de leur micro services orientés serverless (AWS lambdas, DynamoDb, APIGateway). Il nous est paru plus simple de déployer des lambdas via le framework Serverless.
Le développeur n’est pas perdu sur l’infra as code vu qu’elle est codée en typescript.

Bien que nous ayons deux approches différentes pour notre infra as code, elles se complètent. Le framework Serverless amène le développeur à prendre conscience de l’automatisation des applications sur le Cloud et de se coordonner avec la team Cloud sur les variables à mettre. La partie Terraform nous permet d’anticiper et de pouvoir nous projeter si nous souhaitons nous projeter sur du multi-cloud. L’environnement Hashicorp pourrait bien nous aider sur cette partie (Terraform, Vault avec la gestion des secrets …)

Le monitoring

Une fois la migration réalisée sur l’ensemble de la plateforme nous nous sommes intéressé au monitoring de notre plateforme en conservant Logentries et Datadog.
Logentries essentiellement pour la lecture de nos logs applicatifs et Datadog pour l’observabilité de la plateforme. Nous avions également la journalisation de nos logs sur CloudWatch avec des alertes que nous avons définies en amont afin de pouvoir anticiper tout incident (cpu, espace disque …). C’est une première étape avant de baser notre monitoring sur d’autres outils. L’ensemble de nos événements inter comptes sont gérés par CloudTrail afin de répondre au mieux aux audits.

Notre prod étant prête, nous avons pu avoir plus de visibilité sur nos besoins en terme de monitoring. Après réflexion nous avons regroupés au sein de datadog à la fois la gestion des logs et également l’observabilité sur l’ensemble de nos ressources.

Notre migration sur AWS nous aura pris 4 mois en tout.
La migration lift and shift nous a permis de déplacer la plateforme sans accroc notamment car nous avons surdimensionné toutes les ressources techniques. Ressources que nous avons pu optimiser très facilement par la suite.

Fuki, Ingé cloud — Skello Tech Team

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store