Guía para principiantes de Snowpark Container Services: bloques fundamentales y precios

Snowpark Container Services te permite ejecutar aplicaciones en contenedores directamente dentro de Snowflake. Es la versión de Snowflake de AWS ECS, Google Cloud Run o Azure Container Instances. Pero en lugar de ejecutarse en tu cuenta cloud, tus contenedores corren en el entorno de cómputo de Snowflake y tienen acceso nativo a tus datos en Snowflake.

Lo mejor es que tus contenedores pueden consultar directamente tablas de Snowflake, llamar a funciones de Snowflake y acceder a tus datos sin necesidad de crear una cuenta de servicio, gestionar credenciales para el acceso a datos ni mover datos fuera de la plataforma. Además, a los usuarios de tu app se les otorga acceso con un simple grant, así que no necesitas desarrollar software de autenticación ni gestionar usuarios/contraseñas, etc. Hace poco desplegué una app en contenedor para un cliente de AWS / Snowflake, y eligieron SPCS en lugar de ECS porque la gestión de usuarios y la seguridad son mucho más simples.

Hay muchísimos artículos con ejemplos de cómo desplegar apps en Snowpark Container Services. En este artículo nos vamos a enfocar sobre todo en los bloques fundamentales (terminología), los precios y algunas particularidades o diferencias frente a los servicios de contenedores tradicionales.

Veamos los cuatro objetos principales con los que vas a trabajar:

1. Image Repository

Es el registry de contenedores de Snowflake, similar a Docker Hub o Amazon ECR. Subes ahí tus imágenes Docker y Snowflake las descarga al iniciar tus services.

1CREATE IMAGE REPOSITORY my_app_repo;

Snowpark Container Services no descarga imágenes directamente desde registries externos como Docker Hub. Puedes usar imágenes base públicas al hacer el build en local, pero antes de desplegar en Snowflake debes subir la imagen final a un image repository de Snowflake dentro de tu cuenta. Los services solo pueden ejecutar imágenes almacenadas en el sistema de repositorios propio de Snowflake.

2. Compute Pool

Aquí es donde las cosas se apartan de lo que quizás ya conoces. Un compute pool es un conjunto de instancias de máquinas virtuales que ejecutan uno o varios contenedores. Piénsalo como tu clúster de nodos, capaz de correr muchos services o apps.

CREATE COMPUTE POOL my_pool
  MIN_NODES = 1
  MAX_NODES = 3
  INSTANCE_FAMILY = CPU_X64_XS
  AUTO_RESUME = TRUE
  AUTO_SUSPEND_SECS = 60;

Parámetros clave:

• MIN_NODES / MAX_NODES: cuántas instancias VM pueden ejecutarse (esta es tu capacidad, no tus contenedores). El mínimo de nodos debe ser mayor que cero. Se auto-suspende si no hay services activos.
• INSTANCE_FAMILY: el tamaño/tipo de VM (CPU_X64_S, CPU_X64_M, GPU_NV_S, etc.)
• AUTO_RESUME: si el pool arranca automáticamente cuando se necesita
• AUTO_SUSPEND_SECS: cuánto tiempo esperar antes de suspender un pool inactivo sin services en ejecución.

3. Service

Un service es la aplicación en contenedor en ejecución. Define qué imagen ejecutar, cuántas instancias (contenedores) iniciar y cómo enrutar el tráfico hacia ellas.

-- código mínimo requerido:
CREATE SERVICE my_web_app
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml';

-- propiedades más comunes...
CREATE SERVICE my_api_service
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 5 -- Escala hasta 5 según CPU
  MIN_READY_INSTANCES = 1 -- Se requiere al menos 1 para que el service esté listo
  EXTERNAL_ACCESS_INTEGRATIONS = (api_eai, cdn_eai)

Expandir código

El service lee un archivo de especificación YAML (almacenado en un stage) que describe tus contenedores, similar a un deployment de Kubernetes o a un archivo de Docker Compose. Aquí tienes un ejemplo de SPECIFICATION_FILE.yml que el service leerá al iniciar:

spec:
  containers:
  - name: my_app_container
    image: /dbt_dev/my_app/repo/my_app_container:latest
    env:
      # variables de entorno de tu app aquí
      ## Esta app lee datos de Snowflake usando estas variables
      SNOWFLAKE_WAREHOUSE: COMPUTE_WH
      SNOWFLAKE_DATABASE: FIVETRAN
      SNOWFLAKE_SCHEMA: SAP_ECC
      SNOWFLAKE_ROLE: DBT_ROLE
      APP_HOST: 0.0.0.0
      APP_PORT: "8080"
    readinessProbe:
      port: 8080

Expandir código

4. External Access Integration (opcional)

Si tu contenedor necesita llamar a APIs o servicios externos fuera de Snowflake, necesitas una external access integration. Es la forma que tiene Snowflake de controlar el acceso saliente a la red.

CREATE EXTERNAL ACCESS INTEGRATION my_api_access
  ALLOWED_NETWORK_RULES = (my_network_rule)
  ENABLED = TRUE;

Como ves, hay conceptos nuevos muy específicos de este servicio. El conocimiento general de Snowflake o de la nube te ayudará a arrancar, pero hace falta familiarizarse con estos términos.

En mi opinión, los precios de SPCS son bastante razonables. Sale más caro que los servicios de contenedores tradicionales (ECS, Cloud Run, ACI), pero los beneficios adicionales de la gobernanza de Snowflake y la cercanía a los datos muchas veces lo justifican. Aquí están los distintos cargos asociados con SPCS.

Compute Pools

El principal componente de facturación de SPCS son los compute pools. A simple vista, SPCS parece muy accesible. Un Extra Small cuesta apenas 0.06 créditos por hora. A USD 3 por crédito, un XS costaría USD 4.32 al día o USD 1576 al año. Hardware similar en Cloud Run costaría poco menos de USD 3 al día. Así que SPCS es más caro, pero ofrece los beneficios adicionales que ya mencionamos.

Cuando un compute pool se reanuda, se factura un mínimo de 5 minutos.

Comparación con los costos de los Snowflake Virtual Warehouses

Frente a los virtual warehouses de Snowflake, el warehouse más pequeño cuesta 1 crédito por hora. SPCS ofrece una alternativa mucho más económica para tareas ligeras como ejecutar scripts de Python o alojar notebooks. Como vimos arriba, ¡puedes correr un nodo de cómputo al 6% del costo total de un virtual warehouse XS!

Costos de almacenamiento

El almacenamiento es barato y SPCS no consume demasiado, pero conviene tener este aspecto en cuenta. Estas son las distintas formas en que se te podría facturar almacenamiento:

• Image Repository: se implementa como un stage, así que aplican las tarifas estándar de almacenamiento.
• Block volumes para contenedores: almacenan el estado de tu aplicación, similar a AWS EBS o Google Persistent Disk. Es el aspecto más caro en cuanto a almacenamiento. Va de USD 82 a USD 100 por TB al mes, aproximadamente.
• Logging hacia la event table de Snowflake (almacenamiento estándar)
• Cualquier otro stage o tabla que use tu app (almacenamiento estándar)

Aquí es donde a muchos recién llegados (yo incluido) los toma por sorpresa. Si estás acostumbrado a Cloud Run, AWS Lambda, ECS o plataformas de contenedores "serverless" similares, quizás esperes que tu service se apague automáticamente cuando nadie lo está usando. No lo hace.

La realidad de los costos de SPCS

Ben Franklin dijo: "La experiencia es la mejor maestra, pero el tonto no aprende de ninguna otra". Por desgracia, yo aprendí lo siguiente a las malas, ¡así que ojalá tú puedas aprender de mis errores!

Los compute pools tienen AUTO_SUSPEND_SECS, pero solo aplica cuando el pool está vacío. Si tienes un service corriendo en el compute pool, el pool sigue activo. Configurar AUTO_SUSPEND_SECS = 60 en tu compute pool no suspende el pool si hay un service en ejecución, y los services no se suspenden por sí solos.

Los services corren 24/7 por defecto. Cuando creas un service con MIN_INSTANCES = 1 (0 no está permitido), Snowflake mantiene un contenedor corriendo constantemente. Eso significa que estás pagando cómputo 24/7 hasta que suspendas explícitamente el service. A diferencia de Cloud Run, no escala a cero cuando nadie lo usa. La propiedad auto_suspend_secs del service está en preview; funciona para apps internas que no tienen endpoints públicos, como las Service Functions y las comunicaciones Service to Service. Pero las apps web en contenedores no se auto-suspenden cuando están inactivas. Snowflake solo rastrea las llamadas internas a service functions para determinar la inactividad, no el tráfico HTTP de entrada.

Como dije arriba, sigue siendo asequible gracias a la baja tasa de consumo de créditos, incluso si dejas todo corriendo 24x7 (USD 4.32 al día asumiendo USD 3 por crédito y un XS). Es algo a tener presente porque a mí me tomó por sorpresa.

El baile de suspensión en dos pasos

Para que el compute pool se auto-suspenda, primero debes suspender el service:

-- Paso 1: Suspender el service
ALTER SERVICE my_app SUSPEND;

-- Paso 2: Ahora AUTO_SUSPEND_SECS entrará en acción si esperas
-- O puedes forzarlo de inmediato:
ALTER COMPUTE POOL my_pool SUSPEND;
-- puedes suspender el compute pool por sí solo, lo que suspenderá el service.

El auto-resume funciona (pero solo para los services)

Aquí está el lado positivo: aunque los services no se auto-suspenden, sí se auto-reanudan cuando alguien accede a su endpoint, pero solo si lo habilitas:

ALTER SERVICE my_app SET AUTO_RESUME = TRUE;

-- Ahora:
-- 1. Suspendes manualmente el service
-- 2. Alguien llega al endpoint del service
-- 3. El service se despierta automáticamente
-- 4. El compute pool se reanuda automáticamente (porque AUTO_RESUME = TRUE en el pool)

Estrategias para gestionar los costos de Snowpark Container Services

Dadas estas limitaciones, aquí van algunos enfoques prácticos si no quieres que tu app corra 24x7:

1. Suspend/Resume manual (ideal para Dev/Test)

-- Cuando termines de trabajar:
ALTER SERVICE my_app SUSPEND;

-- El service se auto-reanudará cuando alguien acceda
-- Es manual, pero confiable

2. Tareas programadas (bueno para uso predecible)

-- Suspender todas las noches a las 6 PM
CREATE TASK suspend_service_nightly
  SCHEDULE = 'USING CRON 0 18 * * * America/New_York'
AS
  ALTER SERVICE my_app SUSPEND;

-- se auto-reanudará cuando alguien lo use después.

3. Monitorear y alertar (esencial en producción)

-- los comandos show no se ejecutan en un warehouse
SHOW SERVICES;

-- Si quieres usar SQL para cálculos y filtrado...
SELECT
  service_name,
  status,
  compute_pool_name,
  current_instances,
  DATEDIFF('hour', last_resumed, CURRENT_TIMESTAMP()) as hours_running
FROM INFORMATION_SCHEMA.SERVICES
WHERE status = 'RUNNING';

Acceder a URLs de SPCS suspendidas

Cuando el service está suspendido, el usuario verá este error al visitar la URL:

{
  "responseType": "ERROR",
  "requestId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "detail": "Service EXAMPLE_SERVICE not reachable: no service hosts found."
}

Mientras el service y el compute pool tengan auto-resume habilitado, empezarán a levantarse cuando el usuario intente entrar a la URL. Tardará unos 39-60 segundos y luego podrá refrescar la página. La experiencia no es la más óptima, pero tampoco es terrible si los usuarios saben qué esperar.

Como los Compute Pools de SPCS tienen un costo por crédito mucho más bajo, podemos aprovecharlos como una forma mucho más económica de correr jobs batch en Python (o en cualquier lenguaje) dentro de Snowflake. Supongamos que tienes un job de Python ya empaquetado en un contenedor y subido a un registry de Snowflake, además de un archivo YAML que describe el service y está cargado en un Stage. Entonces puedes lanzar un comando execute job service ... para ejecutar el código de ese contenedor. Estos services se apagan al terminar, lo que permite que el Compute Pool se auto-suspenda con normalidad. ¡Un buen truco para aprovechar cómputo más barato en Snowflake!

EXECUTE JOB SERVICE
  IN COMPUTE POOL my_compute_pool
  NAME = my_batch_job
  FROM @my_stage
  SPEC = 'job_spec.yaml';

La UI de Snowsight ofrece una forma cómoda de monitorear el gasto de SPCS. Con el rol accountadmin o uno con acceso a monitorear el uso, ve a Admin → Cost Management → Consumption y cambia el filtro Service Type a SPCS.

✅ Crea un rol dedicado para la gestión de contenedores

✅ Configura la base de datos, el schema, el image repository y el stage

✅ Configura la external access integration si vas a llamar a APIs externas

✅ Crea el compute pool con el tamaño adecuado y la configuración de auto-suspend

✅ Sube la especificación del service al stage

✅ Crea el service con AUTO_RESUME = TRUE

✅ Documenta los procedimientos de suspensión manual o crea tareas programadas

✅ Define queries de monitoreo para rastrear los services en ejecución y los costos

✅ Prueba el ciclo de suspend/resume antes de desplegar a producción

Snowpark Container Services lleva el poder de las aplicaciones en contenedores directamente a tus datos en Snowflake. Pero hay una curva de aprendizaje: hace falta entender los image repositories, los compute pools, los services y cómo se relacionan entre sí. Una vez que dominas estos bloques fundamentales y las particularidades de la gestión de costos, puedes construir aplicaciones de datos potentes que corren junto a tus datos sin tener que salir nunca de la plataforma Snowflake.

Jeff es Consultor de Data y Analytics con más de 15 años de experiencia automatizando insights y usando los datos para controlar procesos de negocio. En el plano tecnológico, se especializa en Snowflake + dbt + Tableau. En el plano de negocio, tiene experiencia en Servicios Públicos, Ensayos Clínicos, Publishing, CPG y Manufactura. Escríbele cuando quieras: [email protected].