Ephemeral environments ¿Cómo crearlos?

Si estás en el mundo del desarrollo de software de seguro te ha pasado en alguna oportunidad que fantaseas con tener una copia de producción para poder hacer tus pruebas y asegurarse que la integración funciona complementamente.

No estás solo/a mí también me pasa, y es por eso que hoy quiero contarte cómo puedes hacer para estar un paso más cerca de tener tu propio ambiente de desarrollo "production like" sin necesidad de estar dependiendo de terceros.

¿Qué es un ambiente efímero o temporal (Ephemeral environments)?

Primero lo primero, son ambientes que se crean para una única finalidad (desarrollo, QA, e2e, etc) se usan y luego se destruyen. Nada permanece en estos ambientes (es la idea), y lo mejor de todo debes poder hacerlo en cuestión de minutos, NO en horas.

A poco no estaría bueno poder hacer los cambios de código que necesitas, crear un Pull Request y en la misma descripción tengas un link a un ambiente completamente creado desde 0 con todo listo para probar esos cambios y asegurarte que lo que fue reportado ya está solucionado.***¿Dime que no?***de esto te estaré contando en las próximas líneas.

Los ambientes efímeros cómo el de la foto anterior, se usan para probar integraciones, hacer demos o desarrollar de forma aislada sin la tediosa necesidad de levantar 245 mil nodos de kubernetes localmente para probar un formulario que está fallando. En algunas ocasiones se le conoce como “ambientes preview”, si bien son similares no son la misma cosa.

La finalidad de crear estos ambientes, es que puedas tener algo para tí, es decir que no dependas de otro programador. De seguro ya te ha pasado antes de tener que esperar que alguien termine de usar la base de datos de desarrollo para poder hacer tus pruebas.

¿Cómo ayudan los ambientes efímeros en el desarrollo de software?

• Agilidad: sí suena “cliché” aún en el 2024, pero muchos equipos hablan de ser "ágiles", pero cuando se le pide poder tener una réplica del ambiente que están desarrollando las ranas suenan en el río. No quisiera entrar en detalle en cuestiones de costos, ya que muchos hablan de las “limitantes” por costos operativos, pero a mi entender, no va por ahí el tema.

• Aumenta la confiabilidad de lo que estás entregando: si eres QA o desarrollador de software, vas a poder detectar y eliminar errores con una precisión milimétrica antes de que salgan a producción.

• Colabora con tu equipo a otro nivel: ahora podrás mostrarle a tus compañeros en un lugar controlado tus dudas o consultas sobre el desarrollo que estás haciendo en ese momento.

Aprovecha la Infraestructura como código (IaC) que ya creaste

Se supone que ya en tu proyecto tienes toda la infraestructura gestionada mediante código (Serverless, Terraform, Pulumi, CDK, etc) ¡Aprovechala! ya lo más difícil está hecho, que es crear toda la infra necesaria, ahora lo que necesitas es crearte una “mini” versión de todo tu ambiente en cuestión de minutos.

No necesitas tener un supercomputador para desarrollar.

Algunas aplicaciones por su naturaleza tienen un montón de dependencias, como pueden ser microservicios en kubernetes, colas de mensajes y similares que deben estar activos para poder “replicar” un ambiente productivo. Hoy en día con las nubes públicas (AWS, Azure, GCP, etc) puedes lograrlo sin quedarte sin presupuesto al día siguiente.

Deja de estar emulando la nube

No pierdas tiempo en eso, ne hubiese gustado que me dijeran esto hace años. Enfócate en entregar algo de valor desde el día 1. Tus pruebas en un "Ephemeral environment" será mucho más real a lo que pasará en producción, entonces por qué seguir usando contenedores que no sabes cuándo fue la última vez que se actualizaron, o si en un futuro seguirá teniendo soporte.

Hace poco el caso de Terraform y OpenTofu nos dejó esto en claro, las reglas de negocios de terceros pueden cambiar en cualquier momento.

Long live the king “Ambiente de QA/ Desarrollo (o como lo llames)”

Estamos en la era de la nube y de la Infraestructura como código (IaC), si seguimos aferrándonos a los ambientes eternos “Dev, QA, Staging, etc” es como que sigamos alquilando películas cuando ya tenemos servicios de streaming mucho más eficientes.

Los costos fijos, estos ambientes perpetuos vienen de la mano con costos fijos, lo estés usando o no. Por otro lado,también tiene falta de flexibilidad o hablame de cuando teníamos que abrir puertos usando nginx para microservicios y lo lindo que lo pasabamos rezando que nada fallara. Lentitud, pasar de un ambiente a otro siempre fue lento, ya que necesitamos no solo la aprobación del cambio sino también que el ambiente quedará libre para nosotros poder hacer las pruebas que necesitamos y no entorpecer el trabajo del otro.

Recuerda que acá, todo se construye en cuestión de minutos y de la misma forma se destruye, por lo que no tienes que preocuparte si un compañero del equipo dejó “tal” cosa corriendo fuera de la jornada.

Sin cuellos de botella, no tienes que esperar por alguien más, cuando lo necesitas mandas a crear tu ambiente y en cuestión de segundos o minutos (dependiendo de tu caso) podrás tener un setup listo.

Consistencia de datos:

Te recuerdas tener que sincronizar datos o preguntar “quién” o “cuándo” podría hacerse un respaldo de la data de producción (anonimizar) y pasarla a un ambiente en particular. Eso sí que era una verdadera pesadilla.

• Inconsistencias: Tenias un usuario favorito, llamemoslo “Capybara”, resulta que ese mismo usuario no existe entre otros ambientes por lo que tienes que ir creándolo cada vez que quieras hacer una prueba.

• Adiós “Capy”: Alguien por error borró tu usuario estrella y ahora no tienes forma de sacar registros o hacer las integraciones que tenías en mente. Esa pérdida de información es tiempo que no puedes recuperar. Muchas veces es sin intención, pero pasa.

• Procesos manuales: Esos seeds que iban y venían entre desarrolladores, algunos tienen alguna data y otros tenían un juego de datos diferentes. Todos esos procesos manuales son los que nos llevan a incurrir en errores. Somos humanos (prometo que este post fué escrito por mí), y podemos llegar a cometer errores, la intención es minimizarlos y trabajar de forma más eficiente.

Manos a la masa (al teclado) y creemos uno

Por ahora hemos venido hablando de lo que és un Ephemeral environment y las ventajas frente a entornos long time tal y cómo los conocemos. Ahora me gustaría dejarte un plan de acción para implementar esta metodología y crear tu propio ambiente temporal con pocos pasos y valiéndonos de la ayuda que Git ya nos brinda hoy en día.

1) Tener una Infraestructura como Código ya definida

Sin dudas es el primer paso, así que si aún no la tienes te invito a que empieces usando la herramienta que más te convenga *(****Extra tip:***si eres programador utiliza CDK que son más amigables para arrancar).

2) Definir un flujo de trabajo

Tendremos que definir en qué momento se crean estos ambientes temporales. Por poner un ejemplo, quiero que al momento de crear una Pull Request quiero que se cree un ambiente y me disponibilize una URL. Es un simple ejemplo, dependerá según la cantidad de personas que están en el equipo y la forma como manejan el “merge” de código.

3) Variables de entorno

¿En tu aplicación se necesitan variables de entorno para integrarse con terceros o similar? Bueno es un buen punto para pensar en repositorios seguros como AWS Secret Manager o AWS Parameter Store, ya que a este ambiente que vamos a crear necesitas poder acceder a estos valores.

4) Integraciones con CI/CD

Todo esto no ocurre al tronar los dedos, debemos de definir dentro de nuestras pipes de CI/CD para que se despliegue nuestro ambiente cada vez que lo necesitemos. En este caso te tendrás que hacer amigo de las “actions” y dominarlas.

5) Datos iniciales

Al ser un ambiente nuevo, recuerda que no tendrá ningún dato para probar, lo mejor será definir junto con el encargado de datos que juego de datos necesitamos sí o sí para que nuestra aplicación tenga un comportamiento similar a lo que pasaría en producción. Esos datos deben ser cargados mediante “seeds” y actualizados a lo largo del tiempo.

6) Borremos todo

Recuerda que la ventaja de este ambiente es que tiene una vida útil corta, por eso debemos definir en qué punto se debe borrar este ambiente. Por citar un ejemplo, podríamos decir que queremos que se borre al “mergear” una Pull Request en nuestra rama principal. Ya con esto definimos en qué momento dejará de existir nuestro ambiente y también cuando dejaremos de pagar por él.💲💲💲

¿Para qué se pueden usar estos ambientes temporales?

Los entornos efímeros son ideales para:

Pruebas:

Validación precisa y eficiente del código en diferentes escenarios, asegurando su correcto funcionamiento. Pensando como Dev, tener la capacidad de probar cosas de forma aislada, es un camino de ida sin lugar a dudas.

Integración:

Verificación de la interoperabilidad entre diferentes componentes del sistema, previniendo problemas de compatibilidad. No más tiempo muerto entre QA o entre Devs

Despliegues:

Implementaciones controladas y escalables a producción, minimizando el tiempo de inactividad y maximizando la disponibilidad. También se puede usar para crear una demo comercial en poco tiempo.

Conclusiones

Los entornos efímeros o Ephemeral environment se han convertido en una herramienta poderosa para optimizar la velocidad de entrega de aplicaciones sin servidor. En conjunto con soluciones CI/CD, estos entornos desechables permiten un desarrollo y una implementación más ágiles, consistentes y eficientes.

Estos ambientes están muy orientados a arquitectura sin servidor “serverless” pero no quiere decir que no puedas tener un ambiente de kubernetes usando esta metodología, puedes hacerlo es cuestión de pensar cómo optimizar los recursos que ya tienes activos, por ejemplo no tienes que darle un cluster a cada usuario, podrías usar uno compartido y entregarles un ambiente virtual a cada uno de los desarrolladores.

Usa la Infraestructura como código como más puedas, ya el mayor camino lo tienes ganado. Así mismo no dejes “hardcoded” valores de recursos, en su lugar usa variables que según el stack que se quiera crear se llamen de otra manera.

Recuerda, no dejes de experimentar, es una ventaja del mundo cloud.

Gracias por llegar hasta acá ¡Estemos en contacto! escríbeme por LinkedIn y dime que tal te pareció el artículo, tu aporte me ayuda a seguir creciendo.

LinkedIn: Hector Fernandez

Final Summary: How to Deploy Ephemeral Environments, Infraestructure as Code. Cloud.