Sin duda, se ha preguntado cuánto cuesta la infraestructura de su proyecto. Lo sorprendente es que el aumento de los costos no es lineal en relación con las cargas. Muchos propietarios de negocios, CTO y desarrolladores comprenden de manera implícita que están pagando de más. Pero, ¿por qué exactamente?
Normalmente, la reducción de costos se reduce simplemente a buscar la solución más barata, la tarifa de AWS o, si hablamos de racks físicos, la optimización de la configuración del hardware. Además, esto lo hace prácticamente cualquiera, según lo que le dicte la situación: si hablamos de una startup, probablemente sea el desarrollador principal, quien tiene suficientes preocupaciones. En empresas más grandes, esto lo maneja el CMO/CTO, y a veces se involucra personalmente el director general junto con el contador. En resumen, son personas que ya tienen suficientes preocupaciones 'profesionales'. Y resulta que las facturas de infraestructura aumentan, pero quienes se encargan de esto... son aquellos que no tienen tiempo para ocuparse de ello.
Si en la oficina se necesita comprar papel higiénico, esto será gestionado por el encargado o la persona responsable de la empresa de limpieza. Si se trata de desarrollo, son los lead y el CTO. En ventas también está bastante claro. Pero desde tiempos inmemoriales, cuando se llamaba 'servidor' a un armario en el que había un sistema torre normal con un poco más de memoria RAM y un par de discos duros en RAID, todos (o, al menos, muchos) ignoran el hecho de que las compras de capacidad también deben estar a cargo de una persona especialmente capacitada.
Lamentablemente, la memoria histórica y la experiencia indican que esta tarea ha sido delegada durante décadas a personas 'casuales': quien estaba más cerca, se encargó del asunto. Y solo recientemente en el mercado ha comenzado a formalizarse y tomar alguna forma la profesión de FinOps. Esa es la persona especialmente capacitada cuyo trabajo consiste en supervisar la compra y el uso de capacidades. Y, al final, en reducir los costos de la empresa en este ámbito.
No estamos promoviendo el rechazo de soluciones costosas y efectivas: cada negocio debe decidir por sí mismo lo que necesita para una existencia cómoda en términos de hardware y tarifas en la nube. Sin embargo, no se puede ignorar el hecho de que la compra impulsiva 'de la lista' sin un control posterior y un análisis de uso resulta, para muchas empresas, en pérdidas sustanciales debido a una gestión ineficaz de los 'activos' de su backend.
¿Quién es FinOps?
Supongamos que tiene una empresa sólida de la que los vendedores hablan con devoción como un 'enterprise'. Probablemente, 'de la lista', ha adquirido una docena o más de servidores, AWS y algunas otras cosas 'por detalle'. Lo cual tiene sentido: en una gran empresa siempre hay algún tipo de movimiento: algunos equipos crecen, otros se desintegran, y otros se trasladan a proyectos adyacentes. Y la combinación de estos movimientos junto con el mecanismo de compras 'de la lista' lleva a nuevos cabellos canosos al ver la siguiente factura mensual por la infraestructura.
¿Entonces, qué hacer: seguir esperando pacientemente, pintar de nuevo o averiguar las causas de la aparición de esos numerosos y horribles ceros en la factura?
Qué pecado ocultar: la aprobación, autorizaciones y el pago mismo de la solicitud dentro de la empresa para la misma tarifa de AWS no siempre es un proceso rápido (en realidad, casi nunca lo es). Y precisamente debido al constante movimiento corporativo, parte de estas adquisiciones puede 'perderse' en alguna parte. Y simplemente quedarse inactivas. Si un administrador atento nota un servidor sin dueño en su sala de servidores, en el caso de tarifas en la nube, la situación es mucho más triste. Pueden estar 'en espera' durante meses: pagados, pero al mismo tiempo ya no son necesarios para el departamento para el cual fueron adquiridos. Al mismo tiempo, colegas de la oficina de al lado comienzan a arrancarse no solo los cabellos que aún no han encanecido, sino también en otros lugares: llevan semanas sin que se les pague una tarifa de AWS similar que necesitan urgentemente.
¿Cuál es la solución más obvia? Correcto, pasar las riendas a los que lo necesiten, y todos quedan satisfechos. Sin embargo, las comunicaciones horizontales no siempre están bien establecidas. Y el segundo departamento puede simplemente no saber de la riqueza del primero, que resultó no ser tan necesario para ellos.
¿Quién tiene la culpa? — En realidad, nadie. Así es como están las cosas por ahora.
¿Quién se ve afectado por esto? — Todos, toda la empresa.
¿Quién puede resolver la situación? — Sí, FinOps.
FinOps no es solo un intermediario entre los desarrolladores y el hardware que necesitan, sino una persona o equipo que sabe dónde, qué y qué tan bien "está" en cuanto a las tarifas en la nube adquiridas por la empresa. De hecho, estas personas deben trabajar en conjunto con DevOps por un lado, y el departamento financiero por otro, desempeñando el papel de intermediario eficaz y, lo más importante, analista.
Un poco sobre la optimización
Nubes. Comparativamente baratas y muy convenientes. Pero esta solución deja de ser económica cuando la cantidad de servidores se vuelve de dos o tres cifras. Además, las nubes permiten utilizar cada vez más servicios que antes no estaban disponibles: bases de datos como servicio (Amazon AWS, Azure Database), aplicaciones serverless (AWS Lambda, Azure Functions) y muchos más. Todos son geniales porque son simples de usar: compras y listo, no hay problemas. Sin embargo, cuanto más se sumerge la empresa y sus proyectos en la nube, peor duerme el director financiero. Y el CEO se vuelve más canoso más rápido.
El problema es que las facturas por varios servicios en la nube siempre son muy confusas: puedes recibir una desglose de tres páginas para un solo artículo, explicando a qué, dónde y cómo se fueron tu dinero. Esto es, por supuesto, agradable, pero es prácticamente imposible entenderlo. Además, nuestra opinión al respecto no es la única: existen servicios enteros para traducir facturas en la nube a lenguaje humano, por ejemplo, o . Si alguien se tomó la molestia de crear un servicio separado para desglosar las facturas, la magnitud del problema ha superado el costo del tinte para el cabello.
Así que, ¿qué hace FinOps en esta situación?
- entender claramente cuándo y en qué cantidades se adquirieron las soluciones en la nube.
- saber cómo se utilizan esos recursos.
- redistribuirlos, según las necesidades de cada departamento.
- no comprar "para tener".
- y al final, ahorra su dinero.
Un excelente ejemplo es el almacenamiento en la nube de copias frías de bases de datos. Por ejemplo, ¿lo archivas para reducir el espacio y el tráfico consumido al actualizar el almacenamiento? Sí, parece una situación trivial en un caso específico, pero la suma de estas situaciones triviales se traduce en costos exorbitantes por los servicios en la nube.
O otra situación: tienes potencial adicional comprado en AWS o Azure para no colapsar bajo la carga máxima. ¿Puede uno estar seguro de que esta es la solución óptima? Si estos instancias están inactivas el 80% del tiempo, simplemente estás regalando dinero a Amazon. Además, para tales casos, tanto AWS como Azure tienen instancias escalables: ¿para qué usar servidores que no están en uso si puedes utilizar herramientas para abordar las cargas máximas? O en lugar de instancias locales, deberías considerar las instancias reservadas, que son mucho más económicas y además ofrecen descuentos.
Por cierto, sobre los descuentos
Como mencionamos al principio, a menudo cualquiera se encarga de las compras: se encuentra a alguien y luego se deja a esa persona que se las arregle sola. Más a menudo, los 'encargados' son personas que están ocupadas, y al final conseguimos una situación donde una persona decide rápidamente y de manera independiente qué y en qué cantidades comprar.
Sin embargo, al interactuar con un vendedor del servicio en la nube, se pueden obtener condiciones más favorables si se trata de la compra al por mayor de recursos. Está claro que no conseguirás tales descuentos mediante un proceso automático y unidireccional, pero hablando con un gerente de ventas real, es posible que consigas algo. O estos chicos pueden informar sobre las promociones disponibles. Eso también puede ser útil.
A la vez, hay que recordar que en AWS o Azure no todo se limita a ellos. Por supuesto, no se está hablando de organizar tu propio servidor, pero también hay alternativas a estas dos soluciones clásicas de los gigantes.
Por ejemplo, Google ofrece la plataforma Firebase para empresas, donde puedes alojar un proyecto móvil 'llave en mano' que puede requerir rápida escalabilidad. Almacenamiento, bases de datos en tiempo real, hosting y sincronización en la nube de datos están disponibles en un solo lugar con esta solución.
Por otro lado, si no estamos hablando de un proyecto monolítico, sino de su集合, una solución centralizada no siempre es beneficiosa. Si el proyecto tiene una larga duración, tiene su propia historia de desarrollo y la cantidad de datos necesarios que deben almacenarse, entonces vale la pena considerar un enfoque más fragmentado.
Al optimizar los gastos en servicios en la nube, puedes darte cuenta de repente de que para las aplicaciones críticas para el negocio, puedes optar por tarifas más potentes que asegurarán ingresos constantes a la empresa. Sin embargo, almacenar la 'herencia' de desarrollo, archivos antiguos, bases de datos y demás en costosas nubes no es la mejor solución. Para esos datos, un centro de datos estándar con discos duros HDD normales y hardware de potencia media sin 'complementos' es más que suficiente.
Aquí se podría pensar una vez más que 'toda esta molestia no vale la pena', pero el problema de esta publicación radica en que, en diversas etapas, las personas responsables ignoran los detalles y hacen lo que es más conveniente y rápido. Lo que, al final, resulta en esas aterradoras cuentas después de un par de años.
¿Cuál es el resultado?
En general, la nube es increíble, resuelve un montón de problemas para empresas de cualquier tamaño. Sin embargo, la novedad de este fenómeno lleva a que aún no tengamos una cultura de consumo y gestión. FinOps es un apalancamiento organizacional que ayuda a utilizar las capacidades en la nube de manera más efectiva. Lo principal es no convertir este puesto en un análogo de un pelotón de fusilamiento, cuyo objetivo sea atrapar a los desarrolladores distraídos y 'reprenderlos' por el tiempo de inactividad de los recursos.
Los desarrolladores deben desarrollar, no contar el dinero de la empresa. Y es aquí donde FinOps debe hacer que tanto el proceso de compra como el de eliminación o transferencia de recursos en la nube a otros equipos sea un evento simple y agradable para todas las partes.
Fuente: habr.com
