Aspectos clave a la hora de aplicar FinOps en tu empresa
Hace unas semanas publicamos ya un capítulo relativo a FinOps en nuestro podcast Querida Tecnología. Dado que está teniendo muy buena acogida y que por falta de tiempo se nos quedaron algunas cosas interesantes en el tintero, me ha parecido buena idea hacer también un post al respecto que lo complemente.
Primero que nada, es importante entender el contexto en el que surge FinOps y la problemática a la que trata de dar solución. La adopción del Cloud lleva varios años extendiéndose y, a día de hoy, ya son pocas las empresas que no hayan migrado sus cargas de trabajo a la nube, si no de forma total, al menos en gran parte.
Es fácil dejarse llevar por cómo el Cloud facilita todo lo relativo a aprovisionamiento y gestión de la infraestructura. También maravillarse por cómo nos permite acelerar la innovación y darle vida de forma muy ágil a una idea que pueda beneficiar a nuestro negocio, haciéndonos más competitivos, gracias a la facilidad con la que podemos beneficiarnos del uso de servicios digitales punteros, o construir y desplegar un desarrollo de manera muy eficiente.
Sin embargo, si no se entienden y se controlan bien los costes que hay por debajo de tanta magia, nos podemos encontrar con un volumen de gasto inesperado y elevado que ponga en peligro la rentabilidad de nuestro proyecto de movimiento a la nube.
Venimos de estar trabajando y desarrollándonos durante muchos años en un modelo de funcionamiento con un enfoque on premise, en el que no se daban dos pasos seguidos sin tener aprobado todo un señor Capacity Plan, con su presupuesto bien ajustado y negociado, que conllevaba la compra de una serie de dispositivos tangibles y que tardaban su tiempo en recibirse, instalarse, configurarse, etc., para pasar, de forma relativamente rápida, a un modelo muy diferente sobre el que aún tenemos margen para madurar. Un modelo Cloud en el que ganamos eficiencia, pero perdemos control sobre las cosas, que es menos tangible y muy fácil de aprovisionar y de escalar cuando llega la necesidad. Pero toda esta maravilla se puede convertir en una trampa desde el punto de vista económico, si no se aplican conceptos de control financiero similares a los de siempre, solo que adaptados al mundo Cloud y no se entienden bien las nuevas reglas de juego que hay que saber aplicar y aprovechar.
También me parece importante poner sobre la mesa uno de los principales fallos estratégicos que se cometen a la hora de plantearse el Move to Cloud. Me refiero a plantearse la conveniencia de ir a la nube solamente pensando en el "Ahorro de Costes" que nos puede reportar, ya que pensar solamente en este aspecto puede resultar engañoso si no se tienen en cuenta otros factores, lo cual puede llevarnos a la frustración de no entender los motivos por los cuales una inversión de este tamaño no está siendo rentable, a pesar de lo bonito que nos lo vendieron.
Y es que debemos migrar a la nube con la convicción del valor significativo que aportará al negocio desde una perspectiva amplia y a largo plazo, no con una visión cortoplacista. A la nube hay que ir convencidos del valor que aporta el poder innovar más rápido, así como el disponer con mayor facilidad de unas infraestructuras y arquitecturas más flexibles y escalables, más seguras, fiables y con mayor alcance geográfico, más versátiles a la hora de evolucionar y de integrarse con otros sistemas, con un mayor nivel de mantenibilidad, etc.
Porque si bien el coste de la nube, a igualdad de condiciones, sí que es menor que su correspondencia en on premise, o al menos eso indican las calculadoras de TCO (Total Cost of Ownership) de los distintos proveedores Cloud, si es que éstos no nos engañan, hay una serie de factores que si no se controlan, o no se saben aprovechar, pueden hacer que se invierta la balanza. Aspectos como dejar activos recursos que ya no se utilizan, o dejarlos en marcha en momentos en que realmente no se necesitan, serían algunos ejemplos de ello.
Pero que no cunda el pánico, porque para ello surgió una vez más la Linux Foundation para poner orden y criterio y ayudarnos a controlar bien todo este asunto mediante la creación, el mantenimiento y la difusión de lo que se conoce como FinOps, a través de la FinOps Foundation.
FinOps es, en esencia, un marco de trabajo operacional y una práctica cultural que tiene como objetivo ayudarnos a maximizar el valor que puede aportar la nube a nuestro negocio. Para ello, se apoya en dos pilares fundamentales, la toma de decisiones oportunas basadas en datos y la responsabilidad financiera compartida mediante la colaboración entre las áreas de Ingeniería, Finanzas y Negocio.
FinOps no va estrictamente de gastar menos, sino de gastar de manera consciente, invirtiendo con meditada cautela donde más lo necesite nuestro negocio y gastando lo menos posible donde haga menos falta. Es aprovechar los beneficios que hemos comentado antes que la nube puede aportar a nuestro negocio, pero de una manera sostenible para éste. Es decir, sabiendo controlar y dirigir el gasto, para ir alineados con los beneficios que requiere nuestra empresa.
Como marco de trabajo que es, FinOps se compone de diferentes capacidades, prácticas, roles, fases, etc., tal y como se puede apreciar en la siguiente imagen, si bien en este artículo me centraré en tratar de que se entiendan bien sus 6 principios, ya que son la base sobre la que se sostiene todo los demás. Además, lo haré desde la perspectiva de un rol de ingeniería/tecnología, ya que es el que me corresponde y también es al que muchas veces le puede parecer que todo esto de la economía de la empresa es cosa de otras áreas, cuando en realidad es cosa de todos. Y es que, como bien argumenta Werner Vogels, VP y CTO de Amazon, en The Frugal Architect (una genial guía online en la que establece también una serie de leyes o principios para construir arquitecturas modernas, pero que a su vez sean también sostenibles y que tengan en cuenta los costes), las empresas pueden fracasar por no tener en cuenta los costes en cada fase de la construcción de soluciones tecnológicas para dar soporte e impulso al negocio (desde el diseño hasta el desarrollo y las operaciones), o por no medirlos adecuadamente. Las matemáticas son sencillas: Si los costes son superiores a los ingresos, la empresa está en peligro.
Pues bien, no me extenderé mucho con el primero de los principios de FinOps, ya que en realidad ya he estado hablando al respecto. Básicamente, consiste en que los diferentes equipos de la empresa necesitan colaborar: Financiero, Negocio y Tecnología deben trabajar juntos a la hora de definir soluciones eficientes e innovadoras, pero sostenibles de cara al negocio.
El segundo principio, indica que todas las decisiones deben estar guiadas por el aporte de valor que suponga para el negocio. Para ello, es recomendable tratar de mantener, en cada caso, el balance que se considere más apropiado entre estos tres parámetros: Coste, Calidad y Velocidad, o lo que también se conoce como el Triángulo de Hierro. Si una empresa requiere apostar más por la calidad con respecto a un caso de uso, probablemente esto conllevará un mayor coste. Si considera más apropiado apostar por la velocidad, puede que tenga que sacrificar la calidad. Mientras que centrarse en los costes, si no se hace adecuadamente, puede perjudicar tanto a la calidad como a la velocidad. Esto se debe a que un enfoque centrado de forma desmedida en los costes, a menudo deja a los equipos perdidos en los detalles, en lugar de mirar la foto global.
Atendiendo a este principio, es importante que en la fase de toma de requisitos consideremos también el Coste como un requerimiento no-funcional más, de igual modo que consideramos otros como la Mantenibilidad, Portabilidad, Seguridad, Escalabilidad, etc. También es importante que todos los equipos sean conscientes de la dimensión en la que obtiene beneficio el negocio, para luego asegurarse de que la arquitectura que se defina vaya en la misma dirección, evitando dejarnos cegar solamente por los aspectos más techies (y aquí, el que esté libre de pecado, que tire la primera piedra...). Como ejemplo, si pensamos en una empresa de e-commerce, podemos concluir que la dimensión en la que se obtiene el beneficio viene determinada por el número de pedidos. Por tanto, en este caso sería comprensible asumir que un aumento en el número de pedidos conlleve un aumento de costes a nivel de Infraestructura y de Operaciones de la solución subyacente, además de que ésta esté lo más optimizada posible aunque nos suponga determinado gasto. En contraposición, otros casos de uso que no aporten tanto beneficio directo para nuestro negocio podrán estar menos dimensionados, o estar temporalmente desescalados, así como implementados mediante servicios y recursos mucho más económicos. Ahora bien, esto no quita que el sistema de pedidos tendrá que estar también óptimamente diseñado pensando en los costes, tratando de aprovechar al máximo los beneficios de economía de escala que proporciona la nube, tal y como veremos un poco más adelante.
El tercer principio consiste en que la responsabilidad con respecto al (buen) uso que se haga de los recursos de la nube debe ser compartida entre todos. Por la parte que nos toca a los que estamos más próximos al ámbito de la tecnología, esto significa que los equipos técnicos también debemos ser conscientes de los costes, desde el diseño de la arquitectura hasta las operaciones. Tenemos que tener en cuenta también el gasto a la hora de valorar cuándo interesa más utilizar en nuestro diseño una función serverless (FaaS) frente a un pod de Kubernetes, por ejemplo (a parte de las propias features de cada tecnología y de otros aspectos como el vendor lock-in, etc., por supuesto), o qué servicios Cloud son más rentables frente a otros.
También es importante ser conscientes de que, en materia de Arquitectura, toda decisión conlleva asumir una serie de Trade-offs que es necesario identificar previamente y comprender profundamente. Por ejemplo, en muchas ocasiones nos enfrentaremos a otro triángulo de requerimientos no-funcionales que siempre están en tensión, como son Coste, Resiliencia y Performance, sobre los que también hay que encontrar el balance más adecuado en función de cada caso de uso, entendiendo que apostar más en beneficio de uno, supondrá seguramente asumir una pérdida en los otros.
El cuarto principio, argumenta que los datos relativos a FinOps deben ser accesibles y oportunos en tiempo. De esta manera, podremos tener un mayor control sobre el uso de la nube, así como realizar una adecuada previsión y planificación financiera en tiempo real. Y es que tener sistemas no monitorizados conduce a la proliferación de costes desconocidos. Por tanto, el seguimiento con respecto al uso, el gasto, las excepciones, etc. son de vital importancia para llevar una adecuada gestión de costes, dándonos visión de en qué parte se nos está yendo de manera inapropiada el dinero o, por contra, en qué parte puede ser que nos interese invertir más (por aquello que mencionaba de las dimensiones de los beneficios de nuestro negocio...). En consecuencia, tengamos siempre presente que la inversión en observabilidad habitualmente nos va a compensar con creces, a pesar del gasto que suponga. Además de los diferentes stacks de observabilidad existentes y reconocidos, tanto independientes como del proveedor Cloud de turno, también es muy recomendable utilizar las herramientas de gestión de costes que estos últimos proporcionan y que nos permitirán llevar a cabo un análisis y control muy detallado sobre nuestros patrones de gasto en la nube, pudiendo establecer también límites de presupuesto, alertas al respecto, etc.
Acercándonos ya al final, nos encontramos con el quinto principio, que indica que la práctica de FinOps debe ser liderada por un equipo centralizado, formado por perfiles de Tecnología, Finanzas, Negocio y Management. Este equipo, será el que marque el camino a seguir a la hora de implantar todo este cambio cultural en la empresa, centralizando todo lo relacionado con la gestión y gobierno sobre las tarifas, así como sobre los cuantiosos descuentos que se pueden llegar a obtener por commitment, por la anticipación de instancias reservadas o por volumen, liberando de esta labor a los equipos técnicos para que estos se puedan centrar en la optimización del uso de los recursos de la nube.
Y por último, nos encontramos con el sexto principio, que expone que hay que aprovechar el modelo de coste variable de la nube. Es decir, tenemos que tratar de verlo como una oportunidad, no como un riesgo, ya que en realidad nos permite llevar a cabo una planificación iterativa ágil sobre nuestros costes, pudiendo realizar ajustes continuos, en contraposición con los planes estáticos a largo plazo, tan propensos a sufrir de las más que conocidas desviaciones.
Dentro de este apartado, cabe destacar la importancia de establecer diferentes políticas de gobierno de la nube como son el apagado de recursos fuera del horario de oficina, o el borrado de aquellos que ya no se necesiten (mucho cuidado con la PoC de turno cuyos recursos puedan quedar olvidados, una vez terminada ésta, continuando incurriendo en costes hasta que nos demos cuenta). Adicionalmente, entender bien el uso que hacemos de la nube, facilitará que podamos identificar escenarios donde poder utilizar instancias spot, basadas en aprovechar los excedentes de capacidad de computo de los proveedores Cloud, permitiéndonos disfrutar de descuentos muy interesantes para casos de uso como la ejecución de tareas por lotes (procesos batch), así como todo tipo de cargas de trabajo que puedan admitir interrupciones.
Y concluiré con dos aspectos que también hay que tener muy presentes a la hora de implantar FinOps con éxito. El primero es que se trata de un proceso complejo, cuya implantación debe hacerse poco a poco y de menos a más, pasando de manera incremental por las diferentes etapas de madurez que define el framework (Gatear, Caminar y Correr - Crawl, Walk and Run). El segundo es que debemos cuestionarnos y analizar vías de optimización constantemente, evitando caer en la trampa de confiarnos, con la excusa de que las cosas hayan ido siempre bien hasta ahora.