Durante dos módulos completos, db-reservas ha sido una caja con una etiqueta. Aparecía en el diagrama de red dentro de snet-datos, la aplicación de App Service se conectaba a ella mediante una cadena de conexión y el punto de conexión privado pe-sql-reservas reservaba su sitio. Pero nadie ha decidido todavía qué es esa caja por dentro, y esa decisión —tomada en una reunión de media hora o heredada de "lo que ya usábamos"— es la que más caro sale corregir después.

Cambiar una máquina virtual de tamaño lleva cinco minutos. Cambiar un plan de App Service, dos clics. Cambiar el motor de base de datos de una plataforma en producción es un proyecto de meses: hay que reescribir consultas, migrar datos históricos, reentrenar al equipo y parar la venta de billetes durante la ventana de corte. Por eso esta lección no despliega nada: construye el criterio. Al final tendrás el mapa de datos completo de Contoso Airlines, con una decisión razonada por sistema, y cada una de esas decisiones será una lección de este módulo.

Aviso de coste: esta lección es puramente de diseño y no crea ningún recurso, así que no genera factura. A partir de la siguiente sí: las bases de datos están entre los recursos más caros de Azure y, a diferencia de una máquina virtual, muchas no se pueden detener. Lee siempre el apartado de coste antes de ejecutar un az ... create.

1. La decisión que realmente falla en los proyectos
2. Relacional frente a NoSQL: qué pregunta responde bien cada modelo
3. Gestionado (PaaS) frente a instalado en una VM (IaaS)
4. El catálogo de datos de Azure en una tabla de decisión
5. Los criterios que deciden
6. Consistencia frente a latencia: el teorema CAP en términos prácticos
7. Cómo se factura una base de datos en la nube
8. El mapa de datos de Contoso Airlines
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

En los proyectos de migración a la nube que salen mal, el punto de fallo rara vez es el cómputo. Es el dato. Y casi siempre por uno de estos tres motivos:

• Se elige por moda, no por pregunta. "Vamos a usar NoSQL porque escala" es una frase sin contenido si nadie ha escrito antes qué consultas hará la aplicación. NoSQL escala para los accesos que su diseño previó; para el resto es peor que una base relacional.
• Se elige por inercia. "Siempre hemos usado SQL Server, ponemos SQL Server". A veces es la respuesta correcta —la compatibilidad es un criterio legítimo y potente—, pero debe ser una conclusión, no un punto de partida.
• Se elige una sola base de datos para todo. Es el error más caro. Una plataforma real tiene varios sistemas con necesidades opuestas, y forzarlos a todos al mismo motor significa que ninguno funciona bien. A usar el almacén adecuado para cada carga se le llama persistencia políglota, y es exactamente lo que hará Contoso.

La pregunta correcta no es "¿qué base de datos es mejor?", sino "¿qué preguntas tengo que responder, con qué frecuencia, sobre cuántos datos y en cuánto tiempo?".

Un modelo relacional organiza los datos en tablas de filas y columnas con un esquema fijo, relaciones declaradas mediante claves foráneas y transacciones ACID. Su superpoder es la consulta arbitraria: puedes cruzar tablas que nadie previó que se cruzarían y el motor encontrará la forma de resolverlo.

NoSQL no es un modelo, sino una familia de modelos que renuncian a parte de eso a cambio de escala, flexibilidad de esquema o latencia:

Dos aclaraciones que evitan malentendidos habituales:

• NoSQL no significa "sin esquema", significa "sin esquema impuesto por el motor". El esquema sigue existiendo: vive en el código de la aplicación, que es un sitio peor para vigilarlo.
• NoSQL no significa "sin transacciones". Cosmos DB tiene transacciones ACID, pero solo dentro de una misma partición lógica. La diferencia está en el alcance, no en la existencia.

Puedes instalar PostgreSQL en una máquina virtual de las que desplegaste en la lección 02-01. Funcionará. La pregunta es qué trabajo estás aceptando a cambio de qué control, aplicando el modelo de responsabilidad compartida del módulo 1:

La regla práctica es simple: usa PaaS salvo que tengas un motivo concreto y escrito para no hacerlo. Los motivos legítimos existen —una versión antigua no soportada, un agente de terceros que exige instalarse en el servidor, funcionalidades de SQL Server que solo hay en la instancia completa, o un requisito de licenciamiento— pero son minoría. El coste por hora de una VM parece menor hasta que sumas las horas de Marta Ríos parcheando servidores un domingo.

Este es el mapa completo de lo que Azure ofrece para datos. Léelo como una tabla de decisión, no como un catálogo de venta:

Redis y Table Storage aparecen aquí porque completan el mapa, pero no tienen lección propia en este módulo: Table Storage ya se vio en 02-04 y Redis se usará como caché en el módulo 6.

Cuando hay que justificar una elección ante un comité —y en Contoso hay que hacerlo, porque Nuria Peña aparecerá en el módulo 8 preguntando por la factura— conviene puntuar seis criterios:

1. Modelo de datos. ¿Los datos tienen forma de tabla con relaciones, de documento autocontenido, de clave-valor o de grafo? Escribe tres consultas reales que la aplicación hará y comprueba si el modelo las responde de forma natural.
2. Consistencia frente a latencia. Lo desarrollamos en el apartado siguiente.
3. Volumen y crecimiento. No el de hoy: el de dentro de tres años. Contoso guarda unos 40 GB de reservas activas y crece 12 GB al año; eso cabe holgadamente en cualquier opción. Los registros de eventos de embarque, en cambio, crecen 200 GB al año y descartan por sí solos la base relacional.
4. Patrón de lectura y escritura. ¿Lecturas o escrituras dominantes? ¿Acceso por clave o por consulta compleja? ¿Picos previsibles? El catálogo de tarifas se lee miles de veces por minuto y se escribe dos veces al día: un caso ideal para documento con caché.
5. Compatibilidad con lo que ya existe. El portal de contenidos de Contoso es WordPress y habla MySQL. Reescribirlo para que hable otra cosa no aporta ningún valor de negocio.
6. Coste y habilidades del equipo. Un motor que nadie sabe operar es una incidencia esperando su turno. Diego Salas conoce SQL Server y PostgreSQL; nadie del equipo ha tocado Cassandra, lo que descarta esa API de Cosmos DB sin más discusión.

El teorema CAP dice que un sistema distribuido no puede garantizar a la vez consistencia (C), disponibilidad (A) y tolerancia a particiones de red (P). Como la red siempre puede partirse, la elección real es: cuando dos centros de datos dejan de verse, ¿prefieres dar un dato posiblemente desactualizado o negar el servicio hasta estar seguro?

Traducido al negocio de Contoso, con dos ejemplos que llevan a respuestas opuestas:

• Plazas libres de un vuelo. Si dos servidores discrepan, se venden dos billetes para el mismo asiento y alguien se queda en tierra, con compensación regulada por la normativa europea. Aquí se elige consistencia: mejor un error que un asiento vendido dos veces.
• Número de puntos de fidelización mostrados en el perfil. Si un pasajero ve 12.400 puntos y el saldo real ya es 12.550 porque el vuelo de ayer acaba de liquidarse, no pasa nada: en unos segundos se corrige. Aquí se elige latencia y disponibilidad.

La consecuencia práctica es que la respuesta no es del sistema, sino del dato: la misma aplicación puede tener datos que exigen consistencia estricta y datos que toleran retraso, y por eso acaba usando dos almacenes distintos. En la lección 03-03 verás que Cosmos DB no obliga a elegir de una vez para siempre: ofrece cinco niveles de consistencia, incluso ajustables por petición.

Todas las bases de datos gestionadas de Azure facturan por las mismas cuatro dimensiones, aunque cada una las llame distinto:

La distinción que más dinero ahorra es aprovisionado frente a sin servidor:

• Aprovisionado: reservas una capacidad fija y pagas por ella las 24 horas, se use o no. Es lo correcto para carga sostenida y previsible, como db-reservas en producción.
• Sin servidor: pagas por el consumo real por segundo y, si el motor lo soporta, la base se pausa cuando lleva un rato sin conexiones, dejando de facturar cómputo (el almacenamiento se sigue pagando siempre). Es lo correcto para desarrollo, pruebas y cargas intermitentes.

La cuenta de servilleta que hará Contoso: el entorno de desarrollo se usa unas 45 horas a la semana de las 168 que tiene. Pagar aprovisionado significa tirar el 73 % del gasto. Con sin servidor y pausa automática, ese 73 % desaparece de la factura sin que nadie cambie su forma de trabajar.

Y un aviso que se repetirá en todo el módulo: una base de datos aprovisionada no se puede "apagar" como una VM. No existe el equivalente al estado desasignado de la lección 02-01. Si dejas creado un servidor de pruebas y te olvidas, sigue facturando cada hora hasta que lo elimines.

Aplicando los seis criterios a los cinco sistemas de la aerolínea, este es el resultado, y también el guion del resto del módulo:

Es persistencia políglota: cinco almacenes porque hay cinco preguntas distintas. El diagrama completo, con la red del módulo 2 al fondo:

Fíjate en las flechas discontinuas: la analítica nunca consulta directamente la base operativa. Es el principio que justifica el apartado 1 de la lección 03-06.

• Elegir el motor antes de escribir las consultas. Si no puedes enumerar las cinco consultas más frecuentes de tu aplicación, no tienes información suficiente para decidir. Escríbelas primero, aunque sea en lenguaje natural.
• Usar NoSQL para evitar diseñar el modelo. La flexibilidad de esquema no elimina el diseño: lo traslada al código, donde no hay motor que valide nada. A los seis meses conviven cuatro formas distintas del mismo documento.
• Meter datos analíticos en la base operativa. Un informe de rentabilidad de tres años lanzado contra db-reservas a las 11 de la mañana degrada la venta de billetes para todos los clientes. Sepáralos desde el principio.
• Olvidar que la base de datos no se apaga. Este es el error que más aparece en las primeras facturas: se crean tres servidores para "probar" y siguen ahí un mes después. Aplica siempre las etiquetas obligatorias (entorno, proyecto, centro-coste, propietario) para poder localizar al responsable de cada recurso.
• Ignorar las habilidades del equipo. El motor teóricamente óptimo que nadie sabe diagnosticar a las tres de la mañana es peor que el motor correcto que todos conocen.
• Consejo: documenta cada decisión con una ficha de una página (contexto, opciones, decisión, consecuencias). Cuando dentro de dos años alguien pregunte por qué las tarifas están en Cosmos DB, esa página ahorrará una semana de discusión.
• Consejo: si dudas entre relacional y documento y el volumen es moderado, empieza por relacional. Añadir un almacén de documentos después es sencillo; reconstruir la integridad referencial que nunca tuviste, no.

Contoso Airlines plantea cinco necesidades adicionales. Para cada una, elige el servicio de datos y justifica con al menos dos de los seis criterios:

1. Guardar cada evento de escaneo de tarjeta de embarque en las puertas: unos 90 millones de registros al año, escritura constante, consulta posterior solo por número de vuelo y fecha.
2. Cachear el resultado de la búsqueda "BCN → LHR, 12 de julio" durante 60 segundos para no golpear la API en cada tecleo del usuario.
3. Almacenar los contratos en PDF firmados con las agencias de viaje, unos 400 al año, con búsqueda por nombre de agencia.
4. Un sistema nuevo de recomendación de rutas alternativas ante cancelaciones, que necesita encontrar caminos entre aeropuertos con un máximo de dos escalas.
5. El estado en tiempo real de los 38 aviones de la flota, actualizado cada 5 segundos y consultado por el panel de operaciones.

Justifica en cada caso si Contoso debe usar un servicio gestionado o una máquina virtual:

1. Una aplicación de mantenimiento de aeronaves que exige SQL Server 2016 con un agente de auditoría de un fabricante externo que se instala como servicio de Windows.
2. Una base de datos nueva para el programa de fidelización, sin dependencias heredadas.
3. Una instancia de SQL Server con 14 bases de datos que hoy se comunican entre sí con consultas entre bases y trabajos del Agente SQL.

El equipo propone este entorno de desarrollo: una base relacional aprovisionada de 4 vCore encendida todo el mes (unos 480 € al mes en tarifa de lista aproximada), 100 GB de almacenamiento y retención de copias de 35 días.

1. ¿Qué cambio de un solo parámetro elimina más gasto, sabiendo que el equipo trabaja 45 horas semanales?
2. ¿Es razonable una retención de 35 días en desarrollo? ¿Qué propondrías?
3. ¿Qué comprobación harías cada lunes para evitar bases olvidadas?

Solución 1:

Solución 2:

1. VM (IaaS), o al menos hay que valorarla seriamente: el agente externo necesita instalarse en el sistema operativo, y en PaaS no hay sistema operativo al que acceder. Antes de rendirse conviene comprobar si el fabricante tiene versión compatible con PaaS.
2. PaaS, Azure SQL Database. No hay dependencias que aten y se aprovechan copias automáticas, parcheo y alta disponibilidad sin trabajo operativo.
3. SQL Managed Instance. Es el caso para el que existe: soporta consultas entre bases y SQL Agent —que Azure SQL Database no ofrece— sin renunciar al modelo gestionado. Migrar a Azure SQL Database obligaría a reescribir esas 14 aplicaciones.

Solución 3:

1. Pasar el nivel a sin servidor con pausa automática. Con 45 horas de uso sobre 168, se factura cómputo aproximadamente el 27 % del tiempo: el ahorro ronda el 70 % de la partida de cómputo, sin cambiar nada en el trabajo diario del equipo. Es exactamente la configuración que Contoso adoptará para db-reservas en rg-contoso-reservas-dev.
2. No, es excesiva. En desarrollo, los datos son sintéticos y regenerables: 7 días es suficiente y reduce la partida de copias de seguridad. Los 35 días tienen sentido en producción, donde hay obligación legal y datos irrepetibles.
3. Listar los recursos sin las etiquetas obligatorias o con entorno=dev creados hace más de una semana, y reclamar al propietario. Con Azure CLI se resuelve con az resource list --tag entorno=dev --query "[].{n:name, t:type}" -o table, aprovechando el filtrado JMESPath de la lección 01-06. En el módulo 4 esto se automatizará con Azure Policy, y en el 8 con Cost Management.

Esta lección no ha creado ni un recurso, y aun así es la que más dinero puede ahorrarle a Contoso Airlines. Ahora sabes por qué la elección del almacén de datos es la decisión menos reversible de una arquitectura y por qué falla casi siempre por los mismos tres motivos: moda, inercia o querer un único motor para todo. Distingues el modelo relacional de las cuatro familias NoSQL —documento, clave-valor, grafo y columnar— por la pregunta que responde bien cada una, no por su eslogan. Tienes en tabla lo que ganas y lo que pierdes al pasar de una base instalada en una VM a un servicio gestionado, y el criterio para saber cuándo el IaaS sigue estando justificado. Conoces el catálogo completo de servicios de datos de Azure como tabla de decisión, con el caso típico de cada uno y, más útil todavía, el caso en el que hay que descartarlo.

También tienes los seis criterios con los que defender una elección ante un comité —modelo, consistencia frente a latencia, volumen, patrón de acceso, compatibilidad y equipo—, una lectura práctica del teorema CAP aplicada a dos datos reales de la aerolínea con respuestas opuestas, y las cuatro dimensiones por las que factura cualquier base de datos gestionada, con la distinción entre aprovisionado y sin servidor que elimina de golpe el 73 % del gasto del entorno de desarrollo. Y sobre todo tienes el mapa de datos de Contoso: cinco sistemas, cinco almacenes, una justificación escrita para cada uno.

Ese mapa es el guion de las próximas cinco lecciones, y empezamos por el corazón del negocio. En la siguiente lección, Azure SQL Database, desplegarás por fin el servidor lógico sql-contoso-reservas-pro y la base db-reservas: elegirás entre modelos de compra DTU y vCore, entenderás por qué el "servidor" no es una máquina, crearás el esquema de vuelos, pasajeros y reservas con sus índices razonados, y conectarás la base a snet-datos mediante el punto de conexión privado pe-sql-reservas con el acceso público deshabilitado, cerrando el hueco que dejaste abierto en el módulo 2. Y verás cómo recuperar los datos cuando alguien ejecuta una migración mal preparada un martes por la tarde.