Cuando inicié a trabajar en la nube, creía que la plataforma era similar a Google Drive o Dropbox donde se suben los archivos o las fotografías que ya no caben en tu teléfono, creía que un trabajo en estas plataformas estaban relacionado con subir archivos lo más rápido posible, y como eso parecía tan sencillo decidí empezar mi carrera en la nube.
De forma inicial el proyecto tenía como objetivo la migración de la carga de trabajo alojada en servidores físicos hacia la nube, específicamente en AWS y GCP, una vez que ví lo que era la nube ¡Quería renunciar! Pero en realidad necesitaba trabajar y decidí quedarme por la oportunidad de aprendizaje y supervivencia (ya que era mi primer trabajo remunerado). Aprendí buscando qué era cada herramienta que debía utilizar, buscaba “para qué sirve AWS” y lo comparaba con el requisito técnico solicitado en la compañía, también buscaba “¿Qué es una EC2 y cómo lanzarlo?” y lo lanzaba, lo mismo con todos los servicios que ofrece el proveedor, S3, RDS, y otras que recuerdo servían para conectar todo lo anterior que se había desplegado, como resultado, tuvimos una infraestructura funcional, pero no optimizada, me alegraba escuchar que éramos parte del proyecto más innovador de la compañía y el que nos salvaría de tener una historia similar a Kodak o blockbuster (spoiler alert, salió peor)
La estructura organizacional era clara, las peras con las peras y las manzanas con las manzanas, los equipos de compras eran los encargados de pagar al proveedor, y los equipos de infraestructura, sólo teníamos la tarea de usarlo.
Al final del año fiscal, el equipo de finanzas detectó que los costos eran excesivos, no porque sobrepasaron un presupuesto específico, si no porque no podíamos pagarlo. Por los recursos generados, que jamás supimos cuántos eran, tuvimos costos aproximados a los $10,000 usd mensuales con un equipo de 22 personas que desplegaba recursos diariamente, mientras que nuestros ingresos no eran ni la mitad de eso.
Con esto, identificamos 2 retos, el primero: no sabíamos qué recursos teníamos activos y su costo, por lo que no teníamos ni idea cómo optimizarlos, y el segundo, no sabíamos quién o quiénes eran responsables de ese proceso.
Ejecutamos un plan de alerta, que tenía como objetivo resultados rápidos, que nos permitiera seguir operando, eliminamos instancias, pausamos recursos, y se alcanzó un 20% de ahorro con respecto al promedio de nuestra factura ¡Salvados! Pero, al mismo tiempo restó funcionalidades derivado de la eliminación de recursos, después de ejecutar esto, mis búsquedas se transformaron en “cómo reducir recursos en la nube” con una pregunta interna “qué hago yo como ingeniera de infraestructura preocupada por los costos si no soy de finanzas” hoy en día claro que tendría una respuesta, pero mientras tanto, descubrí acciones de reducir costos -pero no de optimizarlos- elimine más recursos hasta tener un control estricto de quién desplegó, cómo cuándo y para qué, lo que era muy complejo y nada ágil, todos/as (incluyéndome odiamos “Cloud economics”) pero la realidad es que odiábamos las malas prácticas que ejecutamos en infraestructura, quién pensaría que todo está conectado en la nube.
Nuestros siguiente pasos de la estrategia organizacional me gusta nombrarlos como víctimas de bolsillo profundo e indeciso, porque se tomó la decisión de relanzar todas las funcionalidades iniciales que se detuvieron por el problema con los costos. Para ejecutarlo no hubo un presupuesto determinado y ocurrió lo que todos imaginamos, sobrepasamos un presupuesto que no fue estimado y eso nos quitó certeza para la estrategia cloud de la compañía siempre jugamos con la clásica pregunta ¿Siempre si? o ¿No que no? Después de este lanzamiento, realizamos otras acciones como apagado de instancias, redimensión de bases de datos, y establecimiento de políticas de ciclo de vida para S3 (finalmente veíamos la luz al final del túnel) los resultados se limitaron a un cambio constante de recursos y funcionalidades que agotaron a los equipos técnicos, tanto que se limitó el tiempo de mantenimiento, actualización, optimización, entre otras, y el producto sufría inconsistencias en el mercado, lo que generó una reducción de la demanda.

La siguiente limpieza de recursos, no sólo estuvo relacionada con lo tecnológico, también con lo humano, y perdí mi trabajo 🙁, al igual que muchos de mis compañeros de área, se dice que esa limpieza de recursos fue muy efectiva a nivel de costos, y algunos meses después la empresa abandonó la nube, lo que se conoce como “repatriación de la nube” así que yo me volví una hater de la nube, ahora sin trabajo, y sin nube, regresé a las búsquedas en internet, no sólo para buscar un nuevo trabajo, si no para obtenerlo y no perderlo.

Tras muchos años, me gusta catalogar esta historia como mi momento más humilde, pues fue una serie de eventos desafortunados que me llevaron a FinOps y que ahora, me siento feliz de recordar con cada proyecto que inicio para entender que los costos no sólo necesitan ser reducidos, requieren ser optimizados, y también recordar que en esta metodología no sólo hablamos de dinero, hablamos de cultura de innovación y valor (final feliz, he sido recontratada para ser FinOps en esa misma compañía en su reingreso a la nube)