Série Evolutionary architectures, partie 4

Comment a été ce contenu ?

« Voulez-vous un café avec ça ? »

« Evolutionary Architectures » est une série de billets de blog en quatre parties qui illustre 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 troisième billet de blog décrivait comment la start-up avait commencé à faire évoluer son architecture vers une architecture incluant des outils tels que des pipelines CI/CD et une infrastructure sous forme de code, ainsi qu'à mettre en œuvre les bonnes pratiques, notamment en matière de sécurité et d'autorisation. Dans la quatrième partie, nous verrons Example Startup formaliser sa position en matière de sécurité et de sauvegarde afin de répondre à diverses normes de conformité. Elle définit également une stratégie de données pour l'organisation et explore d'autres secteurs d'activité afin de diversifier son portefeuille de produits.

Le financement de série B pour recruter, développer et se mettre à l'échelle

Tout se passe très bien pour Example Startup. Elle a récemment clôturé un cycle de financement de série B qui, selon elle, devrait permettre de recruter, de développer l'entreprise et de se mettre à l'échelle, ce dont elle a grandement besoin. Le financement et l'adoption par les clients se sont également accompagnés d'une concurrence accrue. Les acteurs bien établis du secteur commencent à la considérer comme un sérieux concurrent et intensifient leurs efforts de marketing.

Example Startup commence à recruter pour développer les domaines fonctionnels et créer des équipes dédiées à l'ingénierie de la fiabilité des sites (SRE), aux plateformes, à l'analytique et à la science des données. Compte tenu de la concurrence sur le marché du travail et de l'absence d'un service des ressources humaines dédié, la start-up contacte une fois de plus l'équipe chargée des comptes AWS pour savoir comment trouver des talents techniques maîtrisant AWS. Il s'avère que l'équipe chargée des comptes a déjà aidé d'autres start-ups clientes dans des situations similaires en leur suggérant des Partenaires AWS susceptibles de les aider à répondre à leurs besoins de recrutement. Rapidement, la start-up reçoit des e-mails de plusieurs candidats sélectionnés ayant de l'expérience avec AWS. Bien heureusement, de nombreux entretiens se transforment en offres d'emploi et la start-up est en mesure de rayer le recrutement de sa liste de tâches.

La frénésie de recrutement entraîne un problème technique : les équipes se plaignent du fait que l'équipe chargée de la plateforme d'Example Startup met trop de temps à créer de nouveaux comptes à des fins de test, ce qui freine l'innovation. L'équipe de la plateforme explique qu'elle n'a pas la bande passante nécessaire pour créer des comptes individuels chaque fois que quelqu'un a une nouvelle idée de fonctionnalité. À ce stade de son parcours AWS, l'équipe de la plateforme tient une réunion bihebdomadaire avec l'équipe chargée des comptes AWS et soulève ce dilemme. Le Solutions Architect (SA) d'AWS recommande de mettre en place une unité organisationnelle (UO) dédiée à un environnement de test (sandbox) au sein de son organisation AWS afin de fournir rapidement des ressources et des environnements temporaires aux autres équipes qui souhaitent tester de nouveaux services et fonctionnalités AWS. En outre, pour maîtriser les coûts, le SA recommande d'utiliser l'automatisation pour arrêter automatiquement les ressources telles que les instances Amazon EC2 en dehors des heures ouvrables normales. L'équipe de la plateforme d'Example Startup suit les conseils du SA. Elle est en mesure de créer rapidement des comptes pour les différentes équipes de la start-up, de manière contrôlée.

Par la suite, l'équipe SRE nouvellement recrutée se rend compte que la start-up peut être mieux positionnée du point de vue de la disponibilité et de la reprise après sinistre (DR). Elle reconnaît que la start-up connaît une croissance rapide et qu'à mesure qu'elle commence à cibler de plus en plus de clients, elle sera confrontée à des exigences de sécurité plus strictes, telles que des audits et des examens de conformité. Cela impliquait la nécessité de certains changements d'infrastructure. Heureusement, une grande partie du travail de reprise après sinistre a été accomplie lorsque Example Startup a modélisé son infrastructure dans Terraform et est passée à une architecture multicomptes dans la troisième partie de la série.

Dans un premier temps, l'équipe Example Startup se familiarise avec l'AWS Resilience Hub pour en savoir plus sur la création d'applications résilientes sur AWS. L'équipe ayant encore quelques questions en suspens, elle contacte l'équipe chargée des comptes AWS, qui lui présente un SA spécialisé en matière de résilience. Le SA travaille avec Example Startup pour spécifier ses exigences en matière d'objectif de délai de reprise (RTO) et d'objectif de point de reprise (RPO) et effectuer une analyse coûts-avantages de différents scénarios de reprise après sinistre. Après quelques appels avec le SA et de nombreuses délibérations internes, l'équipe de SRE décide que ses exigences en matière de RTO/RPO ne nécessitent pas encore une configuration multirégionale. Elle prend la décision de transférer ses données transactionnelles d'Amazon RDS for PostgreSQL vers Amazon Aurora for PostgreSQL, principalement pour la plus grande disponibilité que cela offre ainsi que pour les fonctionnalités d'Amazon Aurora Global Database qui sont importantes pour la base de données de production. La start-up utilise également AWS Audit Manager pour évaluer son respect des normes de conformité pertinentes pour le prochain audit. Sa fonctionnalité automatisée de collecte de preuves lui permet d'économiser beaucoup d'efforts manuels.

Élaboration d'une meilleure expérience client

Après avoir examiné les retours de divers clients sur les produits, le Chief Technology Officer (CTO) se rend compte que les fonctionnalités de tableau de bord proposées aux traders dans l'application de négociation d'Example Startup font défaut. Les concurrents permettent aux utilisateurs de voir facilement une représentation visuelle de l'historique et des performances des transactions (par rapport aux autres traders) au niveau de chaque transaction. Le CTO a indiqué qu'il s'agissait d'une lacune fonctionnelle critique et le travail a été confié à la nouvelle équipe d'analytique. En outre, le CTO souhaite que l'équipe permette aux traders de générer des rapports de négociation à leur guise.

L'équipe d'analytique a déjà utilisé Amazon Quicksight, de sorte que le composant du tableau de bord sera facile à améliorer, y compris une fonctionnalité de détection des anomalies pour aider les traders à trouver des transactions spécifiques qui se démarquent. La demande de rapports est plus complexe, car elle ne veut pas déranger les équipes de développement en exécutant ces rapports sur la base de données de production (cela ne serait pas considéré comme une bonne pratique). Après avoir consulté le livre blanc sur l'architecture moderne des données sur AWS, l'équipe d'analytique se rend compte que le meilleur moyen d'y parvenir est de charger les données Amazon RDS for PostgreSQL dans Amazon Redshift, un entrepôt de données. En utilisant le parallélisme massif d'Amazon Redshift, elle sera en mesure d'exécuter des agrégations complexes à partir de ces données transactionnelles avec une latence bien moindre et avec l'avantage supplémentaire de ne pas engorger la base de données de production. L'équipe d'analytique est heureuse de découvrir qu'Amazon Redshift étant basé sur le moteur PostgreSQL, elle peut réutiliser la plupart de ses requêtes.

Ajouter un nouveau secteur d'activité à la start-up

Au fur et à mesure que tous ces changements se produisent, la Chief Executive Officer (CEO) assiste à une réunion avec l'un de ses anciens collègues d'une grande société commerciale. Elle apprend qu'il y a une pénurie de traders efficaces sur le marché, ce qui a une incidence négative sur le portefeuille de recrutement de la société commerciale et ses projets futurs. La CEO appelle quelques-uns de ses amis travaillant dans des sociétés commerciales qui confirment qu'il s'agit d'une pénurie à l'échelle du secteur. Elle commence à se faire une idée : Example Startup compte de nombreux traders performants. Et si Example Startup offrait à ses traders une sorte de formation par cohorte, qui alimenterait ensuite le vivier de talents de ces sociétés commerciales ? Cela donnerait aux traders une chance d'entrer sur le marché du travail et les sociétés commerciales disposeraient de nouveaux talents.

Étant donné qu'une partie essentielle de la formation consisterait à recommander les bonnes transactions aux nouveaux stagiaires, la CEO organise un appel avec l'équipe de science des données pour savoir à quelle vitesse elle peut créer un modèle de machine learning (ML). Heureusement, certains membres de l'équipe de science des données ont déjà développé, entraîné et déployé des modèles avec Amazon Sagemaker. Amazon Redshift étant l'une des sources de données disponibles pour SageMaker, l'équipe de science des données n'aura pas à configurer un pipeline complexe d'extraction, transformation et chargement (ETL). Les membres de l'équipe de science des données qui ont moins d'expérience avec SageMaker ont été invités à une journée d'immersion axée sur SageMaker par l'équipe chargée des comptes AWS afin de rapidement améliorer leurs compétences. Rapidement, ils ont eux aussi commencé à créer des tâches d'entraînement, à créer des modèles précis et à les déployer sur les points de terminaison. Anticipant l'appel de l'équipe financière d'Example Startup concernant l'augmentation des coûts de calcul, l'équipe de science des données a effectué quelques recherches et a découvert qu'elle pouvait réellement exécuter ses tâches d'entraînement (qui représentent environ 80 % de ses coûts totaux) sur des instances Spot. Ce faisant, elle a pu réduire ses coûts de manière significative.

Alors que la nouvelle de cette initiative de développement des talents, en tant que nouvelle branche d'activité et source de revenus, se répand dans le secteur, de plus en plus de sociétés de capital-risque (VC) ont commencé à s'intéresser à Example Startup, avant même que la start-up ne fasse part de son intention de lancer une nouvelle levée de fonds.

Quelques trimestres plus tard, grâce aux efforts de marketing, aux efforts de co-marketing avec AWS et au bouche-à-oreille de clients existants, l'initiative de développement des talents d'Example Startup s'est rapidement développée. Aussi passionnant que soit l'augmentation de la clientèle, le fait que la start-up soit, pour la première fois depuis sa création, dans le vert, est encore plus enthousiasmant. Le recrutement s'avère être une activité rentable pour la start-up et elle se développe de jour en jour. L'équipe de direction est consciente que ce flux de rentabilité constant pourrait alimenter le reste de son activité. Elle travaille avec diligence sur de nouveaux plans d'expansion et d'innovation, enthousiasmée par l'incroyable avenir qui l'attend.

Récapitulatif

Au cours de cette série en quatre parties, Example Startup passe par les principales étapes d'une start-up, de sa naissance à sa maturité. La plupart des start-ups démarrent avec à peine plus qu'une idée audacieuse et une équipe fondatrice dévouée. Elle élabore un produit minimum viable (MVP) avec une infrastructure sans serveur qui lui permet de tester son idée d'une manière que l'équipe fondatrice puisse gérer elle-même.

Au fur et à mesure que la start-up acquiert des clients payants et obtient un financement post-seed, elle passe à la phase « être sur la bonne voie », dans laquelle son architecture évolue et elle commence à réfléchir sérieusement à la mise à l'échelle, à la sécurité et à l'agilité de développement. Cela implique des améliorations telles que l'utilisation d'outils de création et la mise en place de bases de données de surveillance et sur mesure.

L'une des leçons les plus importantes à tirer de ces étapes est de communiquer avec l'équipe AWS dès le début et souvent, avant même de démarrer des projets, afin de l'aider à évaluer les options et à gagner du temps. L'accès à des ressources métier et techniques peut accélérer les délais et aider les équipes de start-ups en phase de démarrage à atteindre leurs objectifs.

Après la phase d'adaptation produit-marché, les start-ups peuvent commencer à recruter davantage et à se concentrer principalement sur la mise à l'échelle, c'est-à-dire la phase « jusqu'à la Lune ». À ce stade, elle commence à envisager une stratégie multicomptes, une architecture orientée service, la mise en cache et d'autres modifications architecturales pour optimiser son application et améliorer l'expérience client d'un point de vue technique.

Enfin, elle entre dans la phase d'hyperdimensionnement où elle peut commencer à recruter de manière intensive et développer de nouveaux secteurs d'activité. D'un point de vue technique, la start-up a investi beaucoup de temps et d'efforts d'ingénierie dans l'amélioration de la sécurité, des contrôles et des autorisations pour son environnement. Elle dispose probablement d'une version codifiée de son environnement dont elle peut tirer parti pour une expansion internationale rapide et une reprise après sinistre, entre autres cas d'utilisation. L'entreprise a également élaboré une stratégie en matière de données et est en train d'utiliser l'analytique et le machine learning pour mieux comprendre ses clients et son activité. Cette phase finale peut varier. Certaines start-ups seront sur la voie d'une acquisition, tandis que d'autres rechercheront peut-être la rentabilité et la domination du marché.

Vous souhaitez lancer votre parcours de start-up ? Rejoignez AWS Activate pour créer et développer votre start-up avec les bonnes ressources au bon moment.

Consultez l'intégralité de la série Evolutionary Architectures :

Aayzed Tanweer

Aayzed Tanweer

Aayzed est architecte de solutions chez AWS et travaille avec des startups dans l'espace FinTech, plus particulièrement sur les services d'analyse. Originaire de Toronto, il s'est récemment installé à New York, où il aime manger à sa façon et explorer les nombreux coins et recoins de la ville.

Justin Plock

Justin Plock

Justin est architecte de solutions principal chez AWS et est spécialisé dans les startups de la fintech. Il rencontre régulièrement les fondateurs de fintech pour s'assurer que leur activité est sécurisée et conforme aux réglementations du secteur. Avant de rejoindre AWS, il était directeur de la mise en œuvre du cloud dans une compagnie d'assurance du Fortune 200 et directeur de l'ingénierie dans une société de cybersécurité. Il a à cœur d'aider les startups à se développer efficacement et en toute sécurité sur AWS. Il vit dans le Connecticut avec sa femme et ses deux filles.

Zoran Nakev

Zoran Nakev

Zoran est architecte de solutions senior chez AWS. Il travaille principalement avec des startups FinTech et les aide à créer des solutions sur la plateforme AWS. Il utilise son expérience et sa passion pour la technologie pour aider les startups à atteindre leurs objectifs. Il vit dans le New Jersey avec sa famille et aime passer son temps libre à regarder des films, à écouter de la musique et à faire de longues promenades avec son chien.

Comment a été ce contenu ?