Premier groupe français indépendant de recrutement spécialisé, le groupe FED est présent dans 4 pays avec 16 bureaux. Le groupe FED s’est spécialisé sur le recrutement pour douze secteurs d’activité, avec autant de cabinets spécialisés : RH, finance, supply chain, commerce & marketing, etc. Face à la croissance de son activité et de ses effectifs, la DSI du groupe a dû faire évoluer ses infrastructures IT, mais le choix d’un datacenter On premise a vite montré ses limites à accompagner la montée en charge. Afin de dimensionner son infrastructure au plus proche de ses besoins, et d’améliorer les performances, le groupe FED a choisi de migrer ses bureaux virtuels Citrix sur le Cloud AWS.

Vincent Caberas est Ingénieur Systèmes et Réseaux au sein du groupe FED depuis 5 ans. Il s’intéresse aux Systèmes informatiques au sens large, à la Virtualisation et aux Cloud et à la Sécurité. Issu de l’univers Windows, Vincent s’ouvre de plus en plus aux solutions Open Source. Il a supervisé la migration des infrastructures Citrix sur le Cloud AWS, et répond à nos questions sur ce passage sur le Cloud.

Peux-tu présenter le contexte de la migration vers AWS ?

Nous migrons l’ensemble de nos bureaux publiés Citrix vers AWS, soit 330 comptes utilisateurs. Historiquement, ces workloads étaient sur un datacenter on premise. En 2017, pour répondre à la montée en charge et l’ajout de nouveaux services, nous avons ouvert un second datacenter, pour lequel nous avons acheté de nouvelles baies et serveurs. Ceci devait nous permettre de répartir les charges, et également de répondre à la problématique du vieillissement des baies. Cependant, proposer des bureaux à distance demande beaucoup de ressources (CPU, RAM), et la forte croissance des effectifs a remis en question cette stratégie. Nous avions 46 serveurs Citrix sur deux clusters VM Ware, qui représentaient environ 60% de la charge. En cas de panne sur un des deux datacenters, il ne nous aurait pas été possible de revenir à 100%. Deux datacenters ne couvraient pas complètement les besoins, pour bien dimensionner et pouvoir répondre à tout incident, il aurait fallu multiplier les coûts par deux. Nous avons donc choisi de migrer la plus forte charge sur le Cloud public.

Nous avions également constaté que les performances se dégradaient, et que cela pouvait devenir pénalisant pour les utilisateurs. Pour maintenir les performances, il aurait fallu changer de baie et passer sur des disques SSD. Nous aurions pu choisir de continuer à amortir notre infrastructure on premise, mais ce serait courir le risque de l’alourdir à mesure qu’on ajoute des applications. La vie de l’entreprise fait que la charge va en augmentant, et le Cloud nous permet de répondre au plus proche à l’évolution de nos besoins.

Qu’est-ce qui a motivé le choix du Cloud AWS ?

Nous n’avons pas mené de benchmark complet sur les Cloud providers car notre équipe n’avait pas les ressources pour le faire, mais à ce moment AWS avait déjà une forte avance sur ses concurrents, confirmée par le Magic Quadrant Gartner. D2SI, avec qui nous avions déjà une relation de longue date, nous a fait découvrir le Cloud AWS via des travaux sur AWS. Nous avions besoin d’aller vite, donc choisir AWS s’est vite imposé comme une évidence. AWS était recommandé par D2SI, partenaire de confiance, et nous savions qu’ils avaient l’expertise et la capacité à nous accompagner sur ce projet.

Quel était le calendrier de la migration ?

Pour lancer le projet, nous avons commencé par réfléchir à notre stratégie Cloud à court et à long terme, ainsi que du choix de la première application à migrer. Nous devions également choisir une stratégie de migration, lift and shift, replatforming ou refactoring. C’est cette dernière option que nous avons choisie. Nous avons alors pu lancer un premier POC avant de préparer la migration.

Avec l’équipe D2SI, dans un premier temps nous avons fait la définition de cible, préparé la stack réseau, le découpage, les VPC, et travaillé sur les bonnes pratiques AWS. Pour rappel, à ce moment nous n’avions pas d’expérience préalable sur AWS. L’infrastructure as code était également un sujet nouveau, et même si je connaissais déjà la culture d’automatisation chez D2SI, il a fallu se former sur de nouveaux produits, notamment Terraform et Packer. Durant cette phase de build, nous avons donc bénéficié d’un transfert de compétences sur l’Infrastructure as Code. Puis nous avons fait toute la partie création d’images, c’est-à-dire l’automatisation des AMI buildées avec Chocolatey et Packer, et la création des templates. Enfin dans un troisième temps, nous avons buildé la stack complète. Après une phase pilote, la migration a été faite début mai.

Comment D2SI vous a aidé à monter en compétence ?

Nous avons eu deux journées de formation pour faire un premier tour d’horizon sur AWS et Terraform : comprendre la philosophie derrière l’IaC, la valeur ajoutée, commencer à manipuler des ressources… Puis nous avons eu un accompagnement tout au long du projet, durant lequel nous avons travaillé en mode shadowing. D2SI nous a apporté un code qui peut s’adaptant à n’importe quel contexte en le variabilisant. La mise en place a été rapide, cela m’a permis de prendre du temps pour comprendre comment le code est construit, comment fonctionne Terraform, comment D2SI l’utilise, et comment je peux l’utiliser. Aujourd’hui je suis plus autonome sur le sujet, j’ai compris le fonctionnement de la stack D2SI et je peux reproduire des serveurs pour répondre à d’autres besoins.

Qu’est-ce que D2SI vous a amené sur AWS ?

Nous avons pu découvrir toutes les bases du Cloud, comme de comprendre comment fonctionne la partie réseau sur le Cloud et quelles sont les différences avec un réseau d’entreprise. D2SI nous a également accompagné sur la mise en oeuvre des nouveaux services. Entre le démarrage du projet et la mise en oeuvre, le design établi 18 mois plus tôt n’était plus optimal avec l’arrivée de nouveaux services. Nous avions la possibilité de corriger le tir et d’intégrer ces nouveaux services avant la fin du projet, donc nous l’avons fait grâce à l’expertise de D2SI.

Plus spécifiquement, comment avez-vous travaillé sur la partie Windows sur AWS ?

Deux options sont possibles, soit faire du Windows en service managé, soit monter des instances EC2 avec des workloads Windows. C’est le choix que nous avons fait et cela fonctionne très bien, avec des images Windows. Concernant Citrix, nous avons les workers, et une partie stack core qui est sur des machines Windows. Cela fonctionne comme du RDS. Nous avons aussi une partie Windows uniquement que nous avons préféré héberger sur AWS : pour la migration de données, plus les données sont proches, mieux ça fonctionne. Nous avons donc buildé des Active Directory dans des machines EC2, réparties sur deux Availability Zone différentes.

Toujours dans l’idée de rapprocher les données, nous avons créé un serveur de fichiers (DFS) dans la même région que nos Workers Citrix, pour héberger nos data dans AWS et avoir une synchronisation avec notre filer On Premise.

Nous avions également besoin d’un serveur SQL en plus de celui on premise, et D2SI nous a aidé à monter ce second serveur en mirroring sur AWS. Nous avons fait la bascule pour en faire notre serveur primaire lors de la mise en production.

Actuellement nous utilisons des instances Windows dont le prix inclut la licence. A l’avenir, et afin d’optimiser nos coûts, nous utiliserons peut-être le “Bring you own licence” pour ne plus payer les instances avec le coût de la licence associée.

Quels sont les autres services AWS utilisés ?

Hormis les services les plus courants comme EC2, VPC, Direct Connect, Amazon S3 est le premier service AWS que nous avons utilisé. La mise en œuvre a été très simple, et l’apport de valeur ajoutée immédiat : le taux de disponibilité est de plus de 99%, et nous n’avons plus aucune limite de volume. S3 nous a permis de répondre à deux de nos problématiques très rapidement, et sans effort particulier, S3 étant utilisable avec la console AWS. Nous utilisons S3 pour stocker des fichiers issus de notre filer, ainsi que des données “froides” mais sensibles, pour répondre au besoin légal de conserver certains types de relevés. Nous avons donc un bucket S3 destiné à cet usage, et une policy qui transfère ces données dans Glacier après une certaine période, ceci afin d’optimiser les coûts.

Nous utilisons également Storage gateway pour les sauvegardes et l’archivage. D2SI nous a accompagné sur le démarrage de ce projet destiné à remplacer notre matériel à bande physique, pour passer à un backup plus moderne. Nous avions Veeam Backup, donc nous avons choisi d’utiliser Storage Gateway comme VTL sur notre infrastructure on premise, avec une sauvegarde envoyée sur Glacier une fois par mois.

Pour répondre à nos enjeux de sécurité, nous voulions avoir le même niveau de sécurité sur le Cloud et on premise, et donc avoir le même firewall. Pour ce faire, nous utilisons un nouveau service sorti en novembre 2018, Transit Gateway, qui nous permet d’interconnecter tous nos VPC en un point central vers le VPC qui héberge notre appliance Sonic Wall disponible sur le marketplace. Nous avons ainsi le même niveau de filtrage, mais cela règle aussi la problématique des sessions multi utilisateurs et des droits associés dans Citrix. Pour mettre en place notre Sonic Wall, nous avons créé un VPC dédié, et l’accès à Internet est fourni par une internet gateway.

Enfin, nous utilisons aussi Code Commit pour le stockage de l’Infrastructure as Code, ainsi que des services de monitoring comme Cloudwatch, Trusted Advisor et Cloudtrail.

Quel est ton retour personnel sur le Cloud ?

J’ai découvert un vrai terrain de jeu, où l’on peut tout faire ou presque, énormément de choses sont possibles. Il ne faut pas se perdre, parce que pour chaque besoin, on trouve un ou plusieurs services pour y répondre, donc il faut choisir en connaissance de cause. Ces services peuvent ensuite être combinés, comme dans un Lego on assemble ses pièces en fonction de ses objectifs et de ses besoins. L’un des nombreux avantages du Cloud est qu’on ne se pose plus la question de l’engagement sur un produit, de l’estimation de la puissance de calcul ou du volume de données. Il suffit de choisir l’outil pour sa réponse au besoin, et tout le reste est flexible : résilience, redondance, auto scaling, tout est là by design.

A l’échelle de l’entreprise, quel est votre retour ?

Nous avons choisi le Cloud essentiellement pour l’agilité qu’il apporte. Nous avions besoin de pouvoir tester des idées, de lancer des POC et de pouvoir estimer rapidement la faisabilité d’un projet, le temps et les moyens engagés. Le Cloud apporte cette possibilité d’expérimentation sans engager beaucoup de moyens. Lancer des projets sans devoir gérer un achat de matériel représente un énorme gain pour nous. A titre de comparaison, mettre en œuvre notre second datacenter nous a pris plus de deux mois. Le déploiement sur le Cloud est immédiat, et avec de nombreux services managés prêts à l’emploi, on peut être tout de suite efficace.

Quelle est votre relation avec D2SI ?

Nous travaillons depuis 2014 avec D2SI. Comme nous sommes une petite équipe, nous avons parfois besoin d’une expertise précise sur un sujet, et pouvoir lancer un run rapidement, et D2SI a toujours su répondre très exactement à nos besoins. Il y a eu une véritable montée en compétence générale grâce à l’accompagnement de D2SI. C’est D2SI qui nous a amené à l’automatisation, et leur démarche à ce sujet est une vraie force par rapport aux autres prestataires. Non seulement D2SI a les outils pour mettre en oeuvre cette démarche, mais ils arrivent également à bien transmettre leur savoir. La force de D2SI, c’est aussi que tous les consultants ont un socle commun; ils arrivent avec une bonne connaissance de notre contexte, on voit que l’information circule entre eux, et leur niveau technique est toujours très bon. Ce qui n’est pas toujours le cas avec d’autres prestataires, et c’est pour ces raisons que nous apprécions de travailler avec D2SI.