Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Lista de comprobación para usar dos proveedores en paralelo
Usar dos proveedores al mismo tiempo suele ser un estado deliberado y temporal durante una migración, no una arquitectura permanente, pero necesita la estructura suficiente para no convertirse en un caos confuso de lógica condicional repartida por todo el código. Una lista de comprobación ayuda a que esta fase sea corta y a que su propósito esté claro.
Antes de empezar a enviar tráfico real a un segundo proveedor:
- Confirma que las estructuras de respuesta de ambos proveedores se han mapeado a una estructura de datos interna común, de modo que el código de tu aplicación lea de un único formato normalizado sin importar qué proveedor respondió realmente a cada solicitud
- Decide de antemano la lógica de reparto: porcentaje del tráfico, endpoints concretos, segmentos concretos de clientes o un modo sombra en el que se llama al segundo proveedor pero su resultado solo se registra, sin usarse
- Configura registros o etiquetas separados para poder saber después qué proveedor atendió cada solicitud, algo que importa muchísimo cuando algo falla y necesitas saber dónde mirar primero
Mientras ambos proveedores están activos:
- Compara las tasas de error y los tiempos de respuesta de los dos con regularidad, no solo una vez al principio, ya que el comportamiento puede variar a lo largo de días o semanas de formas que una única prueba inicial no detectaría
- Vigila las discrepancias en los resultados reales de los dos proveedores para una misma entrada y ten un proceso de decisión claro sobre qué hacer cuando no coinciden, en lugar de suponer que uno de ellos simplemente tiene razón
- Lleva una nota actualizada de cualquier patrón de solicitud que se comporte de forma claramente distinta entre los dos, ya que esos son justamente los casos que merece la pena probar a fondo antes de retirar el proveedor antiguo
Antes de retirar el proveedor original:
- Confirma que cada ruta de código que podría llamar al proveedor antiguo se ha probado realmente con el nuevo, no solo los casos más comunes
- Busca cualquier lógica de respaldo codificada de forma fija que suponga que el proveedor antiguo siempre está disponible, ya que los periodos con dos proveedores a veces dejan código de respaldo que nadie recuerda eliminar
- Fija una fecha concreta para desactivar el proveedor antiguo en lugar de dejar que el periodo con dos proveedores se alargue indefinidamente, ya que una transición sin fecha de cierre tiende a no terminar nunca
Los hosts de compatibilidad de My Geocode están diseñados precisamente para que la primera mitad de este proceso, la normalización de la estructura de respuesta, sea en gran parte innecesaria si el proveedor del que migras ya tiene un host equivalente, ya que la estructura se mantiene idéntica a la original y tu código de normalización actual (si ya tenías alguno) sigue funcionando sin cambios. La lista completa de 17 hosts de compatibilidad está en /compatibility/. Además, cada solicitud incluye cabeceras de cuota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining y otras, documentadas en /docs/rate-limits/, que son útiles para el paso de registro comparativo descrito arriba, sea cual sea el proveedor que se evalúe como segundo.
Un periodo con dos proveedores bien hecho es corto, está bien instrumentado y termina en una fecha planificada. Mal hecho, se convierte en un elemento permanente y confuso. La diferencia depende casi por completo de que una lista de comprobación como esta se siga en lugar de saltársela por la presión del tiempo.