Nous avons eu un problème intéressant il y a quelques années. Nous sommes une entreprise entièrement distante avec tous nos logiciels dans le cloud. Et nous avions une suite d’applications Spring Boot exécutées sur des conteneurs avec Infrastructure as Code. Mais nous avions besoin d’agilité commerciale.

Le marché mondial de l’emploi évolue rapidement, et il y a toujours une demande de nouveaux produits. Nous avons dû trouver un moyen de garder notre avance dans l’ensemble du secteur.

Nous sommes une entreprise technologique avec une stratégie audacieuse

En 2022, nous avons créé un ADR (Architecture Decision Record) qui disait : « sans serveur en premier et conteneurs en fonction des besoins ». Et a suscité le débat entre près de 40 équipes d’ingénierie.

Commençons par expliquer une terminologie

Serverless-first n’est pas seulement des fonctions en tant que service. Il s’agit également d’un groupe de services gérés de fournisseurs de cloud qui : 

  • Réduire les frais d’exploitation en ne gérant pas l’infrastructure

  • Évoluez selon les besoins, y compris la mise à zéro pour les rendre entièrement élastiques

  • Avoir des prix élastiques (vous ne payez que ce que vous utilisez) 

Chez G-P, serverless-first fait référence à notre utilisation d’AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, API Gateway, S3, DynamoDB, etc.

« Serverless-first » signifie que lorsque nous sélectionnons une solution de calcul, de stockage, de messagerie ou similaire, nous aimerions que les équipes commencent par une option sans serveur. Remarque importante : si le service sans serveur ne répond pas au besoin, les équipes doivent retomber sur un service plus lourd, qui nécessite un investissement plus opérationnel.

« Conteneurs en fonction des besoins » précise que le sans serveur en premier ne signifie pas uniquement sans serveur. Il arrive que nous ayons besoin de conteneurs (par ex., installer un produit logiciel COTS), et ce n’est pas grave.

Une stratégie technologique qui donne la priorité aux clients

Nous évoluons à un rythme agile pour répondre aux besoins de nos clients et de nos utilisateurs. Les services tels que Lambda, S3 et DynamoBD sont incroyablement résilients et rapides. En déchargeant les charges lourdes indifférenciées, nous pouvons passer plus de temps à créer des fonctionnalités pour les utilisateurs, plutôt que de travailler sur la configuration d’infrastructure générique.

Un principe clé chez G-P est : « Vous le construisez, vous l’exécutez. » Nos équipes possèdent leur logiciel. Donc, nous ne nous contentons pas de lancer des logiciels sur le mur à une équipe DevOps. 

Avantages du « sans serveur avant tout »

Le sans serveur est intrinsèquement axé sur les événements.

Notre architecture est entièrement axée sur les événements. En utilisant EDA (Event-Driven Architecture), nous pouvons faire évoluer notre organisation et nos logiciels. Le sans serveur nous oblige à maintenir un petit rayon d’explosion et à communiquer de manière entièrement cloud native via des événements.

Contraintes d’activation

En tant que global employment platform , nous prenons la conformité au sérieux. Notre infrastructure cloud est bien conçue, et nous utilisons une stratégie multi-comptes qui sépare les charges de travail et automatise la conformité au cloud. Serverless nous aide à appliquer des normes élevées en contrôlant la façon dont nous fournissons les ressources cloud.

Décharger le travail

Notre fournisseur cloud gère nos services sans serveur. Un ensemble unique de blocs de construction — intégrés, sécurisés, ajustés, activés et entretenus par AWS — nous permet de nous concentrer plus haut sur la chaîne de valeur pour les clients.

Charges de travail bien conçues

Chaque charge de travail que nous créons est examinée avec AWS Well-Architected Framework. Nous nous concentrons sur l’échelle, la sécurité, la fiabilité et l’optimisation des coûts pour nous assurer non seulement de respecter, mais également de dépasser notre SLA (accord de niveau de service). Cela permet à nos équipes d’ingénierie de continuer à évoluer avec les environnements cloud. 

À propos de nos équipes

Notre stratégie technologique est ambitieuse, ce qui la rend difficile. De nombreux ingénieurs n’ont pas travaillé dans une architecture sans serveur (ou une architecture distribuée). La transition vers une architecture sans serveur n’est pas facile, et nous recherchons des ingénieurs qui sont à l’aise avec l’apprentissage, la pensée en grand et le rythme.

Certains ingénieurs ne sont pas sûrs du terme « serverless » (oui, nous savons qu’il y a des serveurs), car l’approche va au-delà de l’écriture de code dans les fonctions. Notre stratégie nécessite une approche holistique des principes classiques natifs du cloud.

Le résultat

Nous avons fait des progrès extraordinaires en deux ans. La modernisation présente de nombreux avantages (voir notre article sur AWS / la valeur commerciale connue de la modernisation du cloud). Plus précisément, nous avons observé ce qui suit :

1. Rapidité  : la façon dont nous avons divisé notre système permet aux équipes et aux produits d’innover et d’évoluer de manière indépendante. Cela a un impact considérable sur l’agilité de l’entreprise.

2. Conformité  : nous utilisons AWS Well-Architected Framework pour examiner toutes les charges de travail. Étant donné que nous utilisons de nombreux services gérés AWS, nous pouvons compter sur leur excellence opérationnelle et commencer à partir d’un endroit de haute qualité.

3. Pensée système  : nous avons dû normaliser un grand nombre de nos processus afin de pouvoir réfléchir au système, à la fiabilité et à la valeur commerciale. Nous ne passons pas de temps à travailler sur des composants de faible valeur.

4. Innovation  : Le sans serveur signifie que tout est une API. Cette contrainte forcée nécessite une approche axée sur l’API. Lorsque nous nous considérons comme une plateforme, nous pouvons atteindre un nouveau niveau d’innovation en connectant facilement les systèmes via des API, comme en branchant G-P Gia™ dans une nouvelle base de connaissances.

5. Propriété  : AWS est propriétaire de notre infrastructure, mais nous sommes propriétaires de notre domaine d’activité. Le sans serveur avec une conception axée sur le domaine nous a forcés à nous concentrer sur le problème commercial. Cela permet de garder la propriété de la capacité claire.

Le sans serveur n’est pas toujours plus rapide, mais il est plus bénéfique. Nous préférons optimiser la vitesse du système plutôt que la vitesse individuelle du développeur. Le sans serveur d’abord consiste moins à utiliser les fonctions que de penser : « Le code est une responsabilité. Le système est l’actif. » Moins nous avons de code à écrire, plus nous pouvons prendre en compte et modeler le système commercial que nous construisons.

Au fur et à mesure que nous partagerons notre histoire, il deviendra évident que la vitesse à laquelle nous travaillons, qui est un résultat direct de la priorité au sans serveur. Restez à l’écoute.