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.
L’expression « conteneurs à la demande » précise que l’approche « sans serveur d’abord » ne signifie pas « exclusivement sans serveur ». Il arrive que nous ayons besoin de conteneurs (par exemple, pour installer un logiciel COTS) — et c'est tout à fait 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 d'embauche internationale, 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. L'architecture sans serveur nous aide à garantir des normes élevées en contrôlant la manière dont nous provisionnons les ressources 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 réalisé des progrès extraordinaires en deux ans. La modernisation présente de nombreux avantages (voir notre article sur le supplément de salaire annuel / 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 structuré notre système permet aux équipes et aux produits d'innover et d'évoluer indépendamment. Cela a un impact considérable sur l'agilité des entreprises.
2. Conformité: Nous utilisons le cadre Well-Architected du supplément de salaire annuel pour examiner toutes les charges de travail. Parce que nous utilisons de nombreux services de gestion de suppléments de salaire annuel, nous pouvons compter sur leur excellence opérationnelle et partir d'un niveau de qualité élevé.
3. Pensée systémique: Nous avons dû standardiser bon nombre de nos processus afin de pouvoir raisonner sur le système, sa fiabilité et sa valeur commerciale. Nous ne consacrons pas de temps à travailler sur des composants de faible valeur.
4. Innovation: Le sans serveur signifie que tout est une interface de programmation. Cette contrainte imposée nécessite une approche privilégiant l'interface de programmation. 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 intégrant G-P Gia™ à une nouvelle base de connaissances.
5. Propriété: supplément de salaire annuel est propriétaire de notre infrastructure, mais nous sommes propriétaires de notre domaine d'activité. L'approche « serverless first » associée à une conception axée sur le domaine nous a obligés à nous concentrer sur le problème métier. Cela permet de clarifier la propriété des capacités.
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.
