Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 1 de 5
Serverless frente a compute clásico
Serverless prioriza operación gestionada y arranque rápido; classic compute ofrece mayor control de configuración y red.
- Duración
- 17 min aprox.
- Objetivo
- Serverless prioriza operación gestionada y arranque rápido; classic compute ofrece mayor control de configuración y red.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute clásico, serverless y SQL warehouses
Selecciona recursos por patrón de carga, aislamiento, latencia, gobernanza y coste total.
- Comparar serverless, classic y SQL warehouses
- Dimensionar sin sobredimensionar
- Aplicar auto-stop, políticas y modos de rendimiento
01Modelo mentalServerless frente a compute clásico
Serverless prioriza operación gestionada y arranque rápido; classic compute ofrece mayor control de configuración y red.
+
Serverless frente a compute clásico
Serverless prioriza operación gestionada y arranque rápido; classic compute ofrece mayor control de configuración y red.
En serverless, Databricks aprovisiona y optimiza el recurso, aplica versiones compatibles y cobra según uso. Es una opción natural cuando se busca reducir administración y el workload admite sus límites regionales, de red y de funcionalidad.
Classic compute se ejecuta con recursos configurables de la cuenta cloud y permite más control sobre runtime, tipos de nodo, políticas e inicialización. Ese control aumenta las decisiones operativas; no implica automáticamente mejor rendimiento o menor coste.
Modelo mental
Serverless y classic no son niveles de calidad; son modelos de responsabilidad. Serverless delega a Databricks la selección, provisión, escalado y actualización del compute compatible, de modo que el equipo se concentra en el workload. Classic expone decisiones sobre runtime, instancias, red, políticas e inicialización dentro de la cuenta cloud. La comparación correcta comienza por restricciones: conectividad privada, librerías, tipo de tarea, versión requerida, región y controles corporativos. Después se valoran arranque, elasticidad, coste y capacidad operativa. Elegir classic por costumbre añade superficie de mantenimiento; elegir serverless ignorando una limitación puede impedir la ejecución. El objetivo es el mínimo control necesario para cumplir requisitos verificables.
Capacidad gestionada por Databricks que se aprovisiona y escala sin configurar infraestructura subyacente.
Reduce operación cuando el workload y la conectividad están soportados.Recursos configurables en la cuenta cloud del cliente con mayor control de runtime, nodo y red.
Es necesario cuando una restricción no cabe en la superficie serverless disponible.Requisito de tarea, biblioteca, red, región o runtime que determina si una superficie puede ejecutar el trabajo.
Debe comprobarse antes de comparar rendimiento o coste.workload:
latency_sensitive: true
custom_runtime_required: false
private_dependency: false
operations_capacity: low
choice: serverless
La elección es válida solo si la región y las dependencias están soportadas.
Puntos clave
- Serverless elimina gran parte de la gestión de infraestructura
- Classic conserva opciones avanzadas de configuración
- La disponibilidad y conectividad varían por nube y región
Evita
- Elegir classic solo porque permite más parámetros
- Suponer que serverless permite cualquier init script o ruta de red
Recuerdo activo