Unité 8.1 : Cadres de décision d'architecture

Introduction

À ce stade du cours, chaque primitive a été examinée en profondeur. Cette unité ne les réapprend pas. Il s'agit d'un artefact de référence : un ensemble de matrices de sélection auxquelles vous revenez lorsque un niveau FinCorp nécessite une décision et que vous souhaitez le critère de différenciation, la contrainte stricte qui peut disqualifier un choix de manière définitive, et l'unité qui dérive le raisonnement, le tout en un seul endroit.

Lisez chaque matrice de la même manière. Les critères de différenciation réduisent le champ. Les contraintes d'éligibilité strictes sont absolues : une seule contrainte non respectée élimine une option, quelle que soit sa note ailleurs. La souveraineté et la portée de l'attestation sont appliquées en dernier, sur l'ensemble de la conception, car la conformité restreint les choix plutôt que de les initier. L'unité se termine sur les deux façons dont une conception technique solide échoue encore : associer des primitives qui ne se composent pas, et placer un service fonctionnellement correct en dehors de la portée d'attestation que la charge de travail requiert.

1. Sélection de la classe de calcul

La décision de calcul est une division en quatre axes à travers l'isolement du noyau, le contrôle de la famille CPU, l'attachement du stockage sur bloc, et le modèle opérationnel. La contrainte qui disqualifie le plus souvent est la permanente : un modèle de Cube est immuable après la mise en service, donc un niveau dont la forme ou les besoins de mise à l'échelle peuvent changer est conçu sur une classe qui peut être reconfigurée. VM Auto Scaling lui-même est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique de conception.

Le modèle est une classe par niveau : un niveau d'application sans état qui se met à l'échelle prend le noyau dédié, un niveau d'utilité Node de taille fixe prend un Cube, une charge de travail à locataire unique réglementée prend Private Cloud. Ne standardisez pas une classe sur tous les niveaux.

2. Sélection de la plateforme de conteneurs

La décision concernant les conteneurs dépend de qui assume le contrôle du cycle de vie de la plateforme de contrôle et de la charge de conformité. Une seule option impose cette charge à IONOS.

Pour le patrimoine de conteneurs de FinCorp, le facteur de différenciation est la charge opérationnelle : Managed Kubernetes est la valeur par défaut car IONOS possède la plateforme de contrôle, et les alternatives déployées par le client sont choisies uniquement lorsque contrat ou base de compétences OpenShift ou Rancher existe déjà.

3. Sélection du niveau de stockage

Le stockage est adapté au modèle d'accès. La contrainte récurrente est le plancher de performance de SSD et l'asymétrie de zone entre le calcul et le stockage.

Notez l'asymétrie de zone en tant que contrainte de placement : Block Storage propose la zone 1, 2, 3, et Auto, tandis que le calcul n'offre que les zones 1, 2, et Auto. Une paire redondante fixée à la "zone 3 de calcul" n'est pas possible car la zone 3 de calcul n'existe pas.

4. Sélection du moteur de base de données

La décision de base de données est dictée par le modèle de données en premier lieu et le modèle de réplication et de continuité en second lieu. Pour chaque moteur géré, la même limite s'applique : il n'y a pas de réplicas en lecture et le Backup Service ne couvre pas les bases de données gérées, donc la mise à l'échelle en lecture et la continuité sont composées, et non achetées.

Pour le noyau transactionnel de FinCorp, PostgreSQL avec réplication strictement synchrone répond à la exigence de faible RPO, le niveau In-Memory DB répond à la mise à l'échelle en lecture car les réplicas en lecture n'existent pas, et Kafka transporte les événements de modification car il n'y a pas de flux de modification géré de base de données.

5. Sélection des primitives de réseau

Chaque primitive de réseau répond à une couche ou une direction de trafic différente. Les contraintes strictes ici sont la source la plus fréquente d'appariements incompatibles (voir la Section 7).

6. Le filtre de souveraineté et d'attestation

Appliquez ce filtre en dernier, sur la conception terminée. La souveraineté et la conformité ne créent pas une architecture ; elles réduisent l'ensemble des emplacements que une conception déjà correcte est autorisée à utiliser. La souveraineté juridique de l'UE est une propriété de la juridiction de l'opérateur, et non de la région seule : une région de l'UE d'un fournisseur exploité par les États-Unis est toujours exposée à la loi CLOUD Act américaine, alors que IONOS est exploité par l'UE.

Les scopes d'attestation diffèrent par service et ne doivent jamais être généralisés à "la plateforme est certifiée". Les deux reconnaissances BSI, toutes deux pour les centres de données allemands, couvrent des ensembles de services différents :

IONOS est le premier fournisseur de cloud allemand à détenir à la fois l'attestation C5 et la certification IT-Grundschutz, mais les deux scopes ne sont pas interchangeables. C5 est une attestation (Testat), de type 1, et non une certification et non de type 2. Les informations d'identification au niveau des centres de données (par exemple ISO 27001 à un emplacement, PCI-DSS, Uptime Tier IV) sont détenues par l'opérateur de centre de données et varient en fonction de l'emplacement ; les listes de certificats de produits dans le marketing ne sont pas contractuelles. NIS2 est une obligation réglementaire, et non une certification détenue.

Pour FinCorp sous GDPR et BSI, la résidence est une décision de placement prise avant que toute charge de travail ne soit affectée : les centres de données allemands, l'opérateur de l'UE, et chaque service dans le scope validé contre l'attestation exacte dont sa classe de données a besoin.

Résumé de la décision

Utilisez les matrices ci-dessus comme artefact à retenir de l'unité. L'ordre de lecture est fixé :

1. Réduisez par le critère de différenciation pour le niveau.
2. Éliminez chaque option qui échoue à une contrainte d'éligibilité stricte, avant de prendre en compte tout le reste.
3. Appliquez le filtre de souveraineté et d'attestation en dernier, sur toute la conception.

7. Les deux erreurs de composition

Un design peut passer tous les matrices par primitive et échouer encore. Deux erreurs comptent pour presque tous ces cas.

Appairer des primitives incompatibles. Deux choix qui sont chacun corrects en isolation ne se composent pas. Placer un groupe de sécurité réseau « devant » un équilibreur de charge ALB ou NLB géré ne fait rien, car les groupes de sécurité réseau sont liés aux cartes réseau des serveurs et jamais au produit géré Load Balancer ; le filtrage doit être effectué sur les cibles. S'attendre à un trafic entrant via une passerelle NAT échoue, car NAT est uniquement SNAT ; la publication entrante appartient à un Load Balancer ou à une adresse IP publique réservée IP. Essayer de joindre deux centres de données virtuels dans différentes régions à l'aide d'une connexion croisée échoue, car la connexion croisée est limitée à la même région et au même contrat. Chacun est une primitive correcte utilisée là où sa contrainte stricte l'interdit.

Un choix fonctionnellement correct en dehors de la portée d'attestation requise. Un service peut faire le travail parfaitement et être encore le mauvais choix pour une charge de travail réglementée parce qu'il se trouve en dehors de l'attestation que cette charge de travail nécessite. Exécuter le traitement de conteneurs réglementés de FinCorp sur Managed Kubernetes est fonctionnellement solide, mais Managed Kubernetes n'est pas dans la portée d'attestation C5, donc une charge de travail qui nécessite contractuellement C5 doit être placée sur un service couvert par C5, tel que Compute Engine, à la place. Le choix n'est pas incorrect sur le plan technique ; il est incorrect par rapport au filtre de portée, qui est exactement pourquoi ce filtre est appliqué en dernier sur l'ensemble du design.

Résumé

Les décisions d'architecture sur IONOS se réduisent à un processus répétitif : réduire en fonction du critère de différenciation, éliminer en fonction des contraintes strictes, et appliquer enfin la souveraineté et la portée de l'attestation sur la conception terminée. Les matrices de cette unité rassemblent ces critères et contraintes pour le calcul, les conteneurs, le stockage, les bases de données et les réseaux, de sorte qu'une décision puisse être prise et justifiée en un seul endroit, avec les deux erreurs de composition comme vérification finale.

Points clés :

• Les contraintes d'éligibilité strictes disqualifient purement et simplement : une seule contrainte non respectée élimine une option, quel que soit son score ailleurs.
• VM Auto Scaling est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique de conception ; il n'y a pas de répliques en lecture ; Backup Service ne couvre pas les bases de données gérées. Ces limites déterminent les niveaux à l'avance.
• Le filtre de souveraineté et d'attestation est appliqué en dernier, car la conformité réduit une conception déjà terminée plutôt que de la créer.
• Les portées de C5 et d'IT-Grundschutz diffèrent par service : Cubes est dans C5 mais pas dans IT-Grundschutz ; la sauvegarde et Managed Kubernetes sont dans IT-Grundschutz mais pas dans C5. Ne généralisez jamais à « la plateforme est certifiée ».
• Les deux erreurs de composition sont l'association de primitives dont les contraintes interdisent l'association, et la mise d'un service fonctionnellement correct en dehors de la portée d'attestation requise par la charge de travail.

Terminologie importante :

• Contrainte d'éligibilité stricte : un disqualificateur absolu (par exemple, un modèle immutable d'un Cube, ou le manque de mise à l'échelle à zéro de Managed Kubernetes) qui élimine une option avant que tout critère pondéré ne soit considéré.
• Portée d'attestation : l'ensemble exact de services qu'une créance couvre ; sur IONOS, C5 et IT-Grundschutz couvrent des services différents, et une affirmation doit toujours être liée au service nommé, à l'emplacement du centre de données allemand, à la créance, à son type et à sa date.

Lecture supplémentaire

• Unité 4.1 Sélection de la classe de calcul, Unité 4.4 Private Cloud (Serveurs dédiés VMware)
• Unité 6.1 Conception de la plateforme Kubernetes, Unité 6.4 Registre de conteneurs et sélection de la plateforme
• Unité 5.7 Protection des données et cycle de vie
• Unité 1.4 Souveraineté et conformité en tant qu'entrées de conception
• Unité 8.2 L'architecture d'entreprise de référence