Unidad 8.1: Marcos de decisión de arquitectura
Introducción
En este punto del curso, cada primitivo ha sido examinado en profundidad. Esta unidad no los vuelve a enseñar. Es un artefacto de referencia: un conjunto de matrices de selección a las que usted puede volver cuando un nivel de FinCorp necesita una decisión y usted quiere el criterio de diferenciación, la restricción dura que puede descartar una opción de inmediato, y la unidad que deriva la razón, todo en un solo lugar.
Lea cada matriz de la misma manera. Los criterios de diferenciación reducen el campo. Las restricciones de elegibilidad absolutas son absolutas: una sola restricción fallida elimina una opción, no importa cómo se puntúe en otros aspectos. La soberanía y el alcance de la acreditación se aplican al final, en todo el diseño, porque el cumplimiento normativo reduce las opciones en lugar de originarlas. La unidad termina con las dos formas en que un diseño técnicamente sólido aún puede fallar: emparejar primitivos que no se componen, y colocar un servicio funcionalmente correcto fuera del alcance de acreditación que el Workload requiere.
1. Selección de la clase de cómputo
La decisión de cómputo es una división de cuatro ejes a través de la isolación del núcleo, el control de la familia CPU, la conexión de almacenamiento en bloque y el modelo operativo. La restricción que más a menudo descalifica es la permanente: la plantilla de un Cube es inmutable después de la provisión, por lo que un nivel cuya forma o necesidades de escalabilidad pueden cambiar se diseña en una clase que se puede reconfigurar. VM Auto Scaling en sí mismo es solo horizontal y crea nuevas réplicas a partir de una plantilla de réplica de tiempo de diseño.
| Clase | Criterio de diferenciación | Restricción de elegibilidad dura | Derivado en |
|---|---|---|---|
| Núcleo dedicado | Núcleo físico exclusivo; familia CPU seleccionable y modificable | El cambio de familia CPU requiere un reinicio, no una operación en vivo | Unidad 4.1, 4.3 |
| Compartido vCPU | Costo más bajo | No hay selección de familia CPU; comparte núcleos físicos, por lo que no hay garantía de aislamiento bajo contienda | Unidad 4.1 |
| Cubes (instancias de plantilla fija) | Plantilla fija vCPU/RAM/NVMe a un precio fijo | La plantilla NVMe Volume empaquetada no se puede desconectar; la plantilla en sí es inmutable. Cubes todavía puede conectar hasta 23 dispositivos Block Storage adicionales, por lo que esto es una trampa de plantilla, no un callejón sin salida de almacenamiento | Unidad 4.1 |
| Private Cloud (VMware dedicado) | SDDC de VMware administrado de un solo inquilino con licencia incluida | Provisionado de forma autoservicio y bajo demanda, escalado verticalmente agregando hosts; mínimo tres hosts por Cluster | Unidad 4.4 |
El patrón es clase por nivel: un nivel de aplicación sin estado que se escala hacia afuera toma Núcleo dedicado, un nivel de utilidad de tamaño fijo Node toma un Cube, un Workload regulado de un solo inquilino toma Private Cloud. No estandarice una clase en todos los niveles.
2. Selección de plataforma de contenedores
La decisión de contenedores depende de quién lleva el ciclo de vida del control-plane y la carga de cumplimiento. Solo una opción coloca esa carga en IONOS.
| Plataforma | Criterio de diferenciación | Restricción de elegibilidad estricta | Derivado en |
|---|---|---|---|
| Managed Kubernetes | Control plane gestionado de forma gratuita; IONOS lleva el ciclo de vida del control-plane; Node Pools facturado como Compute Engine | Un servicio de LoadBalancer no es un verdadero Load Balancer externo (un IP estático en un worker de ingreso Node, limitado a la capacidad de throughput pública de ese Node); un Managed ALB/NLB separado se provisiona para el tráfico de ingreso real. No se permite escalar a cero; el piso de escalado automático es un Node caliente | Unidad 6.1, 6.2 |
| Red Hat OpenShift | Plataforma OpenShift completa, desplegada por el cliente en la infraestructura de IONOS Cloud | No es un servicio gestionado por IONOS; el ciclo de vida de Cluster recae en el cliente como socio CCSP de Red Hat. Se requiere validación de Red Hat antes de la producción | Unidad 6.4 |
| SUSE Rancher Prime | Gestión de varios Cluster de Rancher en el cómputo de IONOS | Entrega autoadministrada; no gestionada por IONOS; SUSE factura las licencias (suscripción propia) | Unidad 6.4 |
Para el estado de contenedores de FinCorp, el diferenciador es la carga operativa: Managed Kubernetes es el valor predeterminado porque IONOS es el propietario del control plane, y las alternativas desplegadas por el cliente se eligen solo cuando ya existe un contrato o base de habilidades de OpenShift o Rancher.
3. Selección de nivel de almacenamiento
El almacenamiento se ajusta al patrón de acceso. La restricción dura recurrente es el piso de rendimiento de SSD y la asimetría de zona entre cómputo y almacenamiento.
| Nivel | Criterio de diferenciación | Restricción de elegibilidad dura | Derivado en |
|---|---|---|---|
| Block Storage HDD | Menor costo por GB; conexión de un solo VM | Dispositivo de un solo VM; no compartido; no es un mecanismo de copia de seguridad | Unidad 5.1, 4.2 |
| Block Storage SSD Estándar / Premium | Mayor IOPS y throughput por GiB; conexión de un solo VM; hasta 4096 GB por Volume | SSD Estándar por debajo de 100 GB no alcanza el rendimiento completo, por lo que no es adecuado como una base de datos pequeña Volume | Unidad 5.1, 7.3 |
| NFS (archivo de archivo compartido administrado) | Montaje de multi-cliente concurrente dentro de una región | Regional y privado; no disponible en todas las ubicaciones (por ejemplo, DE/FRA/2 y GB/WOR); activo-pasivo en la capa de servicio | Unidad 5.1 |
| Object Storage | Objeto a granel compatible con S3, destino de copia de seguridad y almacenamiento de auditoría; bloqueo de objeto para retención de evidencia de manipulación | No es un sistema de archivos; espacio de nombres plano con autenticación de clave y secreto; no se puede conectar en bloque | Unidad 5.2 |
Tenga en cuenta la asimetría de zona como una restricción de colocación: Block Storage ofrece Zona 1, 2, 3 y Auto, mientras que el cómputo solo ofrece Zona 1, 2 y Auto. Un par redundante fijado a "Zona 3 de cómputo" no es posible porque la Zona 3 de cómputo no existe.
4. Selección del motor de base de datos
La decisión de la base de datos está impulsada por el modelo de datos en primer lugar y el modelo de replicación y continuidad en segundo lugar. En todos los motores gestionados, la misma frontera se mantiene: no hay réplicas de lectura y el Backup Service no cubre las bases de datos gestionadas, por lo que la escalabilidad de lectura y la continuidad se componen, no se compran.
| Motor | Criterio de diferenciación | Restricción de elegibilidad estricta | Derivado en |
|---|---|---|---|
| Managed PostgreSQL | Relacional; replicación asíncrona (predeterminada) o estrictamente síncrona para el RPO más bajo | La replicación síncrona estricta requiere un mínimo de tres réplicas; no hay réplicas de lectura; solo punto de conexión privado | Unidad 5.3 |
| Managed MariaDB | Relacional; perfil operativo más simple | Solo replicación asíncrona (no hay opción síncrona); solo punto de conexión privado | Unidad 5.3 |
| Managed MongoDB | Modelo de documento; particionamiento para escalabilidad horizontal | El particionamiento es una capacidad de edición empresarial; no hay replicación de cambio de flujo gestionada; solo punto de conexión privado | Unidad 5.4 |
| In-Memory DB (caché) | Nivel de lectura de submilisegundo; la capa de escalabilidad de lectura y externalización de sesión | Un caché, no un sistema de registro; solo punto de conexión privado | Unidad 5.5 |
| Managed Kafka | Transmisión de eventos; el sustituto de captura de datos de cambio a nivel de aplicación | Tres corredores; el orden es por partición solo; no es una base de datos | Unidad 5.6 |
Para el núcleo transaccional de FinCorp, el PostgreSQL con replicación síncrona estricta responde al requisito de RPO bajo, el nivel In-Memory DB responde a la escalabilidad de lectura porque no existen réplicas de lectura, y el Kafka transporta eventos de cambio porque no hay un flujo de cambio de base de datos gestionada.
5. Selección de primitivas de red
Cada primitiva de red responde a una capa o dirección de tráfico diferente. Las restricciones difíciles aquí son la fuente más frecuente de emparejamientos incompatibles (ver Sección 7).
| Primitiva | Criterio de diferenciación | Restricción de elegibilidad difícil | Derivada en |
|---|---|---|---|
| ALB administrado | Enrutamiento de contenido de capa 7 (ruta, host, encabezado, método, cookie, origen-IP) con descarga de TLS | Solo HTTP/HTTPS; no se permite la inclusión en lista blanca de IP y no hay NSG en el LB administrado, por lo que el filtrado pertenece a los objetivos | Unidad 3.3 |
| NLB administrado | Paso de TCP de capa 4; el backend mantiene el certificado | Solo TCP; no hay terminación de TLS; no hay NSG en el LB administrado | Unidad 3.4 |
| Puerta de enlace NAT | Ruta de salida para cargas de trabajo privadas | Solo SNAT, no DNAT de entrada; requiere una dirección pública IP reservada | Unidad 3.6 |
| VPN Gateway | Conectividad de sitio a sitio cifrada | Solo IKEv2 o WireGuard (no IKEv1); comparte un IP público en modo activo-pasivo de alta disponibilidad | Unidad 3.6 |
| Conexión cruzada | Conexión de alta velocidad privada entre VDC | Solo misma región y mismo contrato; no es entre regiones; un LAN por conexión | Unidad 3.6 |
| Grupo de seguridad de red | Filtrado de denegación por defecto en el estado de la NIC del servidor | Se vincula solo a las NIC del servidor; no se aplica a los nodos de grupo de Managed Kubernetes Node ni a Cubes suspendidos, y nunca al ALB/NLB administrado | Unidad 3.2 |
| Cloud DNS | Resolución de cualquiercast y administración de registros de baja TTL | No hay conmutación por error basada en comprobaciones de salud nativas; solo dirige nuevas conexiones, y el TTL mínimo de 60 segundos es el principal control de RTO | Unidad 3.7 |
6. El Filtro de Soberanía y Attestación
Aplicar este filtro al final, sobre el diseño terminado. La soberanía y el cumplimiento normativo no originan una arquitectura; reducen el conjunto de ubicaciones que un diseño ya correcto puede utilizar. La soberanía legal de la Unión Europea es una propiedad de la jurisdicción del operador, no solo de la región: una región de la Unión Europea de un proveedor operado por Estados Unidos todavía conlleva la exposición a la Ley de Nube de Estados Unidos, mientras que IONOS es operado por la Unión Europea.
Los alcances de la attestación difieren por servicio y nunca deben generalizarse a "la plataforma está certificada". Los dos reconocimientos de BSI, ambos para centros de datos alemanes, cubren diferentes conjuntos de servicios:
| Servicio | BSI C5 (atestación de tipo 1, 2023-11-07) | ISO 27001 basado en IT-Grundschutz (certificado, 2022-09-14) |
|---|---|---|
| Compute Engine | En el alcance | En el alcance |
| Cloud Cubes | En el alcance | No en el alcance |
| Object Storage | En el alcance | En el alcance |
| Copia de seguridad | No en el alcance | En el alcance |
| Managed Kubernetes | No en el alcance | En el alcance |
IONOS es el primer proveedor de nube alemán en poseer tanto la attestación C5 como la certificación de IT-Grundschutz, pero los dos alcances no son intercambiables. C5 es una attestación (Testat), de tipo 1, no una certificación y no de tipo 2. Las credenciales a nivel de centro de datos (por ejemplo, ISO 27001 en una ubicación, PCI-DSS, Uptime Tier IV) son mantenidas por el operador del centro de datos y varían según la ubicación; las listas de certificados de productos en marketing no son contractuales. NIS2 es una obligación regulatoria, no una certificación mantenida.
Para FinCorp bajo GDPR y BSI, la residencia es una decisión de ubicación tomada antes de que cualquier Workload aterrice: centros de datos alemanes, operador de la Unión Europea, y cada servicio en el alcance validado contra la attestación exacta que su clase de datos requiere.
Resumen de la decisión
Utilice las matrices anteriores como el artefacto de la unidad. El orden de lectura es fijo:
- Reduzca por el criterio de diferenciación para el nivel.
- Elimine cada opción que no cumpla con una restricción de elegibilidad estricta, antes de considerar cualquier otra cosa.
- Aplique el filtro de soberanía y acreditación al final, sobre todo el diseño.
7. Los dos errores de composición
Un diseño puede aprobar cada matriz de primitivos y aún así fallar. Dos errores explican casi todos estos.
Emparejar primitivos incompatibles. Dos opciones que son correctas en aislamiento no se componen. Colocar un grupo de seguridad de red "delante de" un ALB o NLB administrado no hace nada, porque los GSN se vinculan a las NIC del servidor y nunca al administrado Load Balancer; el filtrado tiene que estar en los objetivos. Esperar tráfico de entrada a través de una puerta de enlace NAT falla, porque NAT es solo SNAT; la publicación de entrada pertenece a un Load Balancer o a una dirección pública reservada IP. Intentar unir dos VDC en diferentes regiones mediante Cross-Connect falla, porque Cross-Connect es solo para la misma región y el mismo contrato. Cada uno es un primitivo correcto utilizado donde su restricción dura lo prohibe.
Una opción funcionalmente correcta fuera del alcance de acreditación requerido. Un servicio puede hacer el trabajo perfectamente y aún así ser la opción incorrecta para un Workload regulado porque se encuentra fuera de la acreditación que Workload requiere. Ejecutar el procesamiento de contenedores regulados de FinCorp en Managed Kubernetes es técnicamente sólido, pero Managed Kubernetes no está en el alcance de acreditación de C5, por lo que un Workload que requiere contractualmente C5 debe colocarse en un servicio cubierto por C5, como Compute Engine, en su lugar. La opción no es técnicamente incorrecta; es incorrecta contra el filtro de alcance, que es exactamente por qué ese filtro se aplica al final sobre todo el diseño.
Resumen
Las decisiones de arquitectura en IONOS se reducen a un proceso repetible: reducir por el criterio diferenciador, eliminar las restricciones difíciles y aplicar el alcance de soberanía y acreditación al final sobre el diseño terminado. Las matrices en esta unidad recopilan esos criterios y restricciones para cómputo, contenedores, almacenamiento, bases de datos y redes, para que se pueda tomar una decisión y justificarla en un solo lugar, con los dos errores de composición como última verificación.
Puntos clave:
- Las restricciones de elegibilidad difíciles descalifican directamente: una sola restricción fallida elimina una opción, independientemente de cómo se puntúe en otros aspectos.
- VM Auto Scaling es solo horizontal y crea nuevos réplicas a partir de una plantilla de réplica de tiempo de diseño; no hay réplicas de lectura; el Backup Service no cubre bases de datos gestionadas. Estos límites deciden los niveles de antemano.
- El filtro de soberanía y acreditación se aplica al final, porque el cumplimiento reduce un diseño ya completo en lugar de originarlo.
- Los alcances de C5 y IT-Grundschutz difieren por servicio: Cubes está en C5 pero no en IT-Grundschutz; Copia de seguridad y Managed Kubernetes están en IT-Grundschutz pero no en C5. Nunca generalice a "la plataforma está certificada".
- Los dos errores de composición son emparejar primitivos cuyas restricciones prohíben el emparejamiento, y colocar un servicio funcionalmente correcto fuera del alcance de acreditación que requiere el Workload.
Terminología importante:
- Restricción de elegibilidad difícil: un descalificador absoluto (por ejemplo, una plantilla inmutable de Cube, o la falta de escalabilidad a cero de Managed Kubernetes) que elimina una opción antes de que se considere cualquier criterio ponderado.
- Alcance de acreditación: el conjunto exacto de servicios que cubre una credencial; en IONOS, C5 y IT-Grundschutz cubren diferentes servicios, y una reclamación siempre debe estar vinculada al servicio nombrado, la ubicación del centro de datos alemán, la credencial, su tipo y su fecha.
Lectura adicional
- Unidad 4.1 Selección de clase de cómputo, Unidad 4.4 Private Cloud (Núcleo dedicado VMware)
- Unidad 6.1 Diseño de la plataforma Kubernetes, Unidad 6.4 Registro de contenedores y selección de plataforma
- Unidad 5.7 Protección de datos y ciclo de vida
- Unidad 1.4 Soberanía y cumplimiento normativo como entradas de diseño
- Unidad 8.2 La arquitectura empresarial de referencia