Unité 1.3 : Conception autour des limites de la plateforme : le modèle de substitution natif
Introduction
La façon la plus courante dont un architecte expérimenté se trompe sur IONOS est de rechercher un produit géré qui n'existe pas, de ne rien trouver, et de conclure que la plateforme manque d'une fonctionnalité. La lecture la plus précise est que la plateforme expédie délibérément des primitives et s'attend à ce que vous composiez la fonctionnalité. Il n'y a pas de produit géré API Gateway, pas de fonctionnalité de réplique en lecture, pas de produit de basculement géré, pas de service de capture de données de modification de base de données, pas d'assistant d'importation OVF/OVA, et pas de système d'identité de langage de stratégie. Aucun de ceux-ci n'est une omission pour laquelle s'excuser ; chacun est une fonctionnalité que la plateforme s'attend à ce que vous assembliez à partir des pièces qu'elle vous donne. Cette unité nomme le substitut pour chacun, car une fois que vous détenez le modèle, les lacunes apparentes cessent d'être des surprises et deviennent des modèles de conception connus. Chaque substitution prévisualise le module qui le construit en entier.
1. L'ensemble de substitution
Le modèle est toujours le même : une fonctionnalité que peut vendre un hyperscaler en tant que seul élément géré est, sur IONOS, une composition de deux ou trois primitives que vous reliez ensemble. Définissez honnêtement la limite, puis utilisez le modèle natif.
Le routage de contenu à la place d'un API Gateway géré. Il n'y a pas de produit IONOS API Gateway. Le modèle natif route le contenu avec des règles de transfert de Managed ALB à la limite (basées sur l'hôte et le chemin, puisque l'ALB route le trafic de la couche application sur des politiques définies par l'utilisateur) et un contrôleur d'entrée in-Cluster pour un routage plus fin à l'intérieur de Kubernetes. L'ALB effectue le routage public grossier ; l'entrée effectue le routage interne fin. N'oubliez pas que l'ALB n'a pas de liste d'autorisation IP et pas de groupe de sécurité, donc le filtrage des requêtes appartient aux cibles. Cela est construit dans le Module 3 (équilibrage de charge de la couche 7).
La mise à l'échelle des lectures à la place des réplicas de lecture. Les bases de données gérées sur IONOS n'ont pas de réplicas de lecture et pas de réplication native vers une autre instance gérée. Vous mettez à l'échelle les lectures avec un cache In-Memory DB devant la couche relationnelle, ainsi qu'un regroupement de connexions pour respecter le plafond de connexion dérivé de RAM de la base de données. Le cache absorbe le trafic de lecture lourd ; le regroupement de connexions maintient le nombre de connexions viable. Cela est construit dans le Module 5 (les unités de base de données relationnelles et en mémoire).
La bascule automatique à la place d'un produit de bascule géré. Il n'y a pas de service de bascule géré. Le substitut natif combine les vérifications de santé du chargeur d'équilibrage, qui détourne le trafic loin d'une cible non saine dans le pool principal de Load Balancer, avec un enregistrement Cloud DNS à faible TTL orchestré par le client que une vérification de santé externe réorienté pour la bascule entre zones. Cloud DNS lui-même n'est pas conscient de la santé ; il sert tout enregistrement que vous définissez. Puisque DNS ne détourne que les nouvelles connexions et est limité par la durée de vie de l'enregistrement TTL, le niveau d'application doit être sans état pour que cela soit propre. Cela est construit dans le Module 3 (DNS et bascule) et revisité dans le Module 7 (résilience).
Les événements au niveau de l'application à la place de la capture de données de modification de base de données. Il n'y a pas de flux de capture de données de modification géré à partir des bases de données. Le substitut natif est de publier des événements à partir de l'application elle-même, généralement sur Managed Kafka, où un sujet capture les événements de modification et les consommateurs en aval les lisent. La capture se déplace vers le haut dans le code d'application plutôt que de taper dans le journal de la base de données. Cela est construit dans le Module 5 (diffusion d'événements).
La conversion d'image à la place de l'importation native OVF/OVA. Il n'y a pas d'assistant d'importation OVF/OVA natif. La migration d'une machine virtuelle existante est une étape conçue : convertissez et téléchargez l'image du disque, avec des pilotes VirtIO installés et une transition UEFI préparée, après quoi l'image est utilisable dans la région où elle a été téléchargée (les images sont verrouillées par région). Cela est construit dans le Module 7 (migration et bascule hybride).
Le groupe et l'octroi à la place d'un langage de stratégie IAM. Il n'y a pas de système d'identité à base de stratégie fine. Le contrôle d'accès est basé sur des groupes avec des octrois de ressources : vous attribuez des privilèges à un groupe et accordez à ce groupe l'accès à des ressources spécifiques, et il n'y a pas de règle de refus, donc le principe du moindre privilège signifie simplement ne pas accorder. Cela est construit dans le Module 2 (identité et RBAC).
Le tableau suivant est le modèle en une page ; traitez-le comme l'index du REST du cours.
| Fonctionnalité que vous pourriez attendre | Ce que IONOS ne vend pas | Le substitut natif | Construit dans |
|---|---|---|---|
| API Gateway | Pas de produit API Gateway | Règles de transfert ALB + contrôleur d'entrée in-Cluster | Module 3 |
| Réplicas de lecture | Pas de réplicas de lecture / réplication de base de données gérée | Cache In-Memory DB + regroupement de connexions | Module 5 |
| Bascule gérée | Pas de produit de bascule géré | Vérifications de santé du chargeur d'équilibrage + réorientation DNS à faible TTL orchestrée par le client | Modules 3, 7 |
| Capture de données de modification de base de données | Pas de flux de capture de données de modification géré | Publication d'événements au niveau de l'application (par exemple Kafka) | Module 5 |
| Importation OVF/OVA | Pas d'assistant d'importation natif | Conversion d'image + téléchargement (VirtIO, préparation UEFI) | Module 7 |
| Langage de stratégie IAM | Pas de système d'identité à base de stratégie fine | Groupe et octroi, octrois de ressources de niveau, pas de règle de refus | Module 2 |
Pour FinCorp, le modèle réforme l'ensemble de l'engagement. Sa charge de travail relationnelle réglementée n'obtiendra pas de réplica de lecture géré, donc la conception planifie déjà un chemin de lecture avec cache et regroupement de connexions. Son patrimoine VMware n'importera pas en tant qu'OVA/OVF, donc le plan de migration suppose déjà une conversion d'image (aux côtés des chemins natifs VMware couverts plus tard). Son modèle d'accès n'appliquera pas une stratégie de refus ; la gouvernance est donc conçue comme un octroi délibéré et minimal. Aucun de ces éléments n'est une solution de contournement découverte tardivement sous pression ; chacun est un modèle connu sélectionné à l'avance parce que l'architecte a tenu le modèle de substitution dès le début.
Résumé de la décision
Lorsqu'un exigence mentionne une fonctionnalité que vous ne pouvez pas trouver en tant que produit, ne supposez pas que la plateforme en est dépourvue. Exécutez plutôt cette vérification :
| Étape | Action |
|---|---|
| 1 | Confirmez contre la matrice des faits ou les documents actuels que aucun produit géré ne livre la fonctionnalité directement. |
| 2 | Identifiez la substitution native : quels deux ou trois éléments primitifs la composent (règles de routage + entrée, cache + regroupement, vérifications de santé LB + réorientation DNS à faible TTL, événements d'application, conversion d'images, regroupement et autorisation). |
| 3 | Tenez compte de la contrainte de substitution dès le départ (ALB n'a pas de liste d'autorisation ; DNS ne dirige que les nouvelles connexions ; les images sont verrouillées par région ; il n'y a pas de règle de refus). |
| 4 | Notez lequel des modules ultérieurs la construit, et portez la décision dans la conception de FinCorp. |
La discipline consiste à ne jamais déduire une fonctionnalité d'un nom de produit ou d'un analogue de hyperscaler. Énoncez la limite clairement, puis composez le modèle.
Résumé
IONOS compose des capacités à partir de primitives plutôt que de les vendre comme des fonctionnalités gérées uniques, donc plusieurs choses qu'un architecte pourrait attendre en tant que produits, un API Gateway, des réplicas de lecture, un basculement géré, une capture de données de modification, une importation OVF/OVA, et une politique IAM, sont livrées comme des substitutions natives : des règles ALB plus ingress, un cache plus un regroupement, des vérifications de santé LB plus une réorientation DNS à faible TTL, des événements au niveau de l'application, une conversion d'images, et un groupe-et-octroi. En tenant compte de ce modèle, les lacunes apparentes sont converties en modèles connus et le REST du cours est transformé en l'endroit où chaque substitution est construite.
Points clés :
- La plateforme expédie des primitives et attend une composition ; un produit géré absent est une entrée de conception, et non un défaut.
- Les six substitutions de base sont le routage de contenu (ALB + ingress), la mise à l'échelle de lecture (cache + regroupement), le basculement (vérifications de santé LB + réorientation DNS orchestrée par le client), la capture de données de modification (événements d'application), l'importation VM (conversion d'images), et le contrôle d'accès (groupe-et-octroi).
- Chaque substitution comporte une contrainte à planifier, et chaque substitution préfigure le module ultérieur qui la construit.
- Ne jamais déduire une capacité d'un nom de produit ou d'un analogue de hyperscaler ; confirmer la limite, puis composer le modèle natif.