Unidad 1.3: Diseñar alrededor de las fronteras de la plataforma: El modelo de sustitución nativa

Introducción

La forma más común en que un arquitecto experimentado se equivoca en IONOS es buscar un producto gestionado que no existe, no encontrar nada y concluir que la plataforma falta una característica. La interpretación más precisa es que la plataforma envía deliberadamente elementos básicos y espera que usted componga la capacidad. No hay un API Gateway gestionado, no hay una característica de réplica de lectura, no hay un producto de conmutación por error gestionado, no hay un servicio de captura de datos de cambio de base de datos, no hay un asistente de importación OVF/OVA y no hay un sistema de identidad de lenguaje de política. Ninguno de estos es una omisión para disculparse; cada uno es una capacidad que la plataforma espera que usted ensamblé con las partes que sí le da. Esta unidad nombra el sustituto para cada uno, porque una vez que tenga el modelo, las brechas aparentes dejan de ser sorpresas y se convierten en patrones de diseño conocidos. Cada sustituto prevé el módulo que lo construye en su totalidad.

1. El conjunto de sustitución

El patrón es siempre el mismo: una capacidad que un hyperscaler podría vender como un solo control gestionado es, en IONOS, una composición de dos o tres primitivos que se conectan entre sí. Establezca el límite honestamente, luego busque el patrón nativo.

Enrutamiento de contenido en lugar de un API Gateway gestionado. No hay producto IONOS API Gateway. El patrón nativo enruta el contenido con reglas de reenvío de Managed ALB en el borde (basado en host y ruta, ya que el ALB enruta el tráfico de capa de aplicación en políticas definidas por el usuario) y un controlador de entrada en Cluster para un enrutamiento más fino dentro de Kubernetes. El ALB realiza el enrutamiento público grueso; la entrada realiza el enrutamiento interno fino. Tenga en cuenta que el ALB no tiene lista de permitidos IP y no tiene grupo de seguridad, por lo que el filtrado de solicitudes pertenece a los objetivos. Esto se construye en el Módulo 3 (equilibrio de carga de capa 7).

Escalado de lectura en lugar de réplicas de lectura. Las bases de datos gestionadas en IONOS no tienen réplicas de lectura y no tienen replicación nativa a otra instancia gestionada. Usted escala las lecturas con una caché In-Memory DB delante de la capa relacional más la agrupación de conexiones para respetar el techo de conexión derivado de RAM de la base de datos. La caché absorbe el tráfico de lectura pesado; el agrupador mantiene la cuenta de conexiones superviviente. Esto se construye en el Módulo 5 (las unidades de base de datos relacional e in-memory).

Conmutación por error automatizada en lugar de un producto de conmutación por error gestionado. No hay servicio de conmutación por error gestionado. El sustituto nativo combina comprobaciones de salud de equilibrio de carga, que desvían el tráfico lejos de un objetivo no saludable dentro del grupo de Load Balancer, con un registro Cloud DNS de baja TTL orquestado por el cliente que una comprobación de salud externa reseña para la conmutación por error entre zonas. Cloud DNS en sí mismo no es consciente de la salud; sirve cualquier registro que establezca. Debido a que DNS solo desvía nuevas conexiones y está limitado por la TTL del registro, el nivel de aplicación debe ser sin estado para que esto sea limpio. Esto se construye en el Módulo 3 (DNS y conmutación por error) y se revisa en el Módulo 7 (resiliencia).

Eventos a nivel de aplicación en lugar de captura de datos de cambio de base de datos. No hay flujo de captura de datos de cambio de base de datos gestionado. El sustituto nativo es publicar eventos desde la aplicación en sí, generalmente en Managed Kafka, donde un tema captura los eventos de cambio y los consumidores downstream los leen. La captura se mueve hacia arriba en el código de la aplicación en lugar de aprovechar el registro de la base de datos. Esto se construye en el Módulo 5 (transmisión de eventos).

Conversión de imagen en lugar de importación nativa de OVF/OVA. No hay asistente de importación nativa de OVF/OVA. La migración de una máquina virtual existente es un paso diseñado: convertir y cargar la imagen del disco, con controladores VirtIO instalados y una transición UEFI preparada, después de lo cual la imagen es usable en la región a la que se cargó (las imágenes están bloqueadas por región). Esto se construye en el Módulo 7 (migración y corte híbrido).

Grupo y concesión en lugar de lenguaje de política IAM. No hay sistema de identidad basado en políticas finas. El control de acceso es basado en grupos con concesiones de nivel de recurso: usted asigna privilegios a un grupo y otorga acceso a ese grupo a recursos específicos, y no hay regla de denegación, por lo que el privilegio mínimo significa simplemente no otorgar. Esto se construye en el Módulo 2 (identidad y RBAC).

La siguiente tabla es el modelo en una página; trátela como el índice del REST del curso.

Para FinCorp, el modelo reframa todo el compromiso. Su base de datos relacional regulada Workload no obtendrá una réplica de lectura gestionada, por lo que el diseño ya planea una ruta de lectura con caché y agrupador. Su propiedad VMware no se importará como OVF/OVA, por lo que el plan de migración ya asume la conversión de imagen (junto con los caminos nativos de VMware cubiertos más adelante). Su modelo de acceso no hará cumplir una política de denegación, por lo que la gobernanza se diseña como concesión deliberada y mínima. Ninguno de estos es un trabajo alternativo descubierto tarde bajo presión; cada uno es un patrón conocido seleccionado desde el principio porque el arquitecto sostuvo el modelo de sustitución desde el principio.

Resumen de la decisión

Cuando un requisito nombra una capacidad que no puede encontrar como un producto, no suponga que la plataforma carece de ella. Ejecute esta verificación en su lugar:

La disciplina es nunca inferir una característica a partir de un nombre de producto o un analógico de hyperscaler. Establezca el límite claramente, luego componga el patrón.

Resumen

IONOS compone capacidades a partir de elementos primitivos en lugar de venderlas como características administradas individuales, por lo que varias cosas que un arquitecto podría esperar como productos, un API Gateway, réplicas de lectura, conmutación por error administrada, captura de datos de cambio, importación de OVF/OVA y directiva IAM, se entregan como sustituciones nativas: reglas de ALB más ingreso, caché más agrupación, comprobaciones de salud de LB más reasignación de DNS de baja TTL, eventos a nivel de aplicación, conversión de imagen y grupo-y-concesión. Mantener este modelo convierte las aparentes lagunas en patrones conocidos y convierte el REST del curso en el lugar donde se construye cada sustitución.

Puntos clave:

• La plataforma envía elementos primitivos y espera composición; un producto administrado ausente es una entrada de diseño, no un defecto.
• Las seis sustituciones básicas son enrutamiento de contenido (ALB + ingreso), escalado de lectura (caché + agrupación), conmutación por error (comprobaciones de salud de LB + reasignación de DNS orchestrada por el cliente), captura de datos de cambio (eventos de aplicación), importación de VM (conversión de imagen) y control de acceso (grupo-y-concesión).
• Cada sustitución conlleva una restricción para planificar, y cada una prevé el módulo posterior que lo construye.
• Nunca infiera una capacidad a partir de un nombre de producto o un analógico de hyperscaler; confirme el límite, luego compose el patrón nativo.