Principes de base de la conception système

Last reviewed 2024-05-30 UTC

Ce document du framework d'architecture Google Cloud décrit les principes de base de la conception système. Une conception système robuste est sécurisée, fiable, évolutive et indépendante. Vous pouvez ainsi apporter des modifications itératives et réversibles sans provoquer d'interruption du système, réduire les risques potentiels et améliorer l'efficacité opérationnelle. Nous vous recommandons de suivre quatre principes fondamentaux afin de tendre vers une conception système robuste.

Concevoir en vue d'évoluer

Aucun système n'est statique. Les besoins de ses utilisateurs, les objectifs de l'équipe qui élabore le système et le système lui-même évoluent constamment. En gardant à l'esprit le besoin de changement, élaborez un chemin de production qui permette aux équipes de fournir régulièrement de petites modifications et d'obtenir un retour d'information rapide sur ces changements. Démontrer en permanence la capacité à déployer des modifications est un moyen d'instaurer la confiance avec les personnes concernées, y compris les équipes responsables et les utilisateurs du système. L'utilisation du service Software Delivery Metrics de DORA peut aider votre équipe à surveiller la rapidité, la facilité et la sécurité des modifications apportées au système.

Tout documenter

La documentation est un élément fondamental du développement de logiciels. L'analyse de DORA a révélé un lien évident entre la qualité de la documentation et les performances organisationnelles, c'est-à-dire la capacité de l'entreprise à atteindre ses objectifs de performance et de rentabilité.

Lorsque vous commencez à déplacer vos charges de travail vers le cloud ou à créer vos applications, le manque de documentation du système constitue un obstacle majeur. La documentation est particulièrement importante pour visualiser correctement l'architecture de vos déploiements actuels.

Une architecture cloud correctement documentée établit un langage commun et des normes, qui permettent aux équipes pluridisciplinaires de communiquer et de collaborer efficacement. Il fournit également les informations nécessaires pour identifier et orienter les futures décisions de conception. Afin d'étayer le contexte des décisions spécifiques à la conception, la documentation doit être rédigée à l'aide de vos propres cas d'utilisation.

Au fil du temps, vos décisions de conception évolueront et changeront. L'historique des modifications fournit le contexte nécessaire à vos équipes pour aligner les initiatives, éviter la duplication et mesurer efficacement les changements de performances au fil du temps. Les journaux des modifications sont particulièrement utiles lorsque vous intégrez un nouvel architecte cloud qui ne connaît pas encore la conception, la stratégie ou l'historique actuels de votre système.

Simplifier la conception et utiliser des services entièrement gérés

La simplicité est cruciale pour la conception du système. Si votre architecture est si complexe qu'elle est difficile à comprendre, il sera difficile de la mettre en œuvre et de la gérer au fil du temps. Dans la mesure du possible, utilisez des services entièrement gérés pour réduire les risques, le temps et les efforts de gestion et de maintenance des systèmes de référence.

Si vous exécutez déjà vos charges de travail en production, testez-les avec des services gérés pour voir comment ils peuvent contribuer à réduire les complexités opérationnelles. Si vous développez de nouvelles charges de travail, commencez simplement, établissez un produit minimum viable (MVP) et résistez à l'envie de surcharger. Vous pouvez identifier les cas d'utilisation exceptionnels, effectuer des itérations et améliorer vos systèmes de manière incrémentielle.

Découpler votre architecture

Les recherches menées par l'équipe DORA montrent que l'architecture est un facteur déterminant dans la réussite d'une livraison continue. Le découplage est une technique permettant de séparer vos applications et composants de services en composants plus petits pouvant fonctionner indépendamment. Par exemple, vous pouvez séparer une pile d'applications monolithique en composants de service individuels. Dans une architecture faiblement couplée, une application peut exécuter ses fonctions indépendamment, quelles que soient les différentes dépendances.

Une architecture découplée vous permet d'effectuer les opérations suivantes :

Appliquer des mises à niveau indépendantes.
Appliquer des contrôles de sécurité spécifiques.
Définissez des objectifs de fiabilité pour chaque sous-système.
Surveiller l'état.
Contrôlez de manière précise les performances et les paramètres de coût.

Vous pouvez commencer le découplage au début de la phase de conception ou l'intégrer dans les mises à niveau de votre système lors de la mise à l'échelle.

Utiliser une architecture sans état

Une architecture sans état peut augmenter à la fois la fiabilité et l'évolutivité de vos applications.

Les applications avec état s'appuient sur diverses dépendances pour effectuer des tâches, telles que des données mises en cache localement. Les applications avec état nécessitent souvent des mécanismes supplémentaires pour capturer la progression et redémarrer correctement. Les applications sans état peuvent effectuer des tâches sans dépendances locales importantes à l'aide d'espace de stockage partagé ou de services mis en cache. Une architecture sans état permet à vos applications de s'adapter rapidement avec des dépendances de démarrage minimales. Les applications peuvent supporter des redémarrages forcés, réduire les temps d'arrêt et offrir de meilleures performances aux utilisateurs finaux.

La catégorie "Conception du système" décrit les recommandations permettant de rendre vos applications sans état ou d'utiliser des fonctionnalités cloud natives pour améliorer la capture de l'état de la machine pour vos applications avec état.