Unidad 8.2: La Arquitectura Empresarial de Referencia
Introducción
Cada unidad anterior decidió una cosa en aislamiento: una clase de cómputo, un modo de replicación, una capa de equilibrio de carga, un mecanismo de conmutación por error. Esta unidad los combina en un solo lienzo al mismo tiempo. El propósito no es volver a enseñar ningún producto, sino mostrar cómo las decisiones se componen, dónde una elección en un nivel restringe una elección en otro, y cómo los límites honestos de la plataforma dan forma a la imagen completa en lugar de solo a la parte que los toca.
La arquitectura de referencia es la de FinCorp: una empresa de servicios financieros alemana bajo la supervisión de GDPR y BSI, que migra un gran VMware y establece una capacidad de inteligencia artificial. Es la acumulación de cada decisión tomada en los Módulos 1 a 7, dibujada como un sistema único. Trátelo como una plantilla que se instancia, no como un diagrama que se copia.
1. El sistema ensamblado
El diseño se organiza según la forma en capas canónica del Módulo 1.2: un borde público de capa 7, un nivel de computación sin estado, un equilibrador de carga de capa 4 privado y un nivel de datos privado. Alrededor de esta columna vertebral se encuentran el conjunto dedicado de VMware, la plataforma de contenedores, el nivel de inteligencia artificial y los enlaces híbridos a las instalaciones de FinCorp. Todo se encuentra dentro de un contrato (el límite de gobernanza y facturación del Módulo 2.1) y se segmenta en centros de datos virtuales por región y entorno.
1.1 Segmentación y camino en capas
Un LAN en IONOS es privado hasta que se conecta al acceso a Internet (Unidad 3.1). El VDC de producción de FinCorp lleva tres LAN: un borde público LAN, una aplicación privada LAN y un LAN de datos privado. 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 un IP público.
El camino de la solicitud se organiza deliberadamente. Un Managed Application Load Balancer público (ALB) termina TLS en el borde y enruta según atributos de capa 7; sirve como el dispositivo de borde que maneja el tráfico norte-sur hacia y desde el centro de datos. Detrás de él se encuentra el nivel de aplicación sin estado en Dedicated Core compute. Esos servidores llegan al nivel de datos a través de un Managed Network Load Balancer privado (NLB), que pasa el tráfico TCP de capa 4 a los puntos de conexión 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 de equilibrio de carga: consciente de contenido en el borde donde la lógica de enrutamiento es importante, rápido paso de TCP interno donde no es importante.
El nivel de aplicación es sin estado a propósito. Esa precondición es lo que permite que se auto-escala (Unidad 4.3) y que el Load Balancer de front-end pueda cambiar nuevas conexiones a réplicas sanas sin dejar estado de sesión. El estado de sesión y lectura se externalizan a la capa 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 Private Cloud: un VMware SDDC (vSphere Enterprise Plus, vSAN, NSX-T) gestionado en hardware de un solo inquilino, con licencia incluida en lugar de traída (Unidad 4.4). El uso de un solo inquilino es el conductor del diseño aquí: las cargas de trabajo que llevan los requisitos de aislamiento e isolación más estrictos se encuentran en hardware que no comparte ningún otro inquilino. La provisión es un compromiso guiado, no una acción de consola de auto-servicio, por lo que esta parte del conjunto se diseñó en lugar de construirse en el Data Center Designer.
El conjunto de VMware no es una isla. Se conecta al borde de computación estándar elástico a través de la conectividad híbrida descrita a continuación, lo que da a FinCorp el patrón de híbrido probado: un núcleo de VMware dedicado para procesamiento regulado y estable, más computación estándar elástica para carga de borde variable. La pila de VMware aquí es NSX-T 3.2 con vCenter para administración en Cluster; la única herramienta de movilidad y replicación de VMware en el alcance es lo que la plataforma proporciona en realidad, cubierta bajo migración a continuación.
1.3 Managed Kubernetes para contenedores
Los nuevos servicios y los servicios reestructurados se ejecutan en Managed Kubernetes (Unidad 6.1). El plano de control es gestionado y gratuito; FinCorp paga por Node Pools, que llevan su propio Acuerdo de Nivel de Servicio (SLA) separado del plano de control. El Cluster se conecta a la forma en capas a través de un Load Balancer provisionado por separado y un controlador de entrada en Cluster, porque un manifiesto de Kubernetes no auto-provisiona un Load Balancer gestionado por IONOS. Un servicio de tipo LoadBalancer se resuelve en una dirección IP estática de un solo Node, no un equilibrador de carga gestionado, por lo que la ruta de entrada de producción es un ALB frente a un controlador de entrada en Cluster. Esto es la sustitución de la puerta de enlace API realizada: las reglas de ruta de ALB más el controlador de entrada en Cluster sustituyen un API Gateway gestionado, que IONOS no vende.
La seguridad en el Cluster se divide honestamente. Los firewalls de Network Security Groups y NIC se unen a las NIC de los trabajadores Node, no a la abstracción de Cluster, por lo que el control de pod a pod se aplica con políticas de red en Cluster. Las imágenes de contenedor provienen del Registro de contenedores, gobernado por la disciplina de token (un token estrechamente definido por cada etapa de pipeline, con expiración y rotación; los tokens se eliminan, no se deshabilitan) porque el registro no tiene RBAC.
1.4 La plataforma de datos
El nivel de datos es solo de punto de conexión privado y se compone de varios motores gestionados, cada uno coincidiendo con un patrón de acceso:
- Relacional (Managed PostgreSQL / MariaDB): el sistema de registro. No hay réplicas de lectura. La replicación es en Cluster (PostgreSQL asíncrono por defecto, con modos síncrono y estrictamente síncrono disponibles; MariaDB asíncrono solo) para durabilidad y auto-promoción intra-Cluster, no para escalado de lectura.
- Caché en memoria: la capa de escalado de lectura y externalización de estado (Unidad 5.5). Se encuentra frente al nivel relacional y absorbe la carga de lectura, y mantiene el estado de sesión levantado del nivel de aplicación 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.
- Documental (Managed MongoDB): para las cargas de trabajo cuya forma se adapta mejor a un modelo de documento que a filas relacionales.
- Transmisión (Managed Kafka): la columna vertebral de ingesta y el sustituto de captura de cambios de datos. Dado que no hay una transmisión de cambios de base de datos gestionada, las aplicaciones publican eventos en 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 objetivo de copia de seguridad, archivo de auditoría, almacén de conjuntos de datos y artefactos, y la cola de letras muertas y archivo de cola para Kafka. El bloqueo de objeto proporciona retención con evidencia de manipulación.
1.5 El nivel de inteligencia artificial
La capacidad de inteligencia artificial de FinCorp predetermina la inferencia gestionada en el AI Model Hub: un motor de inferencia de API compatible con OpenAI, con precios por token, sin estado, con residencia de datos de la UE y procesamiento en el país. La generación aumentada de recuperación es construida 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 gestionado del hub se evita a favor de este patrón compuesto, que mantiene el almacén de recuperación bajo la gobernanza de base de datos de FinCorp.
1.6 Conectividad híbrida
Las instalaciones de FinCorp y su conjunto de VMware llegan a la nube a través de los primitivos de conectividad de la Unidad 3.6. Un VPN Gateway (IKEv2 o WireGuard, no IKEv1; con conmutación automática de alta disponibilidad que comparte una dirección IP pública) transporta tráfico de sitio a nube cifrado. Un NAT Gateway proporciona salida para trabajos privados que no tienen una dirección IP pública; solo es SNAT, por lo que es una ruta de salida, nunca un punto de entrada de entrada. Los enlaces de Cross-Connect privados enlazan VDC en la misma región y contrato a través de una interconexión privada compartida, incluido el tráfico de Node entre VDC que depende de un Kubernetes privado Cluster.
1.7 Resiliencia, observabilidad y costo como sobreenvoltura de operación
La resiliencia (Unidad 7.1) se basa en primitivos de plataforma en lugar de un producto de conmutación por error gestionado, 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 gestionados verifican la salud de sus objetivos y dejan de enrutar a un backend fallido; Cloud DNS proporciona resolución anycast y un tiempo de vida mínimo bajo para una propagación rápida de registros, pero no realiza conmutación por error basada en verificación de salud nativa. El plano de dirección de tráfico (DNS) se mantiene separado del plano de continuidad de datos (copias de seguridad, instantáneas, PITR, archivo Object Storage). La observabilidad (Unidad 7.2) abarca cuatro planos de telemetría de alcance fijo, métricas, registros, auditoría y Flow Logs de red, que se ramifican a 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 Logging Service. El costo (Unidad 2.4) se gobierna mediante asignación por contrato y VDC, almacenamiento escalonado según patrón de acceso, y Planes de ahorro comprometidos con el piso de estado estable.
2. Preocupaciones transversales, no características aisladas
La arquitectura solo se mantiene unida porque cuatro preocupaciones se extienden por cada nivel, en lugar de vivir en una sola caja.
Alta disponibilidad se compone, no se compra. El ALB y NLB de borde son administrados y resistentes; los nodos de cómputo y datos redundantes se colocan en zonas explícitas; los equilibradores de carga administrados realizan comprobaciones de salud de sus objetivos y rodean los backends fallidos; y el patrimonio dedicado VMware agrega tolerancia a fallos vSAN y vSphere HA dentro de su Cluster. Ningún producto único ofrece alta disponibilidad de extremo a extremo; el diseño capa estos mecanismos.
Equilibrio de carga aparece a dos altitudes por dos razones. La capa 7 en el borde público ofrece enrutamiento consciente de contenido y terminación TLS; la capa 4 internamente ofrece paso rápido de TCP con el backend manteniendo su propio certificado. Ningún equilibrador de carga administrado acepta un Grupo de Seguridad de Red o una lista de permitidos IP, por lo que el filtrado pertenece a los objetivos detrás de ellos.
Seguridad se aplica donde se une: firewalls de NIC y NSG en NIC de servidor y trabajador, políticas de red dentro de Cluster en Kubernetes, disciplina de tokens en el registro y control de acceso de grupo y concesión en todo el contrato. No hay lenguaje de política IAM y no hay regla de denegación; el privilegio mínimo se logra no otorgando, y la federación (SAML/OIDC) es solo autenticación, por lo que el proceso de unión-movimiento-salida es un libro de ejecución manual.
Conectividad une el patrimonio: LAN privadas para tráfico de nivel este-oeste, VPN para sitio-nube, NAT para salida privada y Cross-Connect para enlaces de VDC cruzados en la misma región. La topología en sí es un control de seguridad, porque aislar el nivel de datos en una LAN privada es lo que compensa la falta de soporte NSG de los equilibradores de carga administrados.
La siguiente tabla asigna cada límite de capacidad de IONOS a un patrón nativo que se compone alrededor de él, realizado en esta arquitectura.
| Capacidad no vendida como característica administrada | Patrón nativo en este diseño | Donde vive |
|---|---|---|
| Administrado API Gateway | Reglas de ruta de capa 7 de ALB más controlador de entrada dentro de Cluster | Borde a Kubernetes |
| Replicas de lectura | Caché en memoria más agrupación de conexiones frente al nivel relacional | Nivel de datos |
| Producto de conmutación administrada | Comprobaciones de salud de objetivos de equilibrador de carga en puntos de conexión zonificados, con DNS de baja TTL para propagación de registros | Avión de resiliencia |
| Captura de datos de cambio de base de datos | Publicación de eventos de nivel de aplicación a Administrado Kafka | Nivel de transmisión |
| Importación nativa de OVF/OVA | Conversión de imagen y carga (controladores VirtIO, preparación UEFI) | Migración |
| Lenguaje de política IAM | Control de acceso de recursos de grupo y concesión | Gobernanza |
La migración al núcleo regulado VMware utiliza solo la herramienta que proporciona la plataforma: Director de disponibilidad de VMware Cloud (VCDA, versión 4.7.x) para replicación, migración y conmutación en vivo asincrónica a unos 50 EUR por VM protegido por mes; L2 VPN integrado de NSX-T para extensión de red de capa 2 (una característica estándar de NSX-T Edge, no un complemento con licencia separada); y vMotion intra-Cluster. vMotion es solo intra-Cluster y no es una capacidad de movilidad en vivo entre sitios. Las cargas de trabajo sin camino nativo VMware se reorganizan a través de la conversión y carga de imágenes, y las bases de datos migran mediante volcado y restauración, ya que Backup Service no cubre bases de datos administradas. Además, se utilizan VPN, NAT y LAN para garantizar la conectividad y la seguridad. También se utilizan Kubernetes y Cluster para proporcionar una infraestructura escalable y segura. Finalmente, se utilizan DNS, IP y VM para garantizar la alta disponibilidad y la escalabilidad de la arquitectura. Y por último, se utilizan API Gateway, SAML, IAM, TLS y Kafka para proporcionar una solución completa y segura.
Resumen de la decisión
El artefacto que soporta la carga de la arquitectura de referencia es el mapa de servicio por servicio: donde se coloca cada componente y exactamente qué reconocimiento de BSI lo cubre. El cumplimiento se limita 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 acreditación de tipo 1 (Testat) otorgada el 2023-11-07; IT-Grundschutz es un certificado ISO 27001 otorgado el 2022-09-14 (BSI). Ambos se aplican a centros de datos alemanes, y sus alcances difieren por servicio. IONOS es el primer proveedor de servicios en la nube alemán en poseer ambos.
| Componente | Servicio de IONOS | Colocación | BSI C5 (acreditación, Tipo 1, 2023-11-07) | IT-Grundschutz (certificado ISO 27001, 2022-09-14) |
|---|---|---|---|---|
| Enrutamiento de borde público | ALB administrado | Borde público LAN | Fuera del alcance | Fuera del alcance |
| Equilibrio de carga de datos internos | NLB administrado | Datos privados LAN | Fuera del alcance | Fuera del alcance |
| Capa de aplicaciones sin estado | Compute Engine (Núcleo dedicado) | Aplicación privada LAN | Dentro del alcance | Dentro del alcance |
| Instancias de plantilla fija | Cloud Cubes | Aplicación privada LAN | Dentro del alcance | Fuera del alcance |
| Plataforma de contenedores | Managed Kubernetes | Aplicación privada LAN | Fuera del alcance | Dentro del alcance |
| Sistema de registro | Managed PostgreSQL / MariaDB | Datos privados LAN (punto de conexión privado) | Fuera del alcance | Fuera del alcance |
| Capa de caché / estado | In-Memory DB | Datos privados LAN (punto de conexión privado) | Fuera del alcance | Fuera del alcance |
| Almacén de documentos | Managed MongoDB | Datos privados LAN (punto de conexión privado) | Fuera del alcance | Fuera del alcance |
| Espina dorsal de eventos | Kafka administrado | Datos privados LAN | Fuera del alcance | Fuera del alcance |
| Archivo de objetos | S3 Object Storage | Regional | Dentro del alcance | Dentro del alcance |
| Copia de seguridad de VM / Volume | Backup Service | Entre niveles | Fuera del alcance | Dentro del alcance |
| Núcleo regulado | Private Cloud (núcleo dedicado VMware) | SDDC de un solo inquilino | Limitado a sus propias acreditaciones de SDDC, no a la plataforma C5 | Limitado por separado |
Dos reglas de lectura gobiernan esta tabla. Primero, "dentro del alcance" significa que el servicio con nombre en centros de datos alemanes lleva ese reconocimiento de BSI; nunca licencia 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, Copia de seguridad y Managed Kubernetes. Los dos alcances divergen: Cubes se encuentran bajo C5 pero no bajo IT-Grundschutz, mientras que Managed Kubernetes y Copia de seguridad se encuentran bajo IT-Grundschutz pero no bajo C5. Segundo, el filtro de soberanía de la Unidad 1.4 se aplica al final, sobre todo el diseño: cada componente se opera bajo la jurisdicción de la Unión Europea, lo que es una propiedad del operador y no solo de la región.
Los dos errores de composición que se deben verificar en el diseño ensamblado son emparejar primitivos incompatibles (por ejemplo, esperar que un NSG proteja un equilibrador administrado, o alcanzar un Cross-Connect para unir dos VDC en diferentes regiones) y colocar un servicio funcionalmente correcto fuera de su alcance de acreditación requerido (por ejemplo, ejecutar procesamiento regulado requerido por C5 en un servicio que C5 no cubre).
Resumen
La arquitectura empresarial de referencia es todo el curso dibujado como un sistema: una ruta pública-L7-a-privada-L4 en capas sobre una capa de computación sin estado y una plataforma de datos privada, con un núcleo dedicado de VMware para procesamiento regulado, Managed Kubernetes para contenedores, un nivel de inteligencia artificial que predetermina la inferencia gestionada, y enlaces híbridos que lo unen a las instalaciones de FinCorp. La alta disponibilidad, el equilibrio de carga, la seguridad y la conectividad no son características en cajas, sino preocupaciones que se extienden por cada nivel, y el conjunto de sustitución nativa es lo que llena los vacíos que la plataforma deliberadamente no vende como productos gestionados. El mapa de colocación y cumplimiento servicio por servicio es el artefacto que hace que el diseño sea defendible bajo auditoría.
Puntos clave:
- La forma en capas es la columna vertebral; todo lo demás (núcleo de VMware, Kubernetes, inteligencia artificial, motores de datos, enlaces híbridos) se adjunta a ella, y la segmentación más la privacidad por defecto impulsan el diseño.
- La alta disponibilidad, el equilibrio de carga, la seguridad y la conectividad son transversales: cada una se compone a través de los niveles desde primitivos de plataforma, no se entrega mediante un solo producto.
- El conjunto de sustitución nativa se realiza de extremo a extremo: enrutamiento de API a través de ALB más ingreso, escalado de lectura a través de caché, conmutación por error a través de comprobaciones de salud de objetivos de equilibrio de carga en puntos de conexión zonificados, CDC a través de Kafka, importación de VM a través de conversión de imagen, acceso a través de grupo y concesión.
- El cumplimiento es por servicio y por ubicación de centro de datos: C5 (atestación de tipo 1, 2023-11-07) y IT-Grundschutz (certificado de ISO 27001, 2022-09-14) tienen diferentes alcances de servicio, y el mapa de colocación codifica ambos.
- El núcleo regulado de VMware solo utiliza VCDA, NSX-T L2 VPN y vMotion intra-Cluster; no hay movilidad en vivo entre sitios, y las bases de datos migran mediante volcado y restauración.
Lectura adicional
- Unidad 8.1: Marcos de decisión de arquitectura (las matrices de selección que esta diseño instancia)
- Unidad 8.3: Laboratorio de coronación, que construye el núcleo empresarial de FinCorp de extremo a extremo en el Data Center Designer
- Unidad 1.2: La arquitectura en capas canónica; Unidad 1.3: El modelo de sustitución nativa; Unidad 1.4: Soberanía y cumplimiento como entradas de diseño
- Centro de arquitectura de IONOS Cloud