Unidad 8.1: Marcos de decisión de arquitectura
Introducción
En este punto del curso, cada primitiva ha sido examinada en profundidad. Esta unidad no las vuelve a enseñar. Es un artefacto de referencia: un conjunto de matrices de selección a las que se recurre cuando un nivel de FinCorp requiere una decisión y se desea tener en un solo lugar el criterio diferenciador, la restricción estricta que puede descartar una opción por completo y la unidad que deriva el razonamiento.
Cada matriz debe leerse de la misma manera. Los criterios diferenciadores reducen el campo de opciones. Las restricciones de elegibilidad estrictas son absolutas: una única restricción incumplida elimina una opción, sin importar lo bien que puntúe en otros aspectos. La soberanía y el alcance de la atestación se aplican al final, sobre el diseño completo, porque el cumplimiento normativo reduce las opciones en lugar de originarlas. La unidad concluye con las dos formas en que un diseño técnicamente sólido puede fallar: emparejar primitivas que no se componen entre sí y colocar un servicio funcionalmente correcto fuera del alcance de atestación que la carga de trabajo requiere.
1. Selección de clase de cómputo
La decisión de cómputo se divide en cuatro ejes: aislamiento de núcleos, control de la familia de CPU, conexión de almacenamiento de bloques y modelo operativo. La restricción que más frecuentemente descalifica una opción es la permanente: la plantilla de un Cube es inmutable después de la aprovisionamiento, por lo que un nivel cuya forma o necesidades de escalado puedan cambiar debe diseñarse sobre una clase que pueda reconfigurarse. VM Auto Scaling es exclusivamente horizontal y crea nuevas réplicas a partir de una plantilla de réplica definida en tiempo de diseño.
| Clase | Criterio diferenciador | Restricción de elegibilidad estricta | Derivado en |
|---|---|---|---|
| Dedicated Core | Núcleo físico exclusivo; familia de CPU seleccionable y modificable | El cambio de familia de CPU requiere un reinicio, no es una operación en vivo | Unidad 4.1, 4.3 |
| Shared vCPU | Costo más bajo | No permite selección de familia de CPU; comparte núcleos físicos, por lo que no hay garantía de aislamiento bajo contención | Unidad 4.1 |
| Cubes (instancias de plantilla fija) | Plantilla fija de vCPU/RAM/NVMe a un precio fijo | El volumen NVMe integrado no puede desconectarse; la plantilla en sí es inmutable. Los Cubes aún pueden conectar hasta 23 dispositivos adicionales de Block Storage, 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 VMware administrado de inquilino único con licencias incluidas | Aprovisionamiento autoservicio y bajo demanda, escalado vertical mediante la adición de hosts; mínimo de tres hosts por clúster | Unidad 4.4 |
El patrón es una clase por nivel: un nivel de aplicación sin estado que escala hacia afuera utiliza Dedicated Core, un nodo de utilidad de tamaño fijo utiliza un Cube, y una carga de trabajo regulada de inquilino único utiliza Private Cloud. No estandarice una sola clase en todos los niveles.
2. Selección de plataforma de contenedores
La decisión sobre contenedores depende de quién asume el ciclo de vida del plano de control y la carga de cumplimiento. Solo una opción coloca esa carga sobre IONOS CLOUD.
| Plataforma | Criterio diferenciador | Restricción de elegibilidad estricta | Derivado en |
|---|---|---|---|
| Managed Kubernetes | Plano de control administrado sin costo; IONOS CLOUD asume el ciclo de vida del plano de control; los grupos de nodos se facturan como Compute Engine | Un Service de LoadBalancer no es un equilibrador de carga externo real (una IP estática en un nodo de entrada de trabajo, limitada al ancho de banda público de ese nodo); se aprovisiona un Managed ALB/NLB separado para la entrada real. No hay escalado a cero; el límite inferior del escalado automático es un nodo cálido | Unidad 6.1, 6.2 |
| Red Hat OpenShift | Plataforma completa de OpenShift, desplegada por el cliente en la infraestructura de IONOS CLOUD | No es un servicio administrado de IONOS CLOUD; el ciclo de vida del clúster recae en el cliente como socio Red Hat CCSP. Se requiere la validación de Red Hat antes de la producción | Unidad 6.4 |
| SUSE Rancher Prime | Gestión de clústeres múltiples de Rancher en la computación de IONOS CLOUD | Entrega autogestionada; no es administrada por IONOS CLOUD; SUSE factura las licencias (modelo de suscripción propia) | Unidad 6.4 |
Para el entorno de contenedores de FinCorp, el diferenciador es la carga operativa: Managed Kubernetes es la opción predeterminada porque IONOS CLOUD es propietario del plano de control, y las alternativas desplegadas por el cliente se eligen solo cuando ya existe un contrato o una base de conocimientos de OpenShift o Rancher.
3. Selección de nivel de almacenamiento
El almacenamiento se ajusta al patrón de acceso. La restricción rígida recurrente es el umbral de rendimiento de SSD y la asimetría de zonas entre cómputo y almacenamiento.
| Nivel | Criterio diferenciador | Restricción rígida de elegibilidad | Derivado en |
|---|---|---|---|
| Block Storage HDD | Costo más bajo por GB; conexión a una sola VM | Dispositivo de una sola VM; no compartido; no es un mecanismo de copia de seguridad | Unidad 5.1, 4.2 |
| Block Storage SSD Standard / Premium | Mayor IOPS y ancho de banda por GiB; conexión a una sola VM; hasta 4096 GB por volumen | SSD Standard por debajo de 100 GB no alcanza el rendimiento completo, por lo que no es adecuado como volumen de base de datos pequeño | Unidad 5.1, 7.3 |
| NFS (archivo compartido administrado) | Montaje concurrente de múltiples clientes dentro de una región | Regional y privado; no disponible en todas las ubicaciones (por ejemplo, DE/FRA/2 y GB/WOR); activo-pasivo a nivel de servicio | Unidad 5.1 |
| Object Storage | Almacenamiento masivo compatible con S3, archivo, destino de copia de seguridad y almacén de auditoría; bloqueo de objetos para retención con evidencia de manipulación | No es un sistema de archivos; espacio de nombres plano con autenticación por clave y secreto; no se puede conectar como bloque | Unidad 5.2 |
Observe la asimetría de zonas como restricción de ubicació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 en "cómputo Zona 3" no es posible porque la Zona 3 de cómputo no existe.
4. Selección del motor de base de datos
La decisión sobre la base de datos se basa primero en el modelo de datos y, en segundo lugar, en el modelo de replicación y continuidad. En los motores relacionales no existen réplicas de lectura, y el Backup Service no cubre ninguna base de datos administrada, por lo que la escalabilidad de lectura y la continuidad se componen, no se adquieren.
| Motor | Criterio diferenciador | 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 estrictamente síncrona requiere dos nodos operativos, con un mínimo de 3 instancias recomendado para producción; sin réplicas de lectura; solo punto de acceso privado | Unidad 5.3 |
| Managed MariaDB | Relacional; perfil operativo más simple | Solo replicación asíncrona (sin opción síncrona); solo punto de acceso privado | Unidad 5.3 |
| Managed MongoDB | Modelo de documentos; fragmentación para escalado horizontal | La fragmentación es una capacidad de la edición empresarial; sin replicación de flujos de cambios administrada; solo punto de acceso privado | Unidad 5.4 |
| In-Memory DB (caché) | Nivel de lectura submilisegundos; capa de escalado de lectura y externalización de sesiones | Es una caché, no un sistema de registro; solo punto de acceso privado | Unidad 5.5 |
| Managed Kafka | Transmisión de eventos; sustituto a nivel de aplicación de la captura de datos de cambios | Tres brokers; el ordenamiento es solo por partición; no es una base de datos | Unidad 5.6 |
Para el núcleo transaccional de FinCorp, PostgreSQL con replicación estrictamente síncrona cumple el requisito de RPO bajo, el nivel In-Memory DB responde al escalado de lectura porque no existen réplicas de lectura, y Kafka transporta los eventos de cambios porque no existe un flujo de cambios de base de datos administrado.
5. Selección de primitivas de red
Cada primitiva de red responde a una capa o dirección de tráfico diferente. Las restricciones estrictas son la fuente más frecuente de combinaciones incompatibles (véase la sección 7).
| Primitiva | Criterio diferenciador | Restricción estricta de elegibilidad | Derivada en |
|---|---|---|---|
| Managed ALB | Enrutamiento de contenido de capa 7 (ruta, host, cabecera, método, cookie, IP de origen) con descarga de TLS | Solo HTTP/HTTPS; sin listas de autorización de IP y sin Network Security Group en el LB administrado, por lo que la filtración corresponde a los destinos | Unidad 3.3 |
| Managed NLB | Paso directo TCP de capa 4; el backend conserva el certificado | Solo TCP; sin terminación de TLS; sin Network Security Group en el LB administrado | Unidad 3.4 |
| NAT Gateway | Ruta de egreso saliente para cargas de trabajo privadas | Solo SNAT, sin DNAT entrante; requiere una IP pública reservada | Unidad 3.6 |
| VPN Gateway | Conectividad cifrada entre sitios | Solo IKEv2 o WireGuard (sin IKEv1); HA activo-pasivo que comparte una IP pública | Unidad 3.6 |
| Cross-Connect | Interconexión privada de ancho de banda alto entre VDCs | Solo misma región y mismo contrato; no es entre regiones; una LAN por conexión | Unidad 3.6 |
| Network Security Group | Filtrado con estado, denegar todo por defecto, en la NIC del servidor | Se vincula solo a NICs de servidor; no se aplica a nodos de grupos de nodos de Managed Kubernetes ni a Cubes suspendidos, y nunca al Managed ALB/NLB administrado | Unidad 3.2 |
| Cloud DNS | Resolución anycast y gestión de registros con TTL bajo | Sin conmutación por error nativa basada en comprobaciones de estado; solo dirige nuevas conexiones, y el TTL mínimo de 60 segundos es el palanca dominante de RTO | Unidad 3.7 |
6. El filtro de soberanía y atestación
Aplique 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 está autorizado a utilizar. La soberanía legal de la UE es una propiedad de la jurisdicción del operador, no solo de la región: una región de la UE de un proveedor operado por EE. UU. sigue estando expuesta a la CLOUD Act de EE. UU., mientras que IONOS CLOUD es operado por la UE.
Los ámbitos de atestación difieren según el servicio y nunca deben generalizarse como "la plataforma está certificada". Las dos reconocimientos de BSI, ambos para centros de datos alemanes, cubren conjuntos de servicios diferentes:
| Servicio | BSI C5 (atestación de tipo 1, 2023-11-07) | ISO 27001 basado en IT-Grundschutz (certificado, 2022-09-14) |
|---|---|---|
| Compute Engine | Dentro del ámbito | Dentro del ámbito |
| Cloud Cubes | Dentro del ámbito | Fuera del ámbito |
| Object Storage | Dentro del ámbito | Dentro del ámbito |
| Backup | Fuera del ámbito | Dentro del ámbito |
| Managed Kubernetes | Fuera del ámbito | Dentro del ámbito |
IONOS CLOUD es el primer proveedor de nube alemán que posee tanto la atestación C5 como la certificación IT-Grundschutz, pero los dos ámbitos no son intercambiables. C5 es una atestació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 certificaciones de producto en el marketing no son contractuales. NIS2 es una obligación regulatoria, no una certificación mantenida.
Para FinCorp bajo RGPD y BSI, la residencia es una decisión de ubicación tomada antes de que cualquier carga de trabajo se despliegue: centros de datos alemanes, operador de la UE, y cada servicio dentro del ámbito validado contra la atestación exacta que su clase de datos requiere.
Resumen de la decisión
Utilice las matrices anteriores como el entregable principal de la unidad. El orden de lectura es fijo:
- Reduzca las opciones según el criterio diferenciador del nivel.
- Elimine todas las opciones que no cumplan una restricción de elegibilidad obligatoria, antes de sopesar cualquier otro factor.
- Aplique el filtro de soberanía y atestación al final, sobre el diseño completo.
7. Los dos errores de composición
Un diseño puede pasar todas las matrices por primitiva y aun así fallar. Dos errores explican casi todos estos casos.
Emparejar primitivas incompatibles. Dos opciones que son correctas por separado no se combinan. Colocar un Network Security Group "delante de" un Managed ALB o NLB no tiene ningún efecto, porque los NSG se asocian a las NIC de los servidores y nunca al balanceador de carga administrado; el filtrado debe aplicarse en los destinos. Esperar tráfico entrante a través de un NAT Gateway falla, porque NAT es solo SNAT; la publicación de tráfico entrante corresponde a un balanceador de carga o a una IP pública reservada. Intentar usar un Cross-Connect para unir dos VDC en diferentes regiones falla, porque Cross-Connect es solo de la misma región y del mismo contrato. Cada una es una primitiva correcta utilizada en un lugar donde su restricción estricta lo prohíbe.
Una elección funcionalmente correcta fuera del alcance de la certificación requerido. Un servicio puede realizar la tarea a la perfección y aun así ser la elección incorrecta para una carga de trabajo regulada, porque se encuentra fuera de la certificación que dicha carga de trabajo requiere. Ejecutar el procesamiento de contenedores regulado de FinCorp en Managed Kubernetes es funcionalmente sólido, pero Managed Kubernetes no está dentro del alcance de la certificación C5, por lo que una carga de trabajo que contractualmente requiere C5 debe colocarse en un servicio cubierto por C5, como Compute Engine. La elección no es incorrecta técnicamente; es incorrecta frente al 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 CLOUD se reducen a un proceso repetible: filtrar por el criterio diferenciador, descartar opciones según las restricciones rígidas y aplicar el alcance de soberanía y de atestación al final, sobre el diseño ya completado. Las matrices de esta unidad recogen esos criterios y restricciones para cómputo, contenedores, almacenamiento, bases de datos y redes, de modo que una decisión pueda tomarse y justificarse en un solo lugar, con los dos errores de composición como verificación cruzada final.
Puntos clave:
- Las restricciones rígidas de elegibilidad descalifican de forma inmediata: una sola restricción incumplida elimina una opción, sin importar lo bien que puntúe en otros aspectos.
- VM Auto Scaling es exclusivamente horizontal y crea nuevas réplicas a partir de una plantilla de réplicas definida en tiempo de diseño; los motores relacionales no tienen réplicas de lectura; Backup Service no cubre ninguna base de datos administrada. Estas delimitaciones determinan las capas de antemano.
- El filtro de soberanía y atestación se aplica al final, porque el cumplimiento reduce un diseño ya completo, en lugar de originarlo.
- Los alcances de C5 e IT-Grundschutz difieren según el servicio: Cubes está incluido en C5 pero no en IT-Grundschutz; Backup y Managed Kubernetes están incluidos en IT-Grundschutz pero no en C5. Nunca se debe generalizar afirmando que "la plataforma está certificada".
- Los dos errores de composición son emparejar primitivas cuyas restricciones prohíben dicho emparejamiento, y colocar un servicio funcionalmente correcto fuera del alcance de atestación que la carga de trabajo requiere.
Terminología importante:
- Restricción rígida de elegibilidad: un descalificador absoluto (por ejemplo, la plantilla inmutable de un Cube, o la ausencia de escala a cero en Managed Kubernetes) que elimina una opción antes de considerar cualquier criterio ponderado.
- Alcance de atestación: el conjunto exacto de servicios que cubre una credencial; en IONOS CLOUD, C5 e IT-Grundschutz cubren servicios diferentes, y una afirmación debe vincularse siempre al servicio nombrado, a la ubicación del centro de datos en Alemania, a la credencial, a su tipo y a su fecha.
Lectura adicional
- Unidad 4.1 Selección de clase de cómputo, Unidad 4.4 Private Cloud (VMware dedicado)
- Unidad 6.1 Diseño de la plataforma Kubernetes, Unidad 6.4 Container Registry y selección de plataforma
- Unidad 5.7 Protección de datos y ciclo de vida
- Unidad 1.4 Soberanía y cumplimiento como entradas de diseño
- Unidad 8.2 La arquitectura empresarial de referencia