Unité 1.3 : Concevoir autour des limites de la plateforme : le modèle de substitution native

Introduction

La cause la plus fréquente d'erreur chez un architecte expérimenté sur IONOS CLOUD consiste à rechercher un produit managé qui n'existe pas, à ne rien trouver, puis à conclure que la plateforme manque d'un élément. L'interprétation plus exacte est que la plateforme fournit délibérément des primitives et s'attend à ce que vous composiez la fonctionnalité. Il n'existe pas de passerelle API managée, pas de fonctionnalité de réplique en lecture, pas de produit de basculement managé, pas de service de capture des modifications de données pour les bases de données, pas d'assistant d'importation OVF/OVA, et pas de système d'identité basé sur un langage de politique. Aucune de ces absences ne constitue une omission à regretter ; chacune représente une capacité que la plateforme s'attend à ce que vous assembliez à partir des composants qu'elle vous fournit. Cette unité identifie le substitut pour chaque cas, car une fois le modèle compris, les lacunes apparentes cessent d'être des surprises et deviennent des modèles de conception connus. Chaque substitut présente en avant-première le module qui le construit en détail.

1. Le jeu de substitutions

Le schéma est toujours le même : une capacité qu'un hyperscaler pourrait vendre comme un seul paramètre géré est, sur IONOS CLOUD, une composition de deux ou trois primitives que vous assemblez. Énoncez la limite honnêtement, puis recourez au schéma natif.

Le routage par contenu à la place d'une passerelle API gérée. Il n'existe pas de produit API Gateway sur IONOS CLOUD. Le schéma natif effectue le routage par contenu à l'aide de règles de transfert de Managed ALB à la périphérie (basées sur l'hôte et le chemin, car l'ALB route le trafic de couche application selon des politiques définies par l'utilisateur) et d'un contrôleur d'ingress au sein du cluster pour un routage plus fin à l'intérieur de Kubernetes. L'ALB effectue le routage public grossier ; l'ingress effectue le routage interne fin. Gardez à l'esprit que l'ALB ne dispose ni de liste d'autorisation IP ni de groupe de sécurité, de sorte que le filtrage des requêtes doit être effectué sur les cibles. Ce mécanisme est développé dans le Module 3 (equilibrage de charge de couche 7).

La mise à l'échelle des lectures à la place des répliques de lecture. Les bases de données gérées sur IONOS CLOUD ne disposent ni de répliques de lecture ni de réplication native vers une autre instance gérée. Vous mettez les lectures à l'échelle à l'aide d'un cache In-Memory DB placé devant la couche relationnelle, ainsi que d'un regroupement de connexions pour respecter la limite de connexions dérivée de la RAM de la base de données. Le cache absorbe le trafic riche en lectures ; le regroupement de connexions maintient le nombre de connexions à un niveau viable. Ce mécanisme est développé dans le Module 5 (les unités sur les bases de données relationnelles et en mémoire).

Le basculement automatique à la place d'un produit de basculement géré. Il n'existe pas de service de basculement géré. Le substitut natif combine les vérifications d'état de l'équilibreur de charge, qui détournent le trafic d'une cible non saine au sein du pool d'arrière-plan de l'équilibreur de charge, avec un enregistrement Cloud DNS à TTL faible orchestré par le client, qu'une vérification d'état externe redirige pour le basculement inter-zones. Cloud DNS lui-même n'est pas conscient de l'état ; il sert l'enregistrement que vous définissez. Étant donné que DNS ne dirige que les nouvelles connexions et est limité par le TTL de l'enregistrement, la couche application doit être sans état pour que ce soit propre. Ce mécanisme est développé dans le Module 3 (DNS et basculement) et réexaminé dans le Module 7 (résilience).

Les événements au niveau de l'application à la place de la capture des données modifiées de la base de données. Il n'existe pas de flux géré de capture des données modifiées depuis les bases de données. Le substitut natif consiste à publier des événements depuis l'application elle-même, typiquement sur Managed Kafka, où un sujet capture les événements de modification et les consommateurs en aval les lisent. La capture est déplacée vers le code applicatif plutôt que de puiser dans le journal de la base de données. Ce mécanisme est développé dans le Module 5 (flux d'événements).

La conversion d'images à la place de l'importation native OVF/OVA. Il n'existe pas d'assistant d'importation native OVF/OVA. La migration d'une machine virtuelle existante est une étape ingénierie : convertir et téléverser l'image disque, avec les 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éversée (les images sont verrouillées par région). Ce mécanisme est développé dans le Module 7 (migration et basculement hybride).

Le regroupement et l'octroi à la place d'un IAM à langage de politique. Il n'existe pas de système d'identité finement granulaire et basé sur des politiques. Le contrôle d'accès est basé sur les groupes avec des octrois au niveau des ressources : vous assignez des privilèges à un groupe et octroyez à ce groupe l'accès à des ressources spécifiques, et il n'y a pas de règle de refus, de sorte que le moindre privilège signifie simplement ne pas octroyer. Ce mécanisme est développé dans le Module 2 (identité et RBAC).

Le tableau suivant est le modèle en une page ; considérez-le comme l'index du reste du cours.

Pour FinCorp, le modèle réorganise l'ensemble de la mission. Sa charge de travail relationnelle réglementée ne bénéficiera pas d'une réplique de lecture gérée, de sorte que la conception prévoit déjà un chemin de lecture par cache et regroupement de connexions. Son parc VMware ne sera pas importé en OVF/OVA, de sorte que le plan de migration suppose déjà la conversion d'images (aux côtés des chemins natifs VMware couverts plus tard). Son modèle d'accès n'appliquera pas de politique de refus, de sorte que la gouvernance est conçue comme un octroi délibéré et minimal. Aucune de ces mesures n'est une solution de contournement découverte tardivement sous pression ; chacune est un schéma connu sélectionné d'avance parce que l'architecte a détenu le modèle de substitution dès le départ.

Résumé de la décision

Lorsqu'une exigence désigne une capacité que vous ne trouvez pas sous forme de produit, ne supposez pas que la plateforme en est dépourvue. Effectuez plutôt cette vérification :

La discipline consiste à ne jamais inférer une fonctionnalité à partir d'un nom de produit ou d'un analogue chez un hyperscaler. Énoncez clairement la limite, puis composez le motif.

Résumé

IONOS CLOUD compose des capacités à partir de primitives plutôt que de les commercialiser sous forme de fonctionnalités gérées uniques. Ainsi, plusieurs éléments qu'un architecte pourrait s'attendre à trouver sous forme de produits, à savoir une passerelle API, des répliques en lecture, une bascule gérée, la capture des modifications de données, l'importation OVF/OVA et l'IAM par politiques, sont fournis sous forme de substituts natifs : des règles ALB associées à l'ingress, la mise en cache associée à la mutualisation, les vérifications d'état du LB associées à la redirection DNS à TTL faible, les événements au niveau applicatif, la conversion d'images et le modèle de groupes et d'attributions. Cette approche permet de transformer les lacunes apparentes en modèles connus et fait du reste du cours le lieu où chaque substitut est mis en œuvre.

Points clés :

• La plateforme fournit des primitives et suppose qu'elles soient composées ; l'absence d'un produit géré constitue une donnée de conception, et non un défaut.
• Les six substituts principaux sont le routage par contenu (ALB + ingress), la mise à l'échelle en lecture (mise en cache + mutualisation), la bascule (vérifications d'état du LB + redirection DNS orchestrée par le client), la capture des modifications de données (événements applicatifs), l'importation de VM (conversion d'images) et le contrôle d'accès (groupes et attributions).
• Chaque substitut implique une contrainte à prendre en compte dans la planification, et chacun préfigure le module ultérieur qui le met en œuvre.
• Ne jamais inférer une capacité à partir d'un nom de produit ou d'un équivalent chez un hyperscaler ; vérifier la limite, puis composer le modèle natif.