Dans la partie 2 de cette série , nous avons appliqué les concepts introduits pour la première fois dans la partie 1 et conçu une startup fictive de logiciel de rencontres en ligne appelée eTumble. Nous avons produit des « documents vivants » pour notre stratégie, notre conception et notre architecture. Le but de cet article est de tout rassembler et de planifier l'infrastructure nécessaire pour donner vie à notre idée et répondre à nos futurs besoins de mise à l'échelle.

Prérequis pour avancer

• Vous avez lu la partie 1 de la série
• Vous connaissez les frameworks/méthodologies que nous explorons ci-dessous en regardant au moins les liens vidéo partagés dans la partie 1
• Vous avez lu la partie 2 de la série

Sans écrire une seule ligne de code ni dépenser d'argent , nos exercices de "documents vivants" produits dans la partie 2 ont révélé les exigences système qui informent nos futurs besoins en infrastructure d'hébergement :

Nous n'avons pas besoin de satisfaire immédiatement tous les besoins "au-delà", mais en être conscients lors de la conception et de la construction de notre MVP peut aider à minimiser les reprises. Découvrons comment !

Portée initiale du MVP basée sur la story map et l'OGSM

eTumble se prépare à devenir la prochaine grande nouveauté en matière de rencontres en ligne. Notre équipe a judicieusement pris le temps d'effectuer une analyse SWOT, documenté notre plan stratégique de 3 à 5 ans à l'aide du cadre OGSM, visualisé et hiérarchisé notre MVP à l'aide de Story Mapping, et conçu et documenté notre architecture en utilisant des parties de la méthodologie du modèle C4.

Notre plan OGSM a identifié un objectif initial de 25 000 utilisateurs au cours de la première année et des tactiques pour atteindre notre objectif, telles qu'un programme de parrainage et des démonstrations sur les campus universitaires. Après plusieurs itérations de mappage d'histoires, nous avons défini notre portée MVP - et l'avons écrite .

Si nous avons sauté la planification stratégique pour identifier l'importance des promotions, nous n'avons peut-être pas assez itéré sur la carte de l'histoire pour choisir le MVP, ce qui aide à prioriser ce que nous construisons en premier. Encore plus effrayant, nous l'avons peut-être appelé "Mike's Match Maker" (ci-dessus) au lieu de notre nom plus cool, eTumble. ;-)

Mettre rapidement notre MVP entre les mains des utilisateurs prévus nous permettra de mieux comprendre le domaine du problème et, par conséquent, affectera les décisions au niveau stratégique et de l'idéation. C'est pourquoi nos plans sont appelés « documents évolutifs » et doivent être réitérés au fil du temps au fur et à mesure que nous apprenons.

Sélection de notre plateforme d'hébergement cloud

La sélection d'un fournisseur d'hébergement cloud peut devenir un exercice politique ou religieux au sein de n'importe quelle organisation ou équipe. Je préfère utiliser une approche basée sur les données pour ces décisions et j'ai décrit comment nous l'avons fait dans une entreprise précédente dans cette interview BrightTALK en 2020.

Dans les parties précédentes de cette série, j'ai échappé au fait que nous utiliserons Google Cloud Platform (GCP). Je vais donc expliquer brièvement mon approche typique.

J'ai orchestré ce processus dans d'anciennes organisations, et l'une d'entre elles avait une gamme de produits avec une stratégie axée sur le mobile. Mes raisons de choisir GCP découlent donc de mon expérience antérieure et du soutien de milliers d'entreprises chez DoiT. AWS Amplify est une solution concurrente, mais en deçà de GCP Firebase en utilisant de nombreux critères ci-dessus, en particulier la facilité d'utilisation.

Cet article va plus en détail en comparant les deux frameworks mobiles populaires, GCP Firebase contre AWS Amplify , mais il est derrière le paywall de Medium. Le consensus était que Firebase était plus complet, plus facile à utiliser et peut-être plus rentable.

Quelle que soit la plateforme que vous choisissez, nous avons identifié les exigences à court et à long terme de notre système. Supposons que nous ayons suivi le processus d'évaluation ci-dessus, sélectionné GCP pour diverses raisons et que nous devions maintenant concevoir notre infrastructure d'hébergement cloud.

Automatisation de nos déploiements de code source

Outre ses employés, le cœur de chaque startup logicielle est son code source - le texte structuré qui est converti en instructions qu'un ordinateur peut comprendre et traiter. Pour que nos programmes atteignent notre public cible (en supposant qu'il n'y ait pas de "Smokescreen MVP" à ce stade), ils doivent être déployés dans le ou les environnements d'hébergement que nous avons choisis.

L'une de nos stratégies pour eTumble est d'innover plus rapidement que les autres. Bien que cela puisse décrire de nombreux aspects d'un démarrage logiciel, nous nous concentrerons sur la vitesse du développeur et la vitesse à laquelle de nouvelles fonctionnalités (histoires d'utilisateurs) peuvent être réalisées par les utilisateurs finaux. Des études ont prouvé qu'il s'agissait d'un avantage concurrentiel, mais nous n'entrerons pas dans tous les détails des pipelines DevOps et DevSecOps et CI/CD dans cet article.

La façon dont cela se produit peut être une préférence personnelle de l'équipe de développement. De nombreux fournisseurs d'hébergement de code source (par exemple, Github.com, Gitlab.com ou Bitbucket.com) disposent désormais de leurs propres outils. Beaucoup proposent également des webhooks lorsque des événements se produisent qui déclenchent des solutions tierces. Chaque fournisseur d'hébergement cloud a également ses propres services, tels que Azure Dev Ops de Microsoft ou Cloud Build et Cloud Deploy de GCP.

Normalement, ma recommandation à la plupart des organisations est d'envisager la solution du fournisseur de cloud, au minimum pour la phase de « déploiement » de vos pipelines de construction, car elle élimine le besoin de partager des clés de compte de service à long terme (qui peuvent être compromises) avec un tiers. système. GCP propose une fédération d'identité de charge de travail qui vous permet d'attribuer des rôles IAM à une solution tierce sans partager de clés, ce qui est également une option.

Considérations relatives à la mise à l'échelle sur le cloud

Monolithe ou pas

Avouons-le, la plupart des startups logicielles qui réussissent aujourd'hui à l'échelle mondiale ont commencé comme une application monolithe à 3 niveaux. Il n'y a rien de mal avec les monolithes à un stade précoce. Le couplage minimise de nombreuses complexités techniques et, comme l'impliquent les « topologies d'équipe », ces décisions concernent souvent la charge cognitive de votre équipe . Avec un objectif de 25 000 utilisateurs au cours de notre première année et une concentration sur le campus universitaire, il s'agit d'une conception tout à fait acceptable pour ce qui est prévu dans notre MVP.

Le problème survient souvent lorsque vous commencez la mise à l'échelle. Ne craignez rien, cependant, car nous pouvons concevoir notre solution «rapide et sale» pour prendre en compte facilement notre future architecture de microservices.

Dans nos diagrammes d'architecture de modèle C4, nous avons identifié des "contrôleurs" dans la vue des composants, pour l'application "API Backend". Les lignes indiquant la publication de messages dans Pub/Sub, par exemple, pourraient initialement inclure la logique du microservice dans l'application API au niveau de la couche "Modèle" de l'architecture Model-View-Controller (MVC). Les routes de l' API restent les mêmes.

Lors de la prise en compte des microservices, nous pouvons déplacer la fonctionnalité "Modèle" de l'application API vers des services distincts et communiquer via HTTP/RPC ou une messagerie asynchrone. Si vous planifiez à l'avance, vous pouvez concevoir une couche wrapper pour les appels de fonction ou de méthode qui interagissent initialement avec une couche de données, et passer à des appels distants à l'avenir avec des modifications de code minimales.

Si vous avez conçu suffisamment de systèmes distribués, vous pouvez toutefois opter pour une architecture pilotée par les événements, comme illustré dans notre diagramme de conteneur.

Aller « sans serveur » ou utiliser des conteneurs

Au début de cette série en 3 parties, j'ai déclaré que les startups logicielles d'aujourd'hui ont un avantage sur celles d'il y a cinq à dix ans, en partie grâce aux fournisseurs de cloud hyperscale. Les produits sans serveur tels qu'AWS Lambda, Google Cloud Functions ou même Azure Functions en sont un excellent exemple. Les développeurs peuvent pousser leur code vers ces "environnements d'exécution" et bénéficier d'aucune maintenance de l'infrastructure et d'une mise à l'échelle automatique.

Bien que cela semble être l'approche évidente pour lancer votre MVP, soyez conscient du champ de mines de la dette technique que vous plantez en cours de route. Certains de ces services offrent un émulateur afin que vous puissiez créer et tester localement, ce qui aide à réduire la dépendance et le coût d'un autre environnement.

Je préfère tirer parti des solutions sans serveur pour les petits travaux asynchrones à usage unique qui sont déclenchés par des événements dans votre système tels que "fichier téléchargé ou modifié" ou "message publié".

Pour créer une API qui acheminera les demandes vers divers éléments principaux, une application conteneurisée peut être un choix plus judicieux. Étant donné que toutes les dépendances sont empaquetées dans l'image, les conteneurs simplifient le développement et les tests locaux. La plupart des fournisseurs d'hébergement cloud proposent une solution de conteneur "sans serveur" comme ECS sur AWS, et Cloud Run ou App Engine Flexible sur GCP.

Je préfère la portabilité des conteneurs pour les applications plus complexes et si vous suivez les principes de la méthodologie d'application à 12 facteurs , ils réduisent également le risque de dérive de la configuration dans différents environnements de votre pipeline CI/CD.

Priyanka Vergadia de Google fournit une collection de "notes de croquis" et ceci ci-dessous illustrant " Où dois-je exécuter mes affaires " est un guide utile.

Tirer parti des groupes de messagerie pour passer d'une à plusieurs équipes

Supposons que nous ayons commencé avec quelques personnes, mais que notre plan nécessite à terme de prendre en charge des dizaines de millions d'utilisateurs dans de nombreux pays. Nous allons sans aucun doute faire évoluer notre organisation pour inclure de nombreuses équipes et spécialistes (l'axe y et l'axe z de l'AKF Scale Cube s'appliquent également à notre organisation).

La meilleure pratique lors de la configuration de la gestion des identités et des accès (IAM) avec des plates-formes cloud consiste à attribuer des rôles à des groupes plutôt qu'à des utilisateurs individuels. Dans un article que j'ai écrit il y a quelques années sur la structuration des entreprises sur le cloud , j'explique les groupes initiaux recommandés et bien plus encore.

les groupes que nous créons à un stade précoce peuvent évoluer avec l'organisation (seuls les membres changent avec le temps)

Même si notre startup commence avec trois personnes, rien ne nous empêche de définir des groupes et d'ajouter des personnes à plusieurs d'entre eux pour commencer . Au fur et à mesure que nous embauchons plus de personnes, nous pouvons progressivement laisser les groupes aux spécialistes.

À l'échelle de l'entreprise, vous pourriez éventuellement diviser davantage les équipes en fonction des besoins et de la charge cognitive. Peu importe où vous commencez, la meilleure pratique consiste à attribuer des rôles Cloud IAM à des groupes, plutôt qu'à des utilisateurs individuels, pour faciliter leur maintenance et minimiser les retouches . Notez le modèle ici.

Concevoir votre hiérarchie de ressources cloud pour l'hébergement multiclient

Cette liste de contrôle de référence sécurisée GCP que j'ai rédigée il y a quelques années comprend un exemple illustratif de la conception des meilleures pratiques recommandées. Au fur et à mesure que nous concevons notre architecture cloud pour notre MVP, il peut y avoir du travail de "jeter" au début, mais j'ai quand même recommandé une structure similaire lors de la configuration de toute hiérarchie de ressources cloud.

Au fur et à mesure que l'organisation évolue, progressant vers des versions ultérieures du produit illustrées dans notre carte des histoires d'utilisateurs, nous pouvons passer à l'administration réseau centralisée, à la gestion des clusters Kubernetes et à la structure d'équipe multi-tenant. Cela déclenche souvent les démarrages de logiciels lorsqu'ils atteignent les points d'inflexion décrits dans la partie 1 de cette série.

il peut y avoir du travail "à jeter" au début

GCP a une excellente référence qui décrit comment établir une multilocation d'entreprise avec plus de détails. Vous trouverez ci-dessous une illustration de ce à quoi l'infrastructure cloud eTumble pourrait ressembler à l'avenir lorsque nous atteindrons nos objectifs Y2 et Y3 (en ignorant la vue des ressources pour la brièveté de l'article).

La clé à retenir ici est de remarquer que les projets initiaux de dossiers de services partagés ne changent jamais et que les groupes que nous avons créés à un stade précoce peuvent évoluer avec l'organisation (seuls les membres changent avec le temps). Chaque locataire (équipe) conserve ses ressources spécifiques telles que les bases de données et les secrets dans leurs projets respectifs, et est référencé à partir des applications conteneurisées déployées sur les clusters dans leurs espaces de noms respectifs.

Systèmes externes (authentification, paiements, e-mail, etc.)

Notre plan et nos conceptions ont illustré un besoin de systèmes externes tels que les e-mails transactionnels, les paiements en ligne et éventuellement l'identité et l'authentification. Lors de la sélection de fournisseurs de solutions externes, tenez compte des points suivants :

• plusieurs environnements pour les tests et la production avec une authentification distincte
• maintenir et faire pivoter les informations d'identification dans le magasin secret chiffré
• incitations commerciales disponibles à l'achat sur le marché

Félicitations pour être arrivé jusqu'ici ! Cette série en 3 parties vous emmène dans un voyage à partir de méthodologies et de cadres utiles, à la conception d'un démarrage logiciel à partir de zéro, et enfin à l'utilisation de "documents vivants" pour planifier l'infrastructure cloud pour les étapes précoces et ultérieures.

• Partie 1 : contexte et introduction à la méthodologie
• Partie 2 : mise en place de méthodologies avec startup fictive
• Partie 3 : concevoir et faire évoluer l'infrastructure cloud

J'ai hâte que vous preniez ces principes et que vous terminiez là où nous nous sommes arrêtés pour aider à résoudre la solitude à l'échelle planétaire . ;-)

Si vous pensez que cette série sera utile à d'autres, ne la gardez pas secrète. Donnez à chaque partie un peu d'"amour" et d'applaudissements, et partagez avec les autres. Merci d'avoir lu!