¿Qué sucede cuando FinOps encuentra una mala arquitectura de nube?

Las prácticas y herramientas de FinOps pueden detectar ineficiencias y oportunidades de optimización. Esto es lo que debe hacer cuando encuentre desperdicio en las implementaciones en la nube.

computación
Créditos: Rawpixel Ltd.

Cloud FinOps, una práctica que combina la gestión financiera y las operaciones en la nube, es fundamental para optimizar los costes de la nube y garantizar la utilización eficiente de los recursos. Es una de las tendencias emergentes más importantes en la computación en la nube.

Sus beneficios van más allá del control de costes. Exploremos cómo los FinOps en cloud también pueden ayudar a resaltar las malas prácticas de arquitectura de la nube que conducen a malas implementaciones. Al analizar los datos y patrones de costes de la nube, los equipos de FinOps pueden identificar áreas de preocupación y lo que debe solucionarse. ¿Podremos aprovechar esto para el bien de las implementaciones en la nube? Tenemos algunas cosas que considerar.

 

Análisis y optimización de costes

Los equipos de Cloud FinOps tienen acceso a datos detallados de costes de la nube. Esto les permite analizar patrones de gasto e identificar prácticas deficientes de arquitectura de nube que contribuyen a una suboptimización innecesaria y a un desperdicio de dinero.

Los errores incluyen el aprovisionamiento excesivo de recursos, la falta de automatización, la contenedorización ineficiente o el uso inadecuado de instancias reservadas. En muchos casos, se tomaron malas decisiones en el pasado y llevará muchos años corregirlas; de hecho, es posible que ya hayan causado un daño irreparable a la empresa.

Los sistemas de observabilidad de FinOps pueden analizar datos de costes e identificar recursos o servicios específicos que aumentan los costes. Esto generalmente conduce a posibles mejoras arquitectónicas e importantes ahorros de costes.

 

Evaluación de rendimiento y escalabilidad

Los equipos de Cloud FinOps pueden evaluar el rendimiento y la escalabilidad de la infraestructura de la nube. La supervisión de indicadores clave de rendimiento, como los tiempos de respuesta, la latencia y el rendimiento, puede identificar cuellos de botella o áreas donde la arquitectura actual limita la escalabilidad y el rendimiento.

Dado que FinOps normalmente rastrea esto a través del dinero gastado, es fácil determinar exactamente cuánto le están costando a la empresa los errores de arquitectura. No es inusual encontrar que un sistema implementado en la nube cueste 10 veces más dinero al mes de lo que debería. Esas cifras son discordantes para la mayoría de las empresas. Recuerde, todo ese dinero podría haberse gastado en otras áreas, como en innovaciones.

Algunos sistemas FinOps pueden calcular las pérdidas netas de estos errores arquitectónicos. En muchos casos, incluso se puede ver la reducción neta del valor empresarial.

Un ejemplo: utilizar un solo proveedor de nube pública sin considerar otros que puedan tener mejores soluciones, como una base de datos que puede funcionar cinco veces más rápido, proporcionando mejor rendimiento y ahorro para las aproximadamente 50 aplicaciones que la utilizan. Una mejor base de datos habría supuesto un tercio del coste, habría proporcionado cinco veces más rendimiento y habría ahorrado 15 millones de dólares al año en ganancias de productividad. Aún peor. Esos 15 millones de dólares podrían haberse utilizado para desarrollar una nueva línea de productos, que la empresa podría haber convertido en 100 millones de dólares en ingresos. Esto puede parecer un ejemplo extremo, pero he visto cosas como esta salir a la luz después de algunos análisis de la arquitectura de la nube, oportunidades perdidas, ineficiencias, etc. Es más común de lo que muchos creen.

 

Control de daños

Bien, ahora la pregunta con la que la mayoría de los profesionales de la nube no quieren lidiar: ¿qué pasa si su arquitectura de nube tiene algunas ineficiencias importantes?

Sospecho que la mayoría de las implementaciones en la nube tienen cierto grado de ineficiencia, por lo que no está solo. Es bueno aceptar los daños para poder asignar dinero para solucionar los problemas. Sugiero dividir cada problema en dominios que puedan abordarse por separado y manejarlos en orden de prioridad, del más costoso al menos. Necesitarás librar muchas batallas para ganar la guerra.

La mayoría de estos serán cosas como bases de datos mal diseñadas, tecnología incorrecta, implementación deficiente de la nube y planificación de operaciones en la nube: cosas que son de naturaleza táctica y, aunque no son fáciles de solucionar, es fácil entender cómo solucionarlo.

Sin embargo, hay más errores estratégicos, como utilizar un único proveedor de nube. Quizás en ese momento pareció una buena idea. Quizás un proveedor tenía una relación con varios miembros de la junta directiva o había razones políticas para las opciones limitadas. Desgraciadamente, la empresa todavía acaba con una gran deuda técnica que podría haberse evitado.

Tenga en cuenta que FinOps no es perfecto. Es bueno encontrar áreas para mejores optimizaciones, pero los buenos arquitectos de la nube aún deben identificar el origen de esas malas prácticas de arquitectura. En otras palabras, FinOps es bueno para detectar problemas, pero aún no identifica los problemas ni cómo solucionarlos.



TE PUEDE INTERESAR...

CASOS DE ÉXITO

Accede a nuestra publicación de canal

DealerWorld Digital

Documentos ComputerWorld

Documento Pure Storage y Kyndryl INFRAESTRUCTURAS