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 evalúe en otros aspectos. La soberanía y el alcance de la acreditación se aplican al final, sobre todo el diseño, porque el cumplimiento 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 requiere la carga de trabajo.
1. Selección de clase de proceso
La decisión de proceso es una división en cuatro ejes a través del aislamiento de núcleo, control de familia de CPU, 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. El VM Auto Scaling en sí mismo es solo horizontal y estampa 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 estricta | Derivado en |
|---|---|---|---|
| Núcleo dedicado | Núcleo físico exclusivo; familia de CPU seleccionable y modificable | El cambio de familia de CPU requiere un reinicio, no una operación en vivo | Unidad 4.1, 4.3 |
| vCPU compartido | Costo más bajo | No hay selección de familia de CPU; comparte núcleos físicos, por lo que no hay garantía de aislamiento bajo contienda | Unidad 4.1 |
| Cubes (instancias con plantilla fija) | Plantilla fija de vCPU/RAM/NVMe a un precio fijo | El volumen NVMe empaquetado no se puede desconectar; 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 de VMware administrado para un solo inquilino con licencia incluida | Provisionado como autoservicio y bajo demanda, escalado verticalmente agregando hosts; mínimo tres hosts por clúster | 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 nodo de utilidad de tamaño fijo toma un Cube, una carga de trabajo regulada para un solo inquilino toma Private Cloud. No estandarice una sola clase en todos los niveles.
2. Selección de plataforma de contenedores
La decisión sobre los 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 CLOUD.
| Plataforma | Criterio de diferenciación | Restricción de elegibilidad estricta | Derivado en |
|---|---|---|---|
| Managed Kubernetes | Control plane gestionado de forma gratuita; IONOS CLOUD lleva el ciclo de vida del control-plane; los grupos de nodos se facturan como Compute Engine | Un servicio LoadBalancer no es un verdadero equilibrador de carga externo (una IP estática en un nodo de trabajo de ingreso, limitado a la capacidad de throughput pública de ese nodo); se provisiona un Managed ALB/NLB separado para el ingreso real. No hay escalabilidad cero; el piso de escalabilidad automática es un nodo cálido | Unidad 6.1, 6.2 |
| Red Hat OpenShift | Plataforma OpenShift completa, implementada por el cliente en la infraestructura de IONOS CLOUD | No es un servicio gestionado por IONOS CLOUD; el ciclo de vida del clúster reside con 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 | Administración multi-clúster de Rancher en la computación de IONOS CLOUD | Entrega autoadministrada; no gestionada por IONOS CLOUD; SUSE factura las licencias (traiga su propia suscripción) | Unidad 6.4 |
Para el estado de contenedores de FinCorp, el diferenciador es la carga operativa: Managed Kubernetes es el valor predeterminado porque IONOS CLOUD posee el control plane, y las alternativas implementadas por el cliente se eligen solo cuando ya existe un contrato o base de habilidades para 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 single-VM | Dispositivo single-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 single-VM; hasta 4096 GB por volumen | SSD Estándar por debajo de 100 GB no alcanza el rendimiento completo, por lo que no es adecuado como un volumen de base de datos pequeño | Unidad 5.1, 7.3 |
| NFS (archivo compartido administrado) | Montaje concurrente multi-cliente 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 | Bulk compatible con S3, archivo, destino de copia de seguridad y almacén de auditoría; bloqueo de objeto para retención con evidencia de manipulación | No es un sistema de archivos; espacio de nombres plano con autenticación clave-secreto; no se puede adjuntar como 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 cómputo" no es posible porque la Zona 3 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. A lo largo de los motores relacionales, no hay réplicas de lectura, y el Backup Service no cubre ninguna base de datos gestionada, por lo que la escalabilidad de lectura y la continuidad están compuestas, no compradas.
| 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 estrictamente síncrona requiere dos nodos operativos, con un mínimo de 3 instancias recomendadas para producción; no hay réplicas de lectura; solo punto de conexión privado | Unidad 5.3 |
| Managed MariaDB | Relacional; perfil operativo más simple | Replicación asíncrona solo (no hay opción síncrona); solo punto de conexión privado | Unidad 5.3 |
| Managed MongoDB | Modelo de documento; particionado para escala horizontal | El particionado es una capacidad de edición empresarial; no hay replicación gestionada de cambio de flujo; solo punto de conexión privado | Unidad 5.4 |
| In-Memory DB (caché) | Capa 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, PostgreSQL con replicación estrictamente síncrona responde al requisito de RPO bajo, la capa In-Memory DB responde a la escalabilidad de lectura porque no existen réplicas de lectura, y Kafka transporta eventos de cambio porque no hay flujo de cambio gestionado en la base de datos.
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 |
|---|---|---|---|
| Managed ALB | Enrutamiento de contenido de capa 7 (ruta, host, encabezado, método, cookie, source-IP) con descarga de TLS | Solo HTTP/HTTPS; no se permite la lista de IP y no hay NSG en el LB administrado, por lo que el filtrado pertenece a los objetivos | Unidad 3.3 |
| Managed NLB | 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 |
| NAT Gateway | Ruta de salida para cargas de trabajo privadas | Solo SNAT, no DNAT entrante; requiere una IP pública reservada | Unidad 3.6 |
| VPN Gateway | Conectividad sitio a sitio cifrada | Solo IKEv2 o WireGuard (no IKEv1); compartición de HA activo-pasivo con una IP pública compartida | Unidad 3.6 |
| Cross-Connect | Conectividad privada de alta banda entre VDCs | Same región y mismo contrato solo; no es entre regiones; un LAN por conexión | Unidad 3.6 |
| Network Security Group | Filtrado deny-all-by-default estatal en la NIC del servidor | Se vincula solo a las NIC del servidor; no se aplica a los nodos del grupo de nodos de Managed Kubernetes o a los Cubes suspendidos, y nunca al Managed ALB/NLB administrado | Unidad 3.2 |
| Cloud DNS | Resolución anycast y administración de registros de bajo 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 controlador RTO | Unidad 3.7 |
6. El Filtro de Soberanía y Attestation
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 jurídica 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 en Estados Unidos sigue teniendo exposición a la Ley CLOUD de Estados Unidos, mientras que IONOS CLOUD es operado en la Unión Europea.
Los alcances de attestation difieren por servicio y nunca deben generalizarse a "la plataforma está certificada". Los dos reconocimientos del BSI, ambos para centros de datos alemanes, cubren diferentes conjuntos de servicios:
| Servicio | BSI C5 (attestation 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 |
| Backup | No en el alcance | En el alcance |
| Managed Kubernetes | No en el alcance | En el alcance |
IONOS CLOUD es el primer proveedor de nube alemán en poseer tanto la attestation C5 como la certificación IT-Grundschutz, pero los dos alcances no son intercambiables. C5 es una attestation (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 poseídas 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 poseída.
Para FinCorp bajo GDPR y BSI, la residencia es una decisión de ubicación tomada antes de que cualquier carga de trabajo se implemente: centros de datos alemanes, operador de la Unión Europea y cada servicio en el alcance validado contra la attestation 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 por primitiva y aún así fallar. Dos errores explican casi todos estos.
Emparejar primitivas 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 GSR se vinculan a las NIC del servidor y nunca al equilibrador de carga administrado; el filtrado tiene que estar en los objetivos. Esperar tráfico entrante a través de una Puerta de Enlace NAT falla, porque NAT es solo SNAT; la publicación entrante pertenece a un equilibrador de carga o a una IP pública reservada. Intentar llegar a un Cross-Connect para unir dos VDC en diferentes regiones falla, porque Cross-Connect es solo para la misma región y el mismo contrato. Cada uno es una primitiva correcta utilizada donde su restricción dura lo prohibe.
Una elección funcionalmente correcta fuera del alcance de acreditación requerido. Un servicio puede hacer el trabajo perfectamente y aún así ser la elección incorrecta para una carga de trabajo regulada porque se encuentra fuera de la acreditación que esa carga de trabajo requiere. Ejecutar el procesamiento contenedorizado regulado de FinCorp en Managed Kubernetes es funcionalmente sólido, pero Managed Kubernetes no está en el alcance de acreditació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 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 CLOUD 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 del diseño terminado. Las matrices en esta unidad recopilan esos criterios y restricciones para cómputo, contenedores, almacenamiento, bases de datos y redes, de modo que se pueda tomar y justificar una decisión 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 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 diseño; los motores relacionales no tienen réplicas de lectura; el Backup Service no cubre ninguna base de datos gestionada. Estos límites deciden los niveles por adelantado.
- 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; Backup 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 la carga de trabajo.
Terminología importante:
- Restricción de elegibilidad difícil: un descalificador absoluto (por ejemplo, una plantilla inmutable de Cube, o la falta de escalado a cero de Managed Kubernetes) que elimina una opción antes de considerar cualquier criterio ponderado.
- Alcance de acreditación: el conjunto exacto de servicios que cubre una credencial; en IONOS CLOUD, C5 y IT-Grundschutz cubren servicios diferentes, 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 (VMware dedicado)
- Unidad 6.1 Diseño de plataforma Kubernetes, Unidad 6.4 Registro de contenedores y selección de plataforma
- Unidad 5.7 Protección y ciclo de vida de los datos
- Unidad 1.4 Soberanía y cumplimiento normativo como entradas de diseño
- Unidad 8.2 La arquitectura empresarial de referencia