De nombreuses leçons que vous apprenez dans les grandes entreprises ne sont pas directement applicables à la première pile d’une start-up. Dans la phase d’exploration initiale d’un produit, vous devez optimiser le déploiement pour la vitesse, le coût et l’optionalité. L’optionalité fait référence à la rapidité avec laquelle vous pouvez changer de direction au sein d’une architecture donnée.
Une entreprise dans les phases de développement ou d’extraction du développement de produit peut utiliser une architecture orientée services ou microservices. Ce type d’architecture de déploiement est rarement adapté pour une start-up qui n’a pas encore trouvé le bon ajustement produit/marché ou la traction commerciale.
Pour une pile de démarrage de base, le mieux est une conception monolithique simple. Cette conception limite le temps consacré à la gestion de l’infrastructure, tout en fournissant une capacité de mise à l’échelle importante à mesure que la start-up gagne davantage de clients.
Cas d’usage potentiels
Cet article présente un exemple de pile de démarrage simple et décrit ses composants.
Architecture
Une start-up, Contoso, a créé un prototype d’application avec un back-end Ruby on Rails et un front-end React écrit en TypeScript. L’équipe Contoso a effectué des démonstrations sur ses ordinateurs portables. À présent, elle veut déployer son application pour ses premières rencontres commerciales avec des clients.
Si l’application est ambitieuse, elle n’a pas encore besoin d’une architecture complexe basée sur des microservices. Contoso a opté pour une conception monolithique simple qui inclut les composants recommandés pour une pile de démarrage.
Téléchargez un fichier Visio de cette architecture.
Dataflow
Dans l’architecture de cette pile de démarrage de base :
- Azure App Service fournit un serveur d’applications simple pour déployer des applications évolutives sans avoir à configurer des serveurs, des équilibreurs de charge ou une autre infrastructure.
- Azure Database pour PostgreSQL est un service de base de données Azure pour un système de gestion de base de données relationnelle (SGBDR) open source très répandu. Vous pouvez vous concentrer sur le développement de votre application plutôt que sur la gestion des serveurs de base de données.
- Réseau virtuel Azure segmente le trafic réseau et protège les services internes des menaces Internet. Vos serveurs d’applications utilisent l’intégration de réseau virtuel pour communiquer avec la base de données sans exposition à Internet.
- GitHub Actions crée une intégration continue et un déploiement continu (CI/CD) dans la gestion de votre code source. GitHub Actions offre une prise en charge étendue de différents langages et une forte intégration aux services Azure.
- Stockage Blob Azure stocke des ressources statiques et enlève la charge aux serveurs d’applications.
- Azure Content Delivery Network (CDN) accélère la distribution de contenu aux utilisateurs via un réseau mondial.
- Azure Monitor supervise et analyse ce qui se passe dans l’infrastructure de votre application.
Composants de la pile de démarrage de base
Une pile complexe peut générer des bogues qui nécessitent une attention constante. Une architecture sophistiquée peut nuire à la création de votre produit. Les bogues ne sont pas provoqués par la complexité, mais une pile complexe facilite l’apparition des bogues. Toutes les architectures sophistiquées ne représentent pas un gaspillage d’énergie, mais elles gaspillent vos ressources si vous n’avez pas encore trouvé l’ajustement produit/marché. Votre première pile de démarrage doit être simple et ne pas être un souci, pour vous permettre de vous concentrer sur le développement du produit.
Le diagramme simple suivant montre la pile de démarrage de base recommandée. Ces composants sont suffisants pour faire exister votre produit et le mettre dans les mains de vos clients. Pour 80 % des start-ups, cette pile est tout ce dont elles ont besoin pour tester les bases intégrées à votre produit. Les start-ups travaillant dans le machine learning, l’Internet des objets (IoT) ou des environnements fortement réglementés peuvent nécessiter plus de composants.
CDN
Avec peu de clients au début, un CDN peut sembler prématuré. Cependant, l’ajout d’un CDN à un produit déjà en production peut avoir des effets secondaires inattendus. Il est préférable d’implémenter un CDN à l’avance. Un CDN met en cache le contenu statique plus près de vos clients et fournit une façade derrière laquelle vous pouvez itérer sur vos API et votre architecture.
App Server
Votre code doit s’exécuter quelque part. Dans l’idéal, cette plateforme doit faciliter les déploiements, tout en nécessitant le moins d’entrées opérationnelles possible. Le serveur d’applications doit être mis à l’échelle horizontalement, mais une intervention manuelle de mise à l’échelle est acceptable tant que vous en êtes toujours à la phase d’exploration.
Comme la plus grande partie de cette pile, le serveur d’applications doit s’exécuter principalement de façon autonome. Traditionnellement, le serveur d’applications était une machine virtuelle ou une instance de serveur web s’exécutant sur un serveur nu. À présent, vous pouvez vous tourner vers des options PaaS (Platform-as-a-Service) et des conteneurs pour supprimer la surcharge opérationnelle.
Contenu statique
Distribuer du contenu statique à partir de votre serveur d’applications gaspille des ressources. Une fois que vous avez configuré un pipeline CI/CD, le travail de création et de déploiement des ressources statiques avec chaque version est trivial. La plupart des frameworks web de production déploient les ressources statiques avec CI/CD : il est donc judicieux de commencer par s’aligner sur cette bonne pratique.
Base de données
Une fois que votre application fonctionne, vous devez stocker vos données dans une base de données. Dans la plupart des cas, une base de données relationnelle est la meilleure solution. Une base de données relationnelle a plusieurs méthodes d’accès et la rapidité d’une solution testée dans le temps. Azure SQL Database, Azure Database pour PostgreSQL et Azure Database for MariaDB sont des bases de données relationnelles. Certains cas d’usage ont besoin d’une base de données de documents ou d’une base de données NoSQL, comme MongoDB ou Azure Cosmos DB.
Agrégation des journaux
En cas de problème avec votre application, vous devez consacrer le moins de temps possible au diagnostic du problème. En agrégeant les journaux et en utilisant le suivi d’application depuis le début, vous aidez votre équipe à se concentrer sur les problèmes eux-mêmes. Vous n’avez pas besoin d’accéder à un fichier sur le serveur d’applications et à examiner attentivement des journaux pour obtenir des données de monitoring.
CI/CD
L’absence de déploiements reproductibles et rapides est un des pires obstacles à la rapidité quand vous itérez sur un produit. Un pipeline CI/CD bien configuré rationalise le processus de déploiement du code sur votre serveur d’applications. Des déploiements rapides et simples signifient que vous voyez rapidement les résultats de votre travail. Une intégration fréquente évite les bases de code divergentes qui entraînent des conflits de fusion.
Déployer ce scénario
Les concepts et les techniques sont les mêmes pour la plupart des projets que vous créez en utilisant un Dockerfile.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Andrew Harvey | CTO et porte-parole de start-up