Cuándo realizamos migraciones masivas o refactorizaciones muy grandes, cómo podemos garantizar que nuestro servicio siga funcionando como debería?
En esté post vamos a hablar de shadow testing
Índice
1 - Qué es shadow testing?
Shadow testing es una técnica que nos permite estar más seguros de hacer un cambio cuando vamos a producción.
Lo que hacemos con esta técnica es simple, cuando realizamos un cambio, y lo desplegamos, no vamos a reemplazar la aplicación que estaba corriendo sino que va a correr en paralelo.
Esto por que?
Lo que vamos a hacer es, cada request que vaya a nuestro servicio que corre en producción también la vamos a mandar a nuestro nuevo servicio:
Para que así podamos comparar que ambas respuestas del servicio son iguales y así garantizamos que el cambio no va a romper ninguno de nuestros clientes.
Hay diferentes técnicas y lugares donde se puede hacer, pero si tienes un proveedor de servicios como AWS se puede configurar en CloudFront para que la request a cierta URL también se haga a otra y luego puedes comparar los resultados (puedes poner código en cloudfront).
Si usas una API gateway propia como YARP o Ocelot, siempre puedes escribir el código de forma manual para hacer dicha comparación.
En cualquier caso como lo implementes o que tecnología no importa tanto como el concepto.
Lo que tenemos que hacer es comparar que las respuestas son iguales, tener monitoreo y logs, ya que los vamos a necesitar. No nos sirve de nada recibir una alerta diciendo que las respuestas no son iguales, necesitamos también saber porque no son iguales e idealmente necesitamos la request del usuario para poder replicar el escenario.
2 - Cuándo implementar shadow testing?
Lo ideal sería pensar que siempre, por lo menos durante un rato si despliegas una aplicación a producción, pero la realidad es que es mucho más fácil de decir y explicar que de implementar.
Implementar shadow testing tiene unos costes muy elevados, porque a primera vista estas duplicando el número de requests a un servicio. Pero, qué pasa si ese servicio llama a otro que a su vez llama a otro, y uno de estos dos están también siendo desplegados? Que el número de recursos que necesitas en el sistema crece exponencialmente, incluidos los recursos de la base de datos.
Por lo tanto es algo muy costoso, si lo vas a tener 10 minutos en horarios donde tu sistema no tiene mucha carga, quizá no notes diferencia, pero si por algún motivo te da por hacer un shadow testing con cada despliegue si que la notarás.
Además del coste monetario de la infraestructura tenemos el coste de mantenimiento y desarrollo, porque toda esta lógica hay que escribirla y mantenerla, que no es fácil.
Aún así hay situaciones donde nos puede salvar de problemas futuros.
A - Migraciones: Cuando migras una API de un sistema a otro, o de un lenguaje a otro, o incluso entre versiones del propio lenguaje, por ejemplo migras una app de NET Framework a la última versión de .NET, si la lógica de la app es medianamente compleja, deberíamos seguir las mismas prácticas que si migramos una app de ruby a Go, así que aquí podríamos tener ambas apps corriendo en paralelo, comparamos resultados durante un par de minutos/horas/días, todo va bien, desplegamos.
B - Refactorizaciones. En el mundo real rara vez se refactoriza una app de no ser porque una dependencia cambie o un proceso necesite un cambio grande, en esos escenarios donde cambiamos una gran porción del código también es ideal el estar seguros. Y si bien es cierto que tendremos nuestros test unitarios y de integración, pero este tipo de tests rara vez coge los “edge cases”. Así que tener ambas apps corriendo en paralelo y comparando resultados puede ahorrarnos problemas y disgustos.
3 - Combinar el Shadow Testing con otras técnicas
Lo ideal no es hacer únicamente Shadow testing, sino utilizar esta técnica dentro de nuestro conjunto de herramientas que usamos para verificar cambios en producción.
No por tener shadow testing en nuestro sistema tenemos que eliminar los test unitarios o los test de integración, ya que estos test cogerán los errores o problemas mucho antes que haciendo shadow testing.
Lo mismo aplica a tener múltiples entornos (dev/staging/prod), no por tener Shadow testing, entre otras técnicas debemos dejar de usar dichos entornos.
Idealmente, la técnica de shadow testing debería ser completamente transparente al desarrollador y tener todo el proceso completamente automatizado, yo por ejemplo lo he utilizado junto a canary deployments, esto quiere decir que, despliegas y corres ambas versiones en paralelo y pasado un tiempo, gradualmente se eliminan instancias de la versión antigua reemplazandolas por las nuevas.
