El examen DP-300 pregunta qué nivel de servicio es más adecuado para una carga de trabajo determinada, no solo cómo se llaman los niveles, sino qué compromisos implica cada uno. Desde el modelo de compra (DTU vs vCore) hasta el nivel de cómputo (Provisioned vs Serverless) y Elastic Pool, cada opción existe por una razón concreta.
DTU vs vCore: Paquete cerrado vs configuración a medida
Imagina que vas al supermercado y tienes dos opciones: comprar una bandeja de comida preparada o elegir cada ingrediente por separado. El modelo DTU es la bandeja preparada: CPU, memoria e I/O vienen empaquetados en un único número. La facturación es simple y predecible, sin necesidad de ajustar parámetros individuales. El modelo DTU ofrece tres niveles de servicio: Basic, Standard y Premium, que escalan juntos a medida que aumenta el número de DTU.
El modelo vCore es la compra por ingredientes: eliges el número de núcleos de CPU, la memoria y el almacenamiento de forma independiente. Esa granularidad permite decir "necesito más núcleos pero menos almacenamiento", algo que un paquete DTU no puede hacer. Además, puedes traer tus licencias de SQL Server existentes mediante Azure Hybrid Benefit para reducir costos. Los tres niveles de servicio de vCore son General Purpose, Business Critical e Hyperscale.
La señal clave en el examen: si el escenario menciona Azure Hybrid Benefit o control independiente de recursos, la respuesta es vCore. Si menciona facturación simple y predecible, piensa en DTU.
General Purpose: el almacén polivalente
Cuando una empresa de logística necesita un nuevo almacén para carga general — sin cámaras frigoríficas ni instalaciones para materiales peligrosos — alquila un espacio estándar. Suficiente capacidad, costo razonable. General Purpose es ese almacén estándar para Azure SQL Database.
General Purpose utiliza Azure Premium Storage (SSD remoto) y admite hasta 8.000 IOPS. La alta disponibilidad se gestiona mediante replicación de almacenamiento y conmutación automática por error, aunque el proceso de failover puede tardar entre 20 y 30 segundos. Es el punto de partida predeterminado para la mayoría de las cargas de trabajo OLTP y de reporting que no requieren latencia extremadamente baja.
Un dato importante: General Purpose no admite In-Memory OLTP. Para cargas de trabajo que requieren un volumen de transacciones muy elevado — como sistemas de trading financiero — Business Critical es la opción adecuada. General Purpose es ideal para bases de datos de desarrollo y aplicaciones de producción con carga moderada donde el control de costos importa más que el rendimiento máximo.
Business Critical: SSD local y AlwaysOn
La torre de control de un aeropuerto no puede permitirse una conexión de red lenta. Los datos de radar y los movimientos de vuelo necesitan respuestas instantáneas, siempre. Business Critical es ese nivel siempre activo y de baja latencia para Azure SQL Database.
Business Critical almacena los datos en SSD local en lugar de almacenamiento remoto, lo que significa menor latencia y un número significativamente mayor de IOPS en comparación con General Purpose. Internamente, ejecuta un clúster de cuatro nodos con AlwaysOn Availability Group (AG). Uno de esos nodos secundarios está disponible como punto de conexión de solo lectura — una función llamada Read Scale-Out.
Read Scale-Out no tiene costo adicional. Dirigir las consultas de reporting hacia la réplica secundaria puede reducir considerablemente la presión sobre el nodo primario sin pagar por una réplica adicional. In-Memory OLTP también está disponible en Business Critical, lo que permite acelerar cargas de trabajo transaccionales intensivas. Cuando una carga de trabajo necesita alto rendimiento transaccional, baja latencia de lectura y garantías sólidas de disponibilidad, Business Critical es la respuesta correcta.
Hyperscale: paredes que se expanden solas
Las bases de datos tradicionales son como almacenes de tamaño fijo: cuando se llenan, hay que mudarse. Hyperscale elimina ese techo. El almacenamiento escala automáticamente hasta 100 TB a medida que crecen los datos, sin intervención manual y sin tiempo de inactividad durante la expansión.
Hyperscale utiliza una arquitectura única basada en Page Servers que gestionan el almacenamiento de forma independiente de la capa de cómputo. Escalar el cómputo hacia arriba o hacia abajo se completa en minutos en lugar de horas. Las copias de seguridad se basan en instantáneas, por lo que el tiempo de backup no crece proporcionalmente con el tamaño de los datos. La restauración desde una instantánea también es rápida, independientemente del tamaño de la base de datos.
La restricción crítica: una vez que una base de datos se migra a Hyperscale, no se puede degradar a General Purpose ni a Business Critical. Es una puerta de un solo sentido. Elige Hyperscale solo cuando el volumen de datos realmente lo exija.
!Niveles de servicio de Azure SQL
Serverless vs Provisioned: paga solo por lo que usas
Algunas oficinas mantienen el aire acondicionado encendido las veinticuatro horas; otras usan un termostato inteligente que lo apaga cuando el edificio está vacío y lo reactiva cuando alguien llega. El cómputo Provisioned es el modelo siempre activo. Serverless es el termostato inteligente.
Serverless solo está disponible dentro del nivel General Purpose con el modelo vCore. Admite auto-pause — la base de datos se suspende tras un período de inactividad configurable — y auto-resume — se reactiva automáticamente cuando llega una conexión. La facturación es por segundo de actividad, por lo que una base de datos de desarrollo inactiva durante la noche casi no genera costos.
La desventaja es la latencia de arranque en frío. Cuando la base de datos se reanuda desde un estado pausado, la primera solicitud puede esperar desde unos pocos segundos hasta más de un minuto, dependiendo del estado de la caché. Para cargas de trabajo de producción que requieren tiempos de respuesta consistentes, Provisioned es la elección correcta. Serverless es ideal para entornos de desarrollo y pruebas o herramientas internas con uso impredecible.
Elastic Pool: la piscina compartida del hotel
La piscina de un hotel sirve a decenas de huéspedes sin que cada uno necesite la suya propia. Funciona porque no todos nadan al mismo tiempo. Elastic Pool aplica la misma lógica a las bases de datos.
Un Elastic Pool permite que múltiples bases de datos compartan un único conjunto de recursos — ya sea basado en DTU o en vCore. Cada base de datos puede definir una asignación mínima garantizada y un límite máximo, lo que impide que un solo tenant consuma todo el pool. Las aplicaciones SaaS donde cada cliente tiene su propia base de datos son el caso de uso clásico: en lugar de aprovisionar recursos dedicados completos para cada tenant, todos comparten un pool y cada uno obtiene lo que necesita cuando lo necesita.
El beneficio de eficiencia es real cuando los picos de uso de los tenants se producen en momentos diferentes. Elastic Pool es más efectivo con muchas bases de datos pequeñas que tienen un uso variable y picos no coincidentes. También simplifica la gestión, ya que se configura el pool una vez y se agregan o eliminan bases de datos fácilmente.
Errores comunes al elegir un nivel
Cuando se empaca para un viaje, asumir que todo se puede comprar en el destino es una apuesta que muchas veces no sale bien. Azure SQL Database tiene decisiones similares de sentido único que son costosas de revertir después del despliegue.
El error más crítico es que la migración a Hyperscale es una operación de un solo sentido. No hay camino de regreso a General Purpose ni a Business Critical una vez que se cruza esa frontera. Del mismo modo, Serverless y geo-replication no se pueden usar juntos. Si eliges Serverless para una base de datos de producción y luego necesitas recuperación ante desastres mediante geo-replication, tendrás que cambiar primero a Provisioned.
La migración de DTU a vCore está soportada, pero lo contrario — de vCore a DTU — no lo está. Read Scale-Out de Business Critical es gratuito, pero General Purpose no tiene esa función en absoluto. Estas restricciones significan que la elección del nivel en el momento del despliegue tiene consecuencias a largo plazo — la elección correcta desde el principio evita migraciones costosas más adelante.
Resumen para el Examen
"Control independiente de CPU y almacenamiento" -- modelo vCore "Portabilidad de licencias con Azure Hybrid Benefit" -- modelo vCore "Facturación en paquete simple, Basic/Standard/Premium" -- modelo DTU "Datos a escala de petabytes, escala instantánea, restauración por instantánea" -- Hyperscale "Degradar desde Hyperscale" -- no compatible (migración en un solo sentido) "SSD local, AlwaysOn AG de 4 nodos, In-Memory OLTP" -- Business Critical "Réplica de solo lectura sin costo adicional" -- Business Critical Read Scale-Out "auto-pause / auto-resume, facturación por segundo" -- Serverless "Serverless + geo-replication" -- no compatibles "Múltiples bases de datos compartiendo un pool de recursos, tenants SaaS" -- Elastic Pool "Azure Premium Storage remoto, OLTP de propósito general" -- General Purpose
DTU = paquete simple, vCore = control granular; GP = propósito general, BC = alto rendimiento + SSD local, Hyperscale = escala masiva (un solo sentido)