Unidad 8.2: La arquitectura empresarial de referencia

Introducción

Cada unidad anterior tomó una decisión de forma aislada: una clase de cómputo, un modo de replicación, una capa de equilibrador de carga, un mecanismo de conmutación por error. Esta unidad los coloca todos en un mismo lienzo a la vez. El propósito no es volver a enseñar ningún producto, sino mostrar cómo se combinan las decisiones, cómo una elección en una capa restringe una elección en otra, y cómo los límites honestos de la plataforma dan forma al panorama completo, no solo a la parte que los toca.

La arquitectura de referencia es la de FinCorp: una empresa alemana de servicios financieros sujeta al RGPD y a la supervisión del BSI, que está migrando un gran entorno de VMware y estableciendo una capacidad de IA. Es la acumulación de todas las decisiones tomadas a lo largo de los Módulos 1 a 7, representada como un único sistema. Trátela como una plantilla que usted instancia, no como un diagrama que copia.

1. El sistema ensamblado

El diseño se organiza según la forma por capas canónica de la Unidad 1.2: un borde público de capa 7, un nivel de cálculo sin estado, un equilibrador privado de capa 4 y un nivel de datos solo privado. Alrededor de esa columna vertebral se encuentran el entorno dedicado de VMware, la plataforma de contenedores, el nivel de IA y los enlaces híbridos hacia las instalaciones de FinCorp. Todo reside dentro de un único contrato (el límite de gobernanza y facturación de la Unidad 2.1) y está segmentado en Centros de Datos Virtuales por región y entorno.

1.1 Segmentación y la ruta por capas

Una LAN en IONOS CLOUD es privada hasta que se conecta al acceso a internet (Unidad 3.1). El VDC de producción de FinCorp lleva tres LAN: una LAN de borde público, una LAN de aplicaciones privada y una LAN de datos privada. El tráfico norte-sur entra en el borde público; el tráfico este-oeste entre niveles permanece en LAN privadas y nunca atraviesa una IP pública.

La ruta de la solicitud es deliberadamente por capas. Un Managed Application Load Balancer (ALB) público termina TLS en el borde y enruta según atributos de capa 7; sirve como dispositivo de borde que maneja el tráfico norte-sur que entra y sale del centro de datos. Detrás de él se encuentra el nivel de aplicaciones sin estado en cálculo Dedicated Core. Esos servidores alcanzan el nivel de datos a través de un Managed Network Load Balancer (NLB) privado, que transmite TCP de capa 4 a los puntos de acceso de la base de datos y maneja el tráfico este-oeste dentro del centro de datos. La composición de ALB público a NLB privado (Unidades 3.3 y 3.4) es la columna vertebral del equilibrio de carga: consciente del contenido en el borde donde la lógica de enrutamiento importa, y passthrough TCP rápido internamente donde no importa.

El nivel de aplicaciones es sin estado a propósito. Esa precondición es lo que le permite auto-escalar (Unidad 4.3) y lo que permite al equilibrador de carga frontal trasladar nuevas conexiones a réplicas sanas sin dejar estado de sesión a la deriva. El estado de sesión y de lectura se externaliza al nivel de caché en memoria, en lugar de mantenerse en los servidores.

1.2 VMware dedicado para procesamiento regulado

El núcleo regulado de FinCorp se ejecuta en IONOS CLOUD Private Cloud: un SDDC dedicado de VMware administrado (vSphere Enterprise Plus, vSAN, NSX-T) en hardware de inquilino único, con licencias incluidas en lugar de aportadas (Unidad 4.4). La tenencia única es el motor del diseño aquí: las cargas de trabajo que tienen los requisitos más estrictos de aislamiento y previsibilidad se encuentran en hardware que ningún otro inquilino comparte. La aprovisionamiento es una participación guiada, no una acción de consola de autoservicio, por lo que esta parte del entorno se diseña en lugar de construirse en el Data Center Designer.

El entorno de VMware no es una isla. Se conecta al borde elástico de cálculo estándar a través de la conectividad híbrida descrita a continuación, lo que da a FinCorp el patrón híbrido probado: un núcleo de VMware dedicado para procesamiento regulado y de estado estable, más cálculo estándar elástico para carga de borde variable. La pila de VMware aquí es NSX-T 3.2 con vCenter para gestión intraclúster; las únicas herramientas de movilidad y replicación de VMware en el alcance son las que la plataforma realmente proporciona, cubiertas bajo migración a continuación.

1.3 Managed Kubernetes para contenedores

Los servicios nuevos y refactorizados se ejecutan en Managed Kubernetes (Unidad 6.1). El plano de control está administrado y es gratuito; FinCorp paga por los grupos de nodos, que tienen su propio SLA separado del plano de control. El clúster se conecta a la forma por capas a través de un equilibrador de carga aprovisionado por separado más un controlador de entrada intraclúster, porque un manifiesto de Kubernetes no aprovisiona automáticamente un equilibrador de carga administrado de IONOS CLOUD. Un Service de tipo LoadBalancer se resuelve a una IP estática de un solo nodo, no a un equilibrador administrado, por lo que la ruta de entrada de producción es un ALB frente a un controlador de entrada intraclúster. Esta es la sustitución de la pasarela de API realizada: las reglas de ruta del ALB más la entrada intraclúster sustituyen a una pasarela de API administrada, que IONOS CLOUD no vende.

La seguridad en el clúster se divide honestamente. Los Network Security Groups y los firewalls de NIC se unen a las NIC de los nodos de trabajo, no a la abstracción del clúster, por lo que el control de pod a pod se aplica con políticas de red intraclúster. Las imágenes de contenedor provienen del Container Registry, gobernadas por la disciplina de tokens (un token de alcance estrecho por etapa de la tubería, con caducidad y rotación; los tokens se eliminan, no se desactivan) porque el registro no tiene RBAC.

1.4 La plataforma de datos

El nivel de datos es solo de punto de acceso privado y está compuesto por varios motores administrados, cada uno adaptado a un patrón de acceso:

• Relacional (Managed PostgreSQL / MariaDB): el sistema de registro. No hay réplicas de lectura. La replicación es intraclúster (PostgreSQL asíncrono por defecto, con modos síncrono y estrictamente síncrono disponibles; MariaDB solo asíncrono) para durabilidad y auto-promoción intraclúster, no para escalado de lectura.
• Caché en memoria: la capa de escalado de lectura y externalización de estado (Unidad 5.5). Está frente al nivel relacional y absorbe la carga de lectura, y mantiene el estado de sesión retirado del nivel de aplicaciones sin estado. Esta caché es lo que hace que funcionen tanto el patrón sin réplicas de lectura como el auto-escalado seguro; no es una decoración opcional.
• Documento (Managed MongoDB): para las cargas de trabajo cuya forma se adapta mejor a un modelo de documento que a filas relacionales.
• Streaming (Managed Kafka): la columna vertebral de ingesta y la sustitución de la captura de cambios de datos. Como no hay un flujo de cambios de base de datos administrado, las aplicaciones publican eventos a Kafka a nivel de aplicación. Las particiones son la unidad de orden y paralelismo del consumidor; el diseño de tema y partición es la decisión que soporta la carga.
• Archivo de objetos (Object Storage): el almacén de espacio de nombres plano compatible con S3 que sirve como destino de copia de seguridad, archivo de auditoría, almacén de conjuntos de datos y artefactos, y la cola de letras muertas y archivo para Kafka. El bloqueo de objetos proporciona retención con evidencia de manipulación.

1.5 El nivel de IA

La capacidad de IA de FinCorp predetermina la inferencia administrada en el AI Model Hub: una API de inferencia compatible con OpenAI, precios por token, sin estado, con residencia de datos en la UE y procesamiento en el país. La generación aumentada por recuperación se construye por el cliente a partir de partes de la plataforma: incrustaciones del hub, vectores almacenados en Managed PostgreSQL y el corpus de origen en Object Storage. La función de almacén de vectores administrado del hub se evita en favor de este patrón compuesto, que mantiene el almacén de recuperación bajo la gobernanza de base de datos propia de FinCorp.

1.6 Conectividad híbrida

Las instalaciones de FinCorp y su entorno de VMware alcanzan la nube a través de las primitivas de conectividad de la Unidad 3.6. Un VPN Gateway (IKEv2 o WireGuard, sin IKEv1; HA activo-pasivo que comparte una IP pública) transporta el tráfico cifrado de sitio a nube. Un NAT Gateway proporciona salida saliente para cargas de trabajo privadas que no tienen IP pública; es solo SNAT, por lo que es una ruta de salida, nunca un punto de entrada entrante. Private Cross-Connect conecta VDC en la misma región y contrato a través de un interconexión privada compartida, incluido el tráfico de nodos entre VDC en el que un clúster de Kubernetes privado depende.

1.7 Resiliencia, observabilidad y costo como el sobre de operación

La resiliencia (Unidad 7.1) se basa en primitivas de la plataforma en lugar de un producto de conmutación por error administrado, que no existe. Los pares redundantes se colocan en zonas de disponibilidad explícitas (nunca Auto, que puede co-localizarlos), y los equilibradores de carga administrados realizan comprobaciones de salud en sus objetivos y dejan de enrutar a un backend fallido; Cloud DNS proporciona resolución anycast y un TTL mínimo bajo para una propagación rápida de registros, pero no realiza conmutación por error nativa basada en comprobaciones de salud. El plano de desvío de tráfico (DNS) se mantiene separado del plano de continuidad de datos (copias de seguridad, instantáneas, PITR, archivo de Object Storage). La observabilidad (Unidad 7.2) abarca cuatro planos de telemetría de alcance fijo, métricas, registros, auditoría y registros de flujo de red, abanicados hacia un SIEM externo porque no hay agregación entre contratos y los eventos del plano de control de Kubernetes no fluyen a través del servicio de registro. El costo (Unidad 2.4) se gobierna por asignación por contrato y VDC, almacenamiento por capas según el patrón de acceso, y Savings Plans comprometidos con el piso de estado estable.

2. Preocupaciones transversales, no funciones aisladas

La arquitectura solo se mantiene cohesionada porque cuatro preocupaciones atraviesan cada nivel, en lugar de estar confinadas en un solo componente.

La alta disponibilidad se compone, no se compra. El ALB y el NLB de borde son gestionados y resilientes; los nodos de cómputo y de datos redundantes se distribuyen en zonas explícitas; los equilibradores de carga gestionados realizan comprobaciones de estado en sus objetivos y enrutan alrededor de los backends fallidos; y el entorno dedicado de VMware añade tolerancia a fallos de vSAN y HA de vSphere dentro de su clúster. Ningún producto individual ofrece HA de extremo a extremo; el diseño superpone estos mecanismos.

El equilibrio de carga aparece en dos niveles por dos razones. La capa 7 en el borde público proporciona enrutamiento consciente del contenido y terminación de TLS; la capa 4 internamente proporciona paso rápido de TCP, manteniendo el backend su propio certificado. Ningún equilibrador gestionado acepta un Network Security Group ni una lista de permisos de IP, por lo que el filtrado debe aplicarse en los objetivos que se encuentran detrás de ellos.

La seguridad se aplica donde tiene efecto: firewalls de NIC y NSGs en las NIC de los servidores y workers, políticas de red dentro del clúster en Kubernetes, disciplina de tokens en el registro y control de acceso basado en grupos y concesiones a lo largo del contrato. No existe un IAM con lenguaje de políticas ni reglas de denegación; el privilegio mínimo se logra mediante la no concesión, y la federación (SAML/OIDC) es solo autenticación, por lo que el proceso de alta, cambio y baja de usuarios es un runbook manual.

La conectividad une el entorno: LAN privadas para el tráfico este-oeste entre niveles, VPN para la conexión entre sitio y nube, NAT para la salida privada y Cross-Connect para enlaces entre VDC en la misma región. La topología en sí misma es un control de seguridad, porque aislar el nivel de datos en una LAN privada es lo que compensa la falta de soporte de NSG en los equilibradores gestionados.

La siguiente tabla asocia cada límite de capacidad de IONOS CLOUD con el patrón nativo que lo compone, tal como se materializa en esta arquitectura.

La migración al núcleo regulado de VMware utiliza únicamente las herramientas que la plataforma proporciona: VMware Cloud Director Availability (VCDA, versión 4.7.x) para replicación asíncrona, migración y conmutación por error en vivo, a un coste aproximado de 50 EUR por VM protegida al mes; VPN de capa 2 integrada en NSX-T para la extensión de red de capa 2 (una función estándar de borde de NSX-T, no un complemento con licencia separada); y vMotion intraclúster. vMotion es solo intraclúster y no es una capacidad de movilidad en vivo entre sitios. Las Workloads que no tienen una ruta nativa de VMware se realojan mediante conversión y carga de imágenes, y las bases de datos se migran mediante volcado y restauración, ya que el Backup Service no cubre las bases de datos gestionadas.

Resumen de la decisión

El elemento fundamental de la arquitectura de referencia es el mapa por servicio: dónde se coloca cada componente y exactamente qué reconocimiento BSI lo cubre. El cumplimiento se delimita por servicio y por ubicación del centro de datos, nunca a nivel de plataforma, por lo que el mapa es lo que lee un auditor. BSI C5 es una atestación de Tipo 1 (Testat) concedida el 2023-11-07; IT-Grundschutz es un certificado ISO 27001 concedido el 2022-09-14 (BSI). Ambos aplican a los centros de datos alemanes, y sus ámbitos difieren según el servicio. IONOS CLOUD es el primer proveedor de nube alemán que posee ambos.

Dos reglas de lectura rigen esta tabla. En primer lugar, "dentro del alcance" significa que el servicio nombrado en los centros de datos alemanes posee ese reconocimiento BSI; nunca autoriza una afirmación a nivel de plataforma. C5 cubre exactamente Compute Engine, Cloud Cubes y S3 Object Storage; IT-Grundschutz cubre exactamente Compute Engine, S3 Object Storage, Backup y Managed Kubernetes. Los dos ámbitos divergen: Cubes están bajo C5 pero no bajo IT-Grundschutz, mientras que Managed Kubernetes y Backup están bajo IT-Grundschutz pero no bajo C5. En segundo lugar, el filtro de soberanía de la Unidad 1.4 se aplica al final, sobre todo el diseño: cada componente se opera bajo jurisdicción de la UE, lo cual es una propiedad del operador y no solo de la región.

Los dos errores de composición contra los que debe verificarse el diseño ensamblado son: emparejar primitivas incompatibles (por ejemplo, esperar que un NSG proteja un equilibrador gestionado, o recurrir a un Cross-Connect para unir dos VDC en diferentes regiones) y colocar un servicio funcionalmente correcto fuera de su alcance de atestación requerido (por ejemplo, ejecutar procesamiento regulado requerido por C5 en un servicio que C5 no cubre).

Resumen

La arquitectura empresarial de referencia es el curso completo representado como un único sistema: una ruta por capas, desde el nivel público L7 hasta el nivel privado L4, sobre una capa de computación sin estado y una plataforma de datos privada, con un núcleo VMware dedicado para el procesamiento regulado, Managed Kubernetes para contenedores, una capa de IA que utiliza inferencia administrada de forma predeterminada, y enlaces híbridos que la vinculan a las instalaciones de FinCorp. La alta disponibilidad, el equilibrio de carga, la seguridad y la conectividad no son funciones dentro de recuadros, sino preocupaciones que atraviesan cada capa, y el conjunto de sustitución nativa es lo que cubre las lagunas que la plataforma no ofrece deliberadamente como productos administrados. La colocación por servicio y el mapa de cumplimiento son los elementos que hacen que el diseño sea defendible durante una auditoría.

Puntos clave:

• La forma por capas es la columna vertebral; todo lo demás (núcleo VMware, Kubernetes, IA, motores de datos, enlaces híbridos) se adjunta a ella, y la segmentación junto con la privacidad por defecto determinan la disposición.
• La alta disponibilidad, el equilibrio de carga, la seguridad y la conectividad son transversales: cada una se compone a través de las capas a partir de primitivas de la plataforma, y no se entregan mediante un único producto.
• El conjunto de sustitución nativa se implementa de extremo a extremo: enrutamiento de API mediante ALB más ingress, escalado de lectura mediante caché, conmutación por error mediante comprobaciones de estado de los objetivos del equilibrador de carga en puntos finales zonificados, CDC mediante Kafka, importación de VM mediante conversión de imagen, y acceso mediante grupo y concesión.
• El cumplimiento es por servicio y por ubicación del centro de datos: C5 (certificación de tipo 1, 2023-11-07) e IT-Grundschutz (certificado ISO 27001, 2022-09-14) tienen alcances de servicio diferentes, y el mapa de colocación codifica ambos.
• El núcleo VMware regulado utiliza únicamente VCDA, VPN L2 de NSX-T y vMotion intraclúster; no hay movilidad en vivo entre sitios, y las bases de datos se migran mediante volcado y restauración.

Lectura adicional

• Unidad 8.1: Marcos de decisión de arquitectura (las matrices de selección que este diseño instancia)
• Unidad 8.3: Laboratorio de título, que construye el núcleo empresarial de FinCorp de principio a fin en Data Center Designer
• Unidad 1.2: La arquitectura por capas canónica; Unidad 1.3: El modelo de sustitución nativa; Unidad 1.4: La soberanía y el cumplimiento como entradas de diseño
• Centro de arquitectura de IONOS CLOUD