Série Evolutionary architectures, partie 3

« Vers la Lune 🚀 »

« Evolutionary Architectures » est une série de billets de blog en quatre parties qui montre comment la conception des solutions et les décisions évoluent au fur et à mesure que les entreprises traversent les différentes étapes du cycle de vie d'une start-up. Dans cette série, nous suivons la bien nommée Example Startup dont l'idée est de créer une application de « bourse fantasy », similaire aux ligues sportives fantasy. L'entreprise envisage d'organiser quatre « tournois » au cours d'une année.

Le deuxième billet de blog décrivait comment la start-up avait commencé à faire évoluer ses solutions techniques alors que les fondateurs se préparaient à lever des fonds. Dans la troisième partie, nous verrons comment Example Startup continue de faire évoluer sa pile technologique et de bien se positionner pour la mise à l'échelle.

Mise à l'échelle efficace grâce à la transition vers une architecture de microservices

L'équipe de transactions boursières fantasy s'agrandit et de nouveaux composants et solutions sont en cours de création. Au fur et à mesure que le portefeuille technique s'élargit, certaine problèmes commencent à apparaître et nécessitent l'attention de l'équipe.

« Les vieilles habitudes ont la vie dure », et l'équipe commence à comprendre en quoi cela peut nuire à la croissance de leur start-up : les délais serrés et l'envie d'en faire plus avec moins entraînent une augmentation de la dette technique. L'un des aspects de cette dette technique est la prolifération progressive de monolithes, par opposition à l'architecture de microservices que l'équipe avait initialement choisie. Les problèmes liés au monolithe, tels que la capacité de mise à l'échelle et les goulots d'étranglement des performances, commencent à apparaître lors des tests et de l'introduction de nouvelles fonctionnalités. Heureusement, l'équipe reconnaît rapidement les défis que cette approche monolithique pose pour une mise à l'échelle optimale des charges de travail. Elle décide de prendre du recul et de réévaluer ses pratiques de développement. L'un des développeurs se souvient que le Solutions Architect (SA) AWS avait anticipé certains de ces problèmes lors d'une conversation précédente. L'équipe d'Example Startup planifie un appel avec AWS pour obtenir de l'aide.

La suppression des monolithes et la transition vers un paradigme basé sur les microservices étant un sujet vaste, le SA d'AWS recommande d'organiser une journée d'immersion sur la modernisation des applications à l'intention de l'équipe d'Example Startup. La journée d'immersion prend la forme d'un atelier connexe mettant l'accent sur les charges de travail relatives aux start-ups. Presque tous les développeurs de l'entreprise assistent à l'événement, qui finit par changer la donne. Au cours d'une seule journée, l'équipe est en mesure d'apprendre à définir, concevoir et implémenter correctement les microservices. Elle apprend également à tracer un chemin de migration progressif d'une application monolithique vers un ensemble de microservices sans avoir à tout refaire en même temps. L'équipe est heureuse de constater ses erreurs très tôt et d'avoir découvert les bonnes pratiques qui l'aideront à progresser. Le Solutions Architect partage également un livre blanc AWS axé sur les stratégies de modernisation susceptibles de combler les lacunes en matière de connaissances au sein de l'équipe d'Example Startup.

L'expérience de la modernisation des applications apporte une telle valeur à Example Startup que l'équipe décide d'appliquer la même approche en tirant parti des bonnes pratiques existantes dans différents domaines fonctionnels à l'avenir. Les ingénieurs et le chef de produit planifient un appel téléphonique pour partager leur feuille de route avec AWS pour le reste de l'année, afin d'éviter les doublons. Example Startup a déjà signé un accord mutuel de non-divulgation avec AWS et cette conversation a donné lieu à une libre circulation productive des idées entre les deux parties, ainsi qu'à une bonne nouvelle : il s'avère qu'une fonctionnalité qu'Example Startup envisageait de développer elle-même figure déjà sur la feuille de route d'AWS pour le trimestre suivant, ce qui libère une partie du temps d'ingénierie de l'équipe.

Le sujet suivant dans la liste des domaines à améliorer d'Example Startup concerne l'infrastructure en tant que code (IaC), l'intégration et la livraison continues (CI/CD) et les tests automatisés. Deux responsables des opérations de développement (DevOps) récemment embauchés ne sont pas satisfaits de la plupart des mécanismes opérationnels actuels de la start-up, en particulier les environnements de création et de tests, ainsi que la gestion des artefacts de code. La croissance de l'équipe d'Example Startup signifie que davantage de personnes ont accès à ces processus sensibles, introduisant ainsi des risques inutiles. Les deux nouveaux membres de l'équipe ont déjà une certaine expérience de Terraform en tant qu'approche de l'IaC. Ils sont heureux d'apprendre qu'AWS est bien prise en charge par Terraform et de découvrir d'autres outils tels qu'AWS CloudFormation et AWS CDK au cas où une alternative serait nécessaire. Cependant, ils ont encore besoin d'aide pour configurer leur CI/CD. Leurs tentatives manquent de cohésion et il s'avère difficile de bien faire fonctionner leur outil de construction avec leur outil de déploiement. En outre, ils sont toujours à la recherche d'une approche appropriée pour gérer leurs images de conteneurs. L'équipe AWS recommande AWS CodePipeline, car il répond à leurs besoins en matière d'intégration fluide d'un outil de création et d'un outil de déploiement et inclut également des tests automatisés, le tout associé à la prise en charge de divers environnements. L'utilisation de CodePipeline permet l'intégration à des solutions qui n'ont pas nécessairement été créées nativement sur AWS, ainsi qu'une prise en charge robuste d'autres outils tels qu'AWS CodeBuild, AWS CodeDeploy et des outils tiers. L'implémentation de CodePipeline permet à Example Startup de cocher un autre élément important de sa liste.

L'équipe étant sur la bonne voie pour mettre en œuvre correctement les microservices, elle se sent habilitée à relever certains des autres défis complexes restants. D'une part, la présence de plusieurs services fonctionnant indépendamment soulève naturellement la question de la communication entre ces services. Chaque appel interservices doit-il être synchrone ou asynchrone en matière de communication ? Comment l'équipe peut-elle commencer à adopter des modèles de bonnes pratiques tels que la messagerie par publication/abonnement (PubSub) ? L'équipe est généralement consciente que l'adoption d'une architecture ortientée événements serait bénéfique, en particulier avec l'abandon des monolithes, mais elle est un peu dépassée par la gamme infinie de services AWS liés à cette architecture, notamment Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS) et Amazon Managed Streaming for Apache Kafka (Amazon MSK). Cette fois-ci, l'équipe est en mesure de trouver elle-même certaines ressources qui constituent un excellent point de départ, telles que des ateliers et des blogs très utiles sur le sujet. Le paradigme « orienté événements » devient peu à peu un outil supplémentaire pour l'équipe.

Élaboration d'une stratégie de sécurité renforcée

La sécurité est restée une priorité pour notre start-up et des outils tels qu'AWS Startup Security Baseline (AWS SSB) l'aident à démarrer. Malheureusement, il n'est jamais possible d'avoir trop de sécurité. La mise en œuvre initiale d'AWS WAF était un bon début, mais l'équipe doit commencer à réfléchir de manière plus proactive à la prévention, à la détection et à la correction. Elle commence à se perfectionner sur les nombreux services AWS axés sur la sécurité qui peuvent l'aider à mettre en œuvre une stratégie de sécurité solide.

L'équipe en pleine expansion et l'implication des partenaires font du contrôle d'accès, des autorisations et de la gouvernance d'autres sujets qui nécessitent une attention croissante. L'équipe essaie de mettre en œuvre les bonnes pratiques, telles que le principe du moindre privilège lors de l'application des autorisations. Au minimum, elle souhaite transférer les charges de travail de production sur ses propres comptes séparés. Au fur et à mesure que l'équipe adopte ces bonnes pratiques, elle constate une complexité opérationnelle croissante en raison des niveaux supplémentaires de gestion et d'autorisations qu'elle doit désormais gérer. Il devient rapidement évident qu'elle a besoin d'une approche mécanisée de la structure des comptes. Quelqu'un mentionne AWS Organizations, ce qui semble être un pas dans la bonne direction. Elle contacte donc son fidèle SA d'AWS pour en discuter. Le SA donne quelques conseils pertinents, notamment en envisageant AWS Control Tower comme une approche plus simple pour gérer plusieurs comptes et AWS Organizations. Comme il s'agit de la première d'une longue série d'étapes vers la mise en place d'une stratégie multicomptes robuste, le SA d'AWS a également partagé avec l'équipe les directives prescriptives de « transition vers plusieurs comptes AWS ». Ce guide inclut les bonnes pratiques en matière de migration de comptes, de gestion des utilisateurs, de mise en réseau, de sécurité et d'architecture lors du passage à une configuration de multi-comptes.

Optimisation des charges de travail pour améliorer les performances

L'équipe s'attaque à certains éléments fondamentaux afin que la start-up soit bien placée pour se développer au bon rythme. Quelques points importants sont rayés de la liste et des plans d'action sont mis en place pour d'autres. Les développeurs font tout ce qui est en leur pouvoir pour optimiser les performances de leurs charges de travail, mais ils ont identifié certaines opportunités d'amélioration qui vont au-delà du code, telles que la mise en cache périphérique avec Amazon CloudFront, la mise en cache au niveau des applications avec Amazon ElastiCache et la mise en cache de base de données. L'équipe s'appuie de plus en plus sur AWS Managed Services pour lui fournir les fonctionnalités dont elle a besoin tout en minimisant la complexité opérationnelle associée. AWS Batch est un autre service géré que certains développeurs découvrent et trouvent étonnamment facile à utiliser. L'approche initiale de traitement des flux avec AWS Lambda commence à atteindre ses limites en raison de l'augmentation exponentielle du volume de données à traiter. Après quelques essais, les développeurs sont en mesure de tracer la voie à suivre pour utiliser AWS Batch, ce qui leur permet de poursuivre leur croissance avec une charge opérationnelle relativement faible et tout en maintenant les coûts à un faible niveau.

Prouver la proposition de valeur de la start-up

Tout ce bon travail chez Example Startup ne passe pas inaperçu. Construire de manière agile mais durable, sans recourir à des solutions de contournement à court terme, montre que l'entreprise pense au long terme, fait preuve de maturité et est en mesure de tenir ses promesses. Ces caractéristiques, associées à une solution innovante et à une bonne adéquation produit-marché, sont au cœur de la proposition de valeur de l'entreprise. Les fondateurs ont réussi à transmettre la valeur de leur entreprise à différentes sociétés de capital-risque et clôturent leur premier cycle de financement de série A. Exemple La startup est en route pour la Lune.

Consultez les premier et deuxième billets de blog de la série Evolutionary Architectures.