Il y a quelques années, nous avons été confrontés à un problème intéressant. Nous sommes une entreprise entièrement à distance et tous nos logiciels sont dans le nuage. Et nous avions une suite d'applications Spring Boot fonctionnant 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 pour de nouveaux produits. Nous devions trouver un moyen de conserver notre avance dans le secteur.

Nous sommes une entreprise technologique dotée d'une stratégie audacieuse

Sur 2022, nous avons créé un ADR (Architecture Decision Record) qui disait : "serverless-first et containers-as-need." Et a suscité un débat au sein de près de 40 équipes d'ingénieurs.

Expliquons d'abord quelques termes

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

  • Réduction des frais généraux opérationnels grâce à l'absence de gestion de l'infrastructure

  • Échelle selon les besoins, y compris l'échelle zéro pour les rendre totalement élastiques.

  • Avoir une tarification élastique (vous ne payez que ce que vous utilisez) 

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

Serverless-first signifie que lorsque nous sélectionnons une solution pour le calcul, le stockage, la messagerie ou autre, nous aimerions que les équipes commencent par une option sans serveur. Une remarque importante : si le service sans serveur ne répond pas au besoin, les équipes doivent se rabattre sur un service plus lourd - qui nécessite un investissement opérationnel plus important.

"Containers-as-need" clarifie le fait que serverless-first ne signifie pas serverless-only. Il arrive que nous ayons besoin de conteneurs (par exemple, pour installer un logiciel COTS), et c'est normal.

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

Nous agissons avec souplesse pour répondre aux besoins de nos clients et de nos utilisateurs. Des services comme Lambda, S3 et DynamoBD sont incroyablement résilients et rapides. En nous déchargeant des tâches lourdes et indifférenciées, nous pouvons consacrer plus de temps à l'élaboration de fonctionnalités pour les utilisateurs, plutôt qu'à la configuration d'infrastructures génériques.

L'un des principes clés de G-P est le suivant : "Vous le construisez, vous le dirigez." Nos équipes sont propriétaires de leurs logiciels. Nous ne nous contentons donc pas de confier un logiciel à une équipe DevOps. 

Avantages de l'approche "sans serveur" (serverless-first)

La technologie Serverless est intrinsèquement axée sur les événements.

Notre architecture est entièrement pilotée par les événements. En utilisant l'EDA (Event-Driven Architecture), nous pouvons faire évoluer à la fois notre organisation et notre logiciel. Serverless nous oblige à garder un petit rayon d'action et à communiquer d'une manière totalement cloud-native via des événements.

Contraintes d'habilitation

En tant que plateforme mondiale de l'emploi, nous prenons la conformité au sérieux. Notre infrastructure en nuage est bien conçue et nous utilisons une stratégie multi-compte qui sépare les charges de travail et automatise la conformité en nuage. Serverless nous aide à appliquer des normes élevées en contrôlant la manière dont nous approvisionnons les ressources du cloud.

Déchargez-vous du travail

Notre fournisseur de cloud gère nos services sans serveur. Un ensemble unique de blocs de construction - intégrés, sécurisés, réglés, activés et maintenus par AWS - nous permet de nous concentrer sur l'amont de la chaîne de valeur pour les clients.

Charges de travail bien architecturées

Chaque charge de travail que nous créons est examinée à l'aide du cadre AWS Well-Architected Framework. Nous nous concentrons sur l'échelle, la sécurité, la fiabilité et l'optimisation des coûts afin de garantir que nous ne nous contentons pas d'atteindre, mais que nous dépassons notre SLA (Service Level Agreement). Cela permet à nos équipes d'ingénieurs d'évoluer avec les environnements en nuage. 

A 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 l'architecture sans serveur n'est pas facile, et nous recherchons des ingénieurs qui sont à l'aise avec l'apprentissage, qui voient grand et qui évoluent à un rythme soutenu.

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 des fonctions. Notre stratégie nécessite une approche holistique des principes cloud-native classiques.

Le résultat

Nous avons accompli 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 manière dont nous avons structuré 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 le cadre AWS Well-Architected Framework pour examiner toutes les charges de travail. Comme nous utilisons de nombreux services gérés AWS, nous pouvons nous fier à leur excellence opérationnelle et partir d'un niveau de qualité élevé.

3. Penser en termes de système: Nous avons dû normaliser un grand nombre de nos processus afin de pouvoir raisonner sur le système, la fiabilité et la valeur commerciale. Nous ne perdons pas de temps à travailler sur des éléments de faible valeur.

4. Innovation: Sans serveur signifie que tout est une Interface de programmation. Cette contrainte impose une approche d'Interface de programmation d'abord. Lorsque nous nous considérons comme une plateforme, nous pouvons atteindre un nouveau niveau d'innovation en connectant facilement des systèmes via des Interfaces de programmation, comme le fait de connecter G-P Gia™ à une nouvelle base de Connaissance.

5. Propriété: AWS est propriétaire de notre infrastructure, mais nous sommes propriétaires de notre domaine d'activité. Serverless-first avec une conception axée sur le domaine nous a obligés à nous concentrer sur le problème de l'entreprise. Ainsi, la propriété des capacités reste claire.

Serverless-first 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 celle des développeurs individuels. L'approche "Serverless-first" consiste moins à utiliser des fonctions qu'à se dire que le code est un handicap. Le système est l'atout". 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, la vitesse à laquelle nous travaillons deviendra évidente, ce qui est un résultat direct de serverless-first. Restez à l'écoute.