Plataforma de Datos Meteorológicos

Arquitectura

1. Proveedores meteorológicos

   modelos NWP, radar y satélite del BoM, alertas
2. Argo Workflows

   Kubernetes · GRIB2 → Zarr · PMTiles
3. Almacenamiento

   Cloudflare R2 · Supabase · OVH S3
4. Workers de borde

   KV · D1 · entrega R2-first
5. Mapa y clientes

   runtime MapLibre · apps en Vercel · APIs

La plataforma

Jane's Weather produce pronósticos, imágenes de radar y satélite y alertas para aplicaciones de consumo y para clientes como FarmOnline Weather de ACM. La producción de datos corre como Argo Workflows y CronJobs de Kubernetes en un clúster OVH en Sídney: las corridas de modelos en GRIB2 se convierten a Zarr, las imágenes de radar y Himawari se vuelven PMTiles y pirámides de teselas cada cinco minutos, las alertas del Bureau of Meteorology se ingieren en PostGIS. La entrega es storage-first: los frontends resuelven artefactos versionados en Cloudflare R2 a través de Workers, y un Worker proveedor de datos usa D1 y KV para catálogo y autenticación antes de recurrir a las APIs en Kubernetes.

El mapa

Mi primera responsabilidad fue el mapa. Diseñé y construí el runtime del mapa meteorológico que hoy es la experiencia de mapa canónica de la plataforma y de quienes la incrustan, como FarmOnline Weather: una aplicación React sobre MapLibre con PMTiles para mapas base y capas meteorológicas, dos modos (pronóstico, guiado por la línea de tiempo y los modelos; ahora, con prioridad al radar más satélite, observaciones y alertas), una abstracción compartida de capas temporales con precarga, y un contrato de incrustación URL-first para que los sitios asociados controlen modo, modelo, capas y vista desde parámetros de consulta.

El mapa es solo la mitad. También escribí el lado de procesamiento que lo alimenta: el modelo de configuración de capas, los scripts Python que convierten pronósticos en malla Zarr en isolíneas PMTiles, y los workflows Argo que publican artefactos de pronóstico, radar, Himawari, alertas y mapas base en R2 según horario, además de la herramienta de captura headless que renderiza imágenes estáticas de pronóstico para el sitio principal.

Operar toda la plataforma

Después de que la plataforma pasara a ACM y migrara entre nubes, el conocimiento de cómo encajaba estaba repartido entre repositorios, un espacio de Confluence desactualizado y la cabeza de las personas. El equipo de Territorial asumió toda la plataforma, y yo lidero ese trabajo. Construimos primero el programa de documentación: un sitio VitePress organizado por fronteras de sistema, con cada afirmación rastreada al código o a la configuración viva y cada vacío declarado explícitamente. Eso destapó riesgos concretos (el clúster de desarrollo sirviendo tráfico de producción, un cronjob de ingesta cuyo código desplegado venía de un repositorio distinto al que todos suponían, credenciales sin ruta de rotación) y los convirtió en incidencias con seguimiento.

Después, el monitoreo. Los exit handlers de Argo solo avisaban cuando un pipeline decía haber fallado; nada verificaba que los artefactos estuvieran realmente frescos y accesibles. Desplegamos Sentinel con una suite que hoy cubre los Workers de borde, las APIs en Kubernetes, el proxy del BoM, las fuentes de los modelos y los tres frontends, con umbrales de desfase calculados de forma independiente a partir de los horarios observados de llegada de los modelos, no de las banderas de la propia plataforma. En el día a día el equipo se ocupa del desarrollo y mantenimiento de las APIs y frontends, secretos y despliegues en Kubernetes, investigación de incidentes y postmortems (un rate limit de ECMWF, una migración de URL de GEM, un pico de gasto en Vercel, un crash loop por corrupción de NaN en la API de consumo).