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.

¿Qué es ser nativo en la nube desde el día 1?

Hoy te contaré como tener procedimientos establecidos y teniendo una mentalidad de computación en la nube puede ayutdarte a despegar desde el momento que estás pensando tu idea.

¿Tu equipo de desarrollo conoce los servicios principales de tu proveedor de la nube? No estamos hablando que un desarrollador pueda crear una infraestructura desde cero sin la ayuda de nadie, no. Estamos hablando, que pueda identificar cómo resolver el problema usando las herramientas de la nube de forma nativa, por ejemplo "este procesamiento podría ser una función serverless" o decir "el motor de base de datos más adecuado es "X"", ese tipo de detalles y conocimiento son el tipo de ayudas que deberías de tener con un equipo que siente la nube en al sangre.

Cuando todo puede fallar, fallará (créeme)

Hablemos ahora de la recuperación ante desastres, algo bastante común, pero que la mayoría de las empresas no están totalmente preparadas, algo tan simple como programar que tu base de datos tenga un respaldo cada 24 hs (o menos según sea el caso) puede ayudarte a tener una menor pérdida de datos. La nube te puede ayudar para este tipo de cosas, aprovechala. No te olvides también de hacer pruebas de restablecimiento usando las herramientas nativas. Está comprobado que las empresas que hacen este tipo de pruebas están mucho más preparadas para recuperarse de forma segura.

Crecer pero con medida

Comenzando a trabajar en la nube la escalabilidad es otro factor sumamente importante, no es lo mismo reservar una habitación de hotel cuando estamos de vacaciones con nuestra familia que cuando estamos por negocios, los motivos de ambos viajes cambian, lo mismo pasa con la capacidad de cómputo, debes de tomar esas acciones y no quedarte fuera del juego por estar amarrado a una herramienta. Usar los servicios en la nube puede ser casi infinito, lo importante es usar los servicios adecuados, tener el conocimiento necesario y medir realmente lo que estemos usando.

Conclusión

Adoptar un pensamiento de nube nativo desde el dia uno es una estrategia que puede ayudarte a tener una base segura para seguir creciendo. Todos estos pilares te ayudarán a ganar escalabilidad, agilidad y sobre todo ser costo eficiente; un factor super importante al momento de moverse a una nube.

Extra tips:

• Tener un equipo que tenga la capacidad de hacer debug de su código local te ahorrá un montón de problemas.

• Dale la oportunidad a tu equipo de experimentar, de probar cosas nuevas, tener acceso individual y que puedan proponer nuevas ideas, eso hará que tu producto tenga un mayor impacto.

Pensar en Desarrollo nativo no es solamente para DevOps, todo lo contrario es para todo el equipo que participa en el ciclo de vida de tu aplicación, anima a tus devs a que aprendan más conocimientos del mundo cloud.

Ya que llegaste hasta acá ¡Estemos en contacto! escríbeme por LinkedIn y dime que tal te pareció el artículo

Héctor Fernández

AWS Community Builder
LinkedIn: Hector Fernandez