Unidad 1.3: Diseño en torno a los límites de la plataforma: el modelo de sustitución nativa

Introducción

La forma más común en que un arquitecto experimentado se equivota en IONOS CLOUD es buscar un producto administrado que no existe, no encontrar nada y concluir que la plataforma carece de una función. La interpretación más precisa es que la plataforma entrega deliberadamente primitivas y espera que usted componga la capacidad. No existe una pasarela de API administrada, ninguna función de réplica de lectura, ningún producto de conmutación por error administrado, ningún servicio de captura de cambios de datos de base de datos, ninguna asistente de importación OVF/OVA y ningún sistema de identidad basado en lenguaje de políticas. Ninguna de estas ausencias es un descuido del que disculparse; cada una es una capacidad que la plataforma espera que usted ensamble a partir de las piezas que sí le proporciona. Esta unidad nombra la sustitución para cada caso, porque una vez que usted domina el modelo, las aparentes lagunas dejan de ser sorpresas y se convierten en patrones de diseño conocidos. Cada sustitución anticipa el módulo que la construye por completo.

1. El conjunto de sustituciones

El patrón es siempre el mismo: una capacidad que un hiperescalador podría vender como un solo control administrado, en IONOS CLOUD es una composición de dos o tres primitivas que usted debe conectar. Declare el límite con honestidad y luego recurra al patrón nativo.

Enrutamiento por contenido en lugar de una API Gateway administrada. No existe un producto IONOS CLOUD API Gateway. El patrón nativo realiza el enrutamiento por contenido mediante reglas de reenvío de Managed ALB en el borde (basadas en host y ruta, ya que el ALB enruta tráfico de capa de aplicación según políticas definidas por el usuario) y un controlador de entrada dentro del clúster para un enrutamiento más detallado dentro de Kubernetes. El ALB realiza el enrutamiento público de gran grano; el controlador de entrada realiza el enrutamiento interno de gran precisión. Tenga en cuenta que el ALB no tiene listas de permisos de IP ni grupos de seguridad, por lo que la filtración de solicitudes corresponde a los destinos. Esto se construye en el Módulo 3 (equilibrio de carga de capa 7).

Escalado de lecturas en lugar de réplicas de lectura. Las bases de datos administradas en IONOS CLOUD no tienen réplicas de lectura ni replicación nativa a otra instancia administrada. Usted escala las lecturas con una caché de In-Memory DB frente a la capa relacional, junto con la agrupación de conexiones para respetar el límite de conexiones derivado de la RAM de la base de datos. La caché absorbe el tráfico intensivo en lecturas; el agrupador de conexiones mantiene el número de conexiones en un nivel sostenible. Esto se construye en el Módulo 5 (las unidades de base de datos relacional y en memoria).

Conmutación por error automatizada en lugar de un producto de conmutación por error administrado. No existe un servicio de conmutación por error administrado. La sustitución nativa combina las comprobaciones de estado del equilibrador de carga, que desvían el tráfico de un destino no saludable dentro del grupo de backends del equilibrador de carga, con un registro de Cloud DNS de TTL bajo, orquestado por el cliente, que una comprobación de estado externa reorienta para la conmutación por error entre zonas. Cloud DNS en sí no es consciente del estado; sirve el registro que usted configure. Dado que DNS solo dirige nuevas conexiones y está limitado por el TTL del registro, la capa 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 cambios de base de datos. No existe un flujo de captura de datos de cambios administrado desde las bases de datos. La sustitución nativa consiste en publicar eventos desde la propia aplicación, típicamente en Managed Kafka, donde un tema captura los eventos de cambio y los consumidores aguas abajo los leen. La captura se desplaza hacia el código de la aplicación en lugar de conectar al registro de la base de datos. Esto se construye en el Módulo 5 (transmisión de eventos).

Conversión de imágenes en lugar de importación nativa de OVF/OVA. No existe un asistente nativo de importación de OVF/OVA. Migrar una máquina virtual existente es un paso de ingeniería: convertir y cargar la imagen del disco, con los controladores VirtIO instalados y una transición a UEFI preparada, después de lo cual la imagen es utilizable 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 conmutación híbrida).

Asignación por grupos y concesión en lugar de IAM con lenguaje de políticas. No existe un sistema de identidad basado en políticas con gran granularidad. El control de acceso es basado en grupos con concesiones a nivel de recurso: usted asigna privilegios a un grupo y concede a ese grupo acceso a recursos específicos, y no existe regla de denegación, por lo que el principio de privilegio mínimo significa simplemente no conceder. 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 resto del curso.

Para FinCorp, el modelo redefine todo el compromiso. Su carga de trabajo relacional regulada no obtendrá una réplica de lectura administrada, por lo que el diseño ya planifica una ruta de lectura con caché y agrupador. Su entorno de VMware no se importará como OVF/OVA, por lo que el plan de migración ya asume la conversión de imágenes (junto con las rutas nativas de VMware cubiertas más adelante). Su modelo de acceso no aplicará una política de denegación, por lo que la gobernanza se diseña como una concesión deliberada y mínima. Ninguna de estas es una solución alternativa descubierta tarde bajo presión; cada una es un patrón conocido seleccionado desde el principio porque el arquitecto mantuvo el modelo de sustitución desde el inicio.

Resumen de la decisión

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

La disciplina consiste en no inferir nunca una función a partir del nombre de un producto o de un análogo de un proveedor de nube a gran escala. Declare el límite con claridad y luego componga el patrón.

Resumen

IONOS CLOUD compone capacidades a partir de primitivas en lugar de venderlas como funciones administradas individuales. Por lo tanto, varios elementos que un arquitecto podría esperar como productos, como una pasarela de API, réplicas de solo lectura, conmutación por error administrada, captura de datos de cambios, importación de OVF/OVA e IAM basado en políticas, se entregan como sustituciones nativas: reglas de ALB junto con ingress, caché junto con agrupación, comprobaciones de estado de LB junto con reorientación de DNS con TTL bajo, eventos a nivel de aplicación, conversión de imágenes y asignación de grupos y permisos. Mantener este modelo convierte las aparentes carencias en patrones conocidos y convierte el resto del curso en el lugar donde se construye cada sustitución.

Puntos clave:

• La plataforma incluye primitivas y espera su composición; un producto administrado ausente es un elemento de diseño, no un defecto.
• Las seis sustituciones principales son: enrutamiento de contenido (ALB + ingress), escalado de lectura (caché + agrupación), conmutación por error (comprobaciones de estado de LB + reorientación de DNS orquestada por el cliente), captura de datos de cambios (eventos de la aplicación), importación de VM (conversión de imágenes) y control de acceso (asignación de grupos y permisos).
• Cada sustitución conlleva una restricción que debe planificarse, y cada una anticipa el módulo posterior que la construye.
• Nunca infiera una capacidad a partir de un nombre de producto o de un análogo de un proveedor de nube a gran escala; confirme el límite y, a continuación, componga el patrón nativo.