{"id":35224,"date":"2019-10-31T22:03:02","date_gmt":"2019-10-31T19:03:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit\/"},"modified":"2019-10-31T22:03:02","modified_gmt":"2019-10-31T19:03:02","slug":"skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit","title":{"rendered":"\u00bfCu\u00e1nto gastas en infraestructura? \u00bfY c\u00f3mo puedes ahorrar en esto?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00bfCu\u00e1nto
\n
\nSin duda, se ha preguntado cu\u00e1nto cuesta la infraestructura de su proyecto. Lo sorprendente es que el aumento de los costos no es lineal en relaci\u00f3n con las cargas. Muchos propietarios de negocios, CTO y desarrolladores comprenden de manera impl\u00edcita que est\u00e1n pagando de m\u00e1s. Pero, \u00bfpor qu\u00e9 exactamente?<\/p>\n

Normalmente, la reducci\u00f3n de costos se reduce simplemente a buscar la soluci\u00f3n m\u00e1s barata, la tarifa de AWS o, si hablamos de racks f\u00edsicos, la optimizaci\u00f3n de la configuraci\u00f3n del hardware. Adem\u00e1s, esto lo hace pr\u00e1cticamente cualquiera, seg\u00fan lo que le dicte la situaci\u00f3n: si hablamos de una startup, probablemente sea el desarrollador principal, quien tiene suficientes preocupaciones. En empresas m\u00e1s 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.
\n<\/a><\/noindex>
\nSi en la oficina se necesita comprar papel higi\u00e9nico, esto ser\u00e1 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\u00e9n est\u00e1 bastante claro. Pero desde tiempos inmemoriales, cuando se llamaba 'servidor' a un armario en el que hab\u00eda un sistema torre normal con un poco m\u00e1s 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\u00e9n deben estar a cargo de una persona especialmente capacitada. <\/p>\n

Lamentablemente, la memoria hist\u00f3rica y la experiencia indican que esta tarea ha sido delegada durante d\u00e9cadas a personas 'casuales': quien estaba m\u00e1s cerca, se encarg\u00f3 del asunto. Y solo recientemente en el mercado ha comenzado a formalizarse y tomar alguna forma la profesi\u00f3n 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 \u00e1mbito.<\/p>\n

No estamos promoviendo el rechazo de soluciones costosas y efectivas: cada negocio debe decidir por s\u00ed mismo lo que necesita para una existencia c\u00f3moda en t\u00e9rminos 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\u00e1lisis de uso resulta, para muchas empresas, en p\u00e9rdidas sustanciales debido a una gesti\u00f3n ineficaz de los 'activos' de su backend.<\/p>\n

\u00bfQui\u00e9n es FinOps?<\/h4>\n

\nSupongamos que tiene una empresa s\u00f3lida de la que los vendedores hablan con devoci\u00f3n como un 'enterprise'. Probablemente, 'de la lista', ha adquirido una docena o m\u00e1s de servidores, AWS y algunas otras cosas 'por detalle'. Lo cual tiene sentido: en una gran empresa siempre hay alg\u00fan tipo de movimiento: algunos equipos crecen, otros se desintegran, y otros se trasladan a proyectos adyacentes. Y la combinaci\u00f3n 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. <\/p>\n

\u00bfEntonces, qu\u00e9 hacer: seguir esperando pacientemente, pintar de nuevo o averiguar las causas de la aparici\u00f3n de esos numerosos y horribles ceros en la factura? <\/p>\n

Qu\u00e9 pecado ocultar: la aprobaci\u00f3n, autorizaciones y el pago mismo de la solicitud dentro de la empresa para la misma tarifa de AWS no siempre es un proceso r\u00e1pido (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\u00f1o en su sala de servidores, en el caso de tarifas en la nube, la situaci\u00f3n es mucho m\u00e1s 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\u00fan no han encanecido, sino tambi\u00e9n en otros lugares: llevan semanas sin que se les pague una tarifa de AWS similar que necesitan urgentemente.<\/p>\n

\u00bfCu\u00e1l es la soluci\u00f3n m\u00e1s obvia? Correcto, pasar las riendas a los que lo necesiten, y todos quedan satisfechos. Sin embargo, las comunicaciones horizontales no siempre est\u00e1n bien establecidas. Y el segundo departamento puede simplemente no saber de la riqueza del primero, que result\u00f3 no ser tan necesario para ellos.<\/p>\n

\u00bfQui\u00e9n tiene la culpa? \u2014 En realidad, nadie. As\u00ed es como est\u00e1n las cosas por ahora.
\n\u00bfQui\u00e9n se ve afectado por esto? \u2014 Todos, toda la empresa.
\n\u00bfQui\u00e9n puede resolver la situaci\u00f3n? \u2014 S\u00ed, FinOps.<\/p>\n

FinOps no es solo un intermediario entre los desarrolladores y el hardware que necesitan, sino una persona o equipo que sabe d\u00f3nde, qu\u00e9 y qu\u00e9 tan bien \"est\u00e1\" 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\u00f1ando el papel de intermediario eficaz y, lo m\u00e1s importante, analista.<\/p>\n

Un poco sobre la optimizaci\u00f3n<\/h4>\n

\nNubes. Comparativamente baratas y muy convenientes. Pero esta soluci\u00f3n deja de ser econ\u00f3mica cuando la cantidad de servidores se vuelve de dos o tres cifras. Adem\u00e1s, las nubes permiten utilizar cada vez m\u00e1s servicios que antes no estaban disponibles: bases de datos como servicio (Amazon AWS, Azure Database), aplicaciones serverless (AWS Lambda, Azure Functions) y muchos m\u00e1s. Todos son geniales porque son simples de usar: compras y listo, no hay problemas. Sin embargo, cuanto m\u00e1s se sumerge la empresa y sus proyectos en la nube, peor duerme el director financiero. Y el CEO se vuelve m\u00e1s canoso m\u00e1s r\u00e1pido.<\/p>\n

El problema es que las facturas por varios servicios en la nube siempre son muy confusas: puedes recibir una desglose de tres p\u00e1ginas para un solo art\u00edculo, explicando a qu\u00e9, d\u00f3nde y c\u00f3mo se fueron tu dinero. Esto es, por supuesto, agradable, pero es pr\u00e1cticamente imposible entenderlo. Adem\u00e1s, nuestra opini\u00f3n al respecto no es la \u00fanica: existen servicios enteros para traducir facturas en la nube a lenguaje humano, por ejemplo, www.cloudyn.com<\/a><\/noindex> o www.cloudability.com<\/a><\/noindex>. Si alguien se tom\u00f3 la molestia de crear un servicio separado para desglosar las facturas, la magnitud del problema ha superado el costo del tinte para el cabello.<\/p>\n

As\u00ed que, \u00bfqu\u00e9 hace FinOps en esta situaci\u00f3n?<\/p>\n