My Geocode

Migración

Lista de comprobación para cambiar de host de API sin tiempo de inactividad

· 3 min de lectura · My Geocode · #sin-inactividad#lista-de-migración#geocodificación#despliegue#devops

Cambiar el host de una API en producción sin interrupciones es posible, pero exige tratar el cambio como un despliegue con su propio perfil de riesgo, no como una edición de configuración de una línea enviada directamente a producción. La diferencia entre una transición fluida y un incidente casi siempre está en la preparación, no en el momento del cambio en sí.

Antes del cambio:

  • Prepara las credenciales del nuevo host con bastante antelación y confirma que funcionan en un entorno de staging o de pruebas con patrones de solicitud reales, no solo con una única llamada de prueba manual
  • Instrumenta tu aplicación para que registre qué host atendió cada solicitud, aunque sea temporalmente, para poder verificar el progreso del despliegue y diagnosticar después cualquier problema por host
  • Confirma que tu sistema de configuración permite cambiar el valor del host sin volver a desplegar toda la aplicación, ya sea mediante una variable de entorno, un feature flag o un servicio de configuración remota, ya que un proceso que exige un despliegue por cada cambio reacciona más despacio si algo falla a mitad de la transición

Durante el cambio:

  • Aplica el cambio de forma gradual en lugar de todo a la vez si tu infraestructura lo permite: un porcentaje del tráfico, un servidor o región cada vez, o un endpoint no crítico antes que los demás
  • Vigila en tiempo real las tasas de error y los tiempos de respuesta durante el periodo de despliegue y compáralos directamente con tu referencia previa al cambio, no con un rango que se supone aceptable
  • Mantén activas y listas las credenciales del host anterior durante este periodo, para que volver atrás sea un cambio de configuración y no un nuevo despliegue

Después del cambio:

  • Deja que el nuevo host funcione con todo el tráfico durante un periodo de observación definido antes de dar por terminada la migración, ya que algunos problemas solo aparecen con carga sostenida o a determinadas horas del día
  • Compara los datos de respuesta reales del host antiguo y del nuevo para una muestra de solicitudes idénticas, si has registrado ambos, para detectar diferencias sutiles en los datos que las tasas de error por sí solas no revelarían
  • Retira las credenciales del host antiguo solo cuando haya pasado el periodo de observación sin problemas, en una fecha concreta decidida y no "algún día"

Como los hosts de compatibilidad de My Geocode reproducen la estructura exacta de solicitud y respuesta de un proveedor, el cambio real en el código de una migración basada en la compatibilidad suele limitarse al nombre del host y a la credencial de autenticación, lo que reduce la cantidad de código nuevo que se introduce durante la parte más arriesgada de la transición. La autenticación admite cuatro estilos, cabecera X-API-Key, Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, así que esta parte del cambio a menudo puede ser una simple actualización de configuración sin ningún cambio de código, según cómo esté estructurada tu biblioteca cliente actual.

Una migración sin tiempo de inactividad depende menos de una infraestructura ingeniosa y más de la disciplina: prepárate a fondo, despliega de forma gradual, vigila de cerca y conserva una vía de vuelta hasta que tengas la confianza suficiente para no necesitarla.

Más sobre migración