Unité 8.1 : Cadres de prise de décision architecturale

Introduction

À ce stade du cours, chaque primitive a été examinée en profondeur. Cette unité ne les réenseigne pas. Il s'agit d'un artefact de référence : un ensemble de matrices de sélection auxquelles vous faites référence lorsqu'une couche FinCorp nécessite une décision et que vous souhaitez obtenir le critère de différenciation, la contrainte stricte pouvant disqualifier un choix de manière définitive, et l'unité qui en déduit 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 des possibles. Les contraintes d'éligibilité strictes sont absolues : une seule contrainte non respectée élimine une option, quelle que soit sa performance sur les autres aspects. La souveraineté et le périmètre d'attestation sont appliqués en dernier, sur l'ensemble de la conception, car la conformité restreint les choix plutôt qu'elle ne les initie. L'unité se conclut sur les deux façons dont une conception techniquement solide peut tout de même échouer : associer des primitives qui ne composent pas, et placer un service fonctionnellement correct en dehors du périmètre d'attestation requis par la charge de travail.

1. Sélection de la classe de calcul

La décision de calcul repose sur une division en quatre axes : l'isolation des cœurs, le contrôle de la famille de CPU, l'attachement du stockage en bloc et le modèle opérationnel. La contrainte qui écarte le plus souvent une option est la contrainte permanente : le modèle d'un Cube est immuable après le provisionnement. Par conséquent, un niveau dont la configuration ou les besoins en mise à l'échelle peuvent évoluer est conçu sur une classe qui peut être reconfigurée. VM Auto Scaling est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique défini au moment de la conception.

Le schéma consiste à associer une classe à chaque niveau : un niveau d'application sans état qui se met à l'échelle horizontalement utilise Cœur dédié, un nœut utilitaire de taille fixe utilise un Cube, et une charge de travail mono-locataire soumise à des réglementations utilise Private Cloud. Ne standardisez pas une seule classe sur tous les niveaux.

2. Sélection de la plateforme de conteneurs

La décision concernant les conteneurs repose sur qui assume le cycle de vie du plan de contrôle et la charge de conformité. Une seule option place cette charge sur IONOS CLOUD.

Pour le parc de conteneurs de FinCorp, le facteur de différenciation est la charge opérationnelle : Managed Kubernetes est le choix par défaut car IONOS CLOUD possède le plan de contrôle, et les alternatives déployées par le client ne sont choisies que lorsqu'un contrat ou une base de compétences OpenShift ou Rancher existe déjà.

3. Sélection de la couche de stockage

Le stockage est adapté au motif d'accès. La contrainte rigoureuse récurrente est le seuil de performance des 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 les zones 1, 2, 3 et Auto, tandis que le calcul ne propose que les zones 1, 2 et Auto. Une paire redondante fixée sur « Zone 3 calcul » n'est pas possible car la zone 3 du calcul n'existe pas.

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

La décision concernant la base de données est d'abord dictée par le modèle de données, puis par le modèle de réplication et de continuité. Aucun moteur relationnel ne propose de répliques en lecture, et le Backup Service ne couvre aucune base de données managée. Par conséquent, la mise à l'échelle en lecture et la continuité sont composées, et non acquises.

Pour le cœur transactionnel de FinCorp, PostgreSQL avec réplication strictement synchrone répond à l'exigence de RPO faible, la couche In-Memory DB répond à la mise à l'échelle en lecture car les répliques en lecture n'existent pas, et Kafka transporte les événements de modification car aucun flux de modifications de base de données managée n'est disponible.

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 rigoureuses constituent ici la source la plus fréquente de combinaisons incompatibles (voir la section 7).

6. Le filtre de souveraineté et d'attestation

Appliquez ce filtre en dernier, sur la conception finalisée. La souveraineté et la conformité ne sont pas à l'origine d'une architecture ; elles restreignent l'ensemble des emplacements qu'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é aux États-Unis présente toujours une exposition au CLOUD Act américain, tandis qu'IONOS CLOUD est exploité par un opérateur de l'UE.

Les périmètres d'attestation diffèrent selon le service et ne doivent jamais être généralisés en « la plateforme est certifiée ». Les deux reconnaissances BSI, toutes deux pour des centres de données allemands, couvrent des ensembles de services différents :

IONOS CLOUD est le premier fournisseur de cloud allemand à détenir à la fois l'attestation C5 et la certification IT-Grundschutz, mais les deux périmètres ne sont pas interchangeables. C5 est une attestation (Testat), de type 1, et non une certification, et non de type 2. Les accréditations au niveau du centre de données (par exemple ISO 27001 sur un site, PCI-DSS, Uptime Tier IV) sont détenues par l'opérateur du centre de données et varient selon le site ; les listes de certifications de produits dans le marketing ne sont pas contractuelles. NIS2 est une obligation réglementaire, et non une certification détenue.

Pour FinCorp, conformément au RGPD et au BSI, la résidence des données est une décision de placement prise avant que toute charge de travail ne soit déployée : centres de données allemands, opérateur de l'UE, et chaque service dans le périmètre validé par rapport à l'attestation exacte requise par sa classe de données.

Résumé de la décision

Utilisez les matrices ci-dessus comme livrable principal de l'unité. L'ordre de lecture est fixe :

1. Restreindre par le critère de différenciation du niveau.
2. Éliminer toute option qui ne satisfait pas à une contrainte d'éligibilité stricte, avant de prendre en compte tout autre élément.
3. Appliquer le filtre de souveraineté et d'attestation en dernier, sur l'ensemble de la conception.

7. Les deux erreurs de composition

Une conception peut passer toutes les matrices par primitive et échouer néanmoins. Deux erreurs expliquent la quasi-totalité de ces échecs.

Association de primitives incompatibles. Deux choix, chacun correct pris isolément, ne composent pas ensemble. Placer un Network Security Group « devant » un Managed ALB ou NLB n'a aucun effet, car les NSGs sont liés aux cartes réseau des serveurs et jamais au load balancer managé ; le filtrage doit se situer sur les cibles. S'attendre à du trafic entrant via une NAT Gateway échoue, car la NAT est uniquement en SNAT ; la publication entrante relève d'un load balancer ou d'une IP publique réservée. Opter pour un Cross-Connect pour relier deux VDC dans des régions différentes échoue, car le Cross-Connect est limité à la même région et au même contrat. Il s'agit à chaque fois d'une primitive correcte utilisée là où sa contrainte stricte l'interdit.

Un choix fonctionnellement correct hors du périmètre d'attestation requis. Un service peut accomplir parfaitement la tâche et rester néanmoins le mauvais choix pour une charge de travail réglementée, s'il se situe hors de l'attestation que cette charge de travail exige. Exécuter le traitement conteneurisé réglementé de FinCorp sur Managed Kubernetes est fonctionnellement valide, mais Managed Kubernetes ne fait pas partie du périmètre d'attestation C5, de sorte qu'une charge de travail qui exige contractuellement C5 doit être déployée sur un service couvert par C5, tel que Compute Engine. Le choix n'est pas techniquement erroné ; il est erroné au regard du filtre de périmètre, ce qui explique précisément pourquoi ce filtre est appliqué en dernier sur l'ensemble de la conception.

Résumé

Les décisions d'architecture sur IONOS CLOUD se réduisent à une itération reproductible : restreindre par le critère différenciant, éliminer sur les contraintes strictes, et appliquer le périmètre de souveraineté et d'attestation en dernier sur la conception finalisée. Les matrices de cette unité regroupent ces critères et contraintes pour le calcul, les conteneurs, le stockage, les bases de données et le réseau, afin 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 immédiatement : une seule contrainte non respectée élimine une option, indépendamment de ses autres scores.
• VM Auto Scaling est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique défini à la conception ; les moteurs relationnels ne disposent pas de répliques en lecture ; le Backup Service ne couvre aucune base de données managée. Ces limites déterminent les niveaux à l'avance.
• Le filtre de souveraineté et d'attestation est appliqué en dernier, car la conformité restreint une conception déjà complète plutôt qu'elle ne l'initie.
• Les périmètres C5 et IT-Grundschutz diffèrent selon le service : Cubes est couvert par C5 mais pas par IT-Grundschutz ; Backup et Managed Kubernetes sont couverts par IT-Grundschutz mais pas par C5. Il ne faut jamais généraliser en affirmant que « la plateforme est certifiée ».
• Les deux erreurs de composition consistent à associer des primitives dont les contraintes interdisent cette association, et à placer un service fonctionnellement correct en dehors du périmètre d'attestation requis par la charge de travail.

Terminologie importante :

• Contrainte d'éligibilité stricte : un critère d'exclusion absolu (par exemple le modèle immuable d'un Cube, ou l'absence de mise à l'échelle à zéro de Managed Kubernetes) qui élimine une option avant toute prise en compte des critères pondérés.
• Périmètre d'attestation : l'ensemble exact des services couverts par une accréditation ; sur IONOS CLOUD, 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, à l'accréditation, à son type et à sa date.

Lecture complémentaire

• Unité 4.1 Sélection de la classe de calcul, Unité 4.4 Private Cloud (VMware dédié)
• Unité 6.1 Conception de la plateforme Kubernetes, Unité 6.4 Container Registry 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