{"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\/pt\/blog\/administrirovanie\/skolko-vy-tratite-na-infrastrukturu-i-kak-na-etom-sekonomit","title":{"rendered":"Quanto voc\u00ea gasta em infraestrutura? E como voc\u00ea pode economizar isso?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Quanto
\n
\nCertamente, voc\u00ea j\u00e1 se perguntou quanto custa a infraestrutura do seu projeto. \u00c9 surpreendente: o aumento das despesas n\u00e3o \u00e9 linear em rela\u00e7\u00e3o \u00e0s cargas. Muitos propriet\u00e1rios de neg\u00f3cios, CTOs e desenvolvedores, de forma inconsciente, percebem que est\u00e3o pagando demais. Mas pelo qu\u00ea exatamente?<\/p>\n

Normalmente, a redu\u00e7\u00e3o de custos se resume a encontrar a solu\u00e7\u00e3o mais barata, a tarifa da AWS ou, se falamos sobre racks f\u00edsicos, a otimiza\u00e7\u00e3o da configura\u00e7\u00e3o do hardware. Al\u00e9m disso, na pr\u00e1tica, isso \u00e9 tratado por qualquer um, como a sorte permitir: se estamos falando de uma startup, provavelmente \u00e9 o desenvolvedor l\u00edder, que j\u00e1 est\u00e1 lidando com muitas responsabilidades. Em empresas maiores, isso \u00e9 tratado pelo CMO\/CTO, e, \u00e0s vezes, at\u00e9 o diretor-geral se envolve pessoalmente com o chefe de contabilidade. No geral, essas s\u00e3o as mesmas pessoas que j\u00e1 t\u00eam muitas preocupa\u00e7\u00f5es \"especializadas\". Assim, as contas de infraestrutura aumentam, mas quem realmente lida com isso... s\u00e3o aqueles que n\u00e3o t\u00eam tempo para se aprofundar na quest\u00e3o.
\n<\/a><\/noindex>
\nSe for preciso comprar papel higi\u00eanico para o escrit\u00f3rio, isso \u00e9 responsabilidade do respons\u00e1vel pela manuten\u00e7\u00e3o ou da pessoa encarregada da empresa de limpeza. Se falamos de desenvolvimento \u2014 s\u00e3o os leads e o CTO. Vendas \u2014 tamb\u00e9m \u00e9 tudo claro. Mas desde os tempos antigos, quando cham\u00e1vamos de \"servidor\" o arm\u00e1rio que abrigava um sistema torre comum com um pouco mais de mem\u00f3ria RAM e alguns discos em RAID, todos (ou, pelo menos, muitos) ignoram o fato de que as compras de recursos deveriam ser gerenciadas por algu\u00e9m especificamente treinado para isso. <\/p>\n

Infelizmente, a mem\u00f3ria hist\u00f3rica e a experi\u00eancia indicam que essa tarefa foi delegada por d\u00e9cadas a pessoas \"casuais\": quem estivesse mais pr\u00f3ximo, era quem assumia a responsabilidade. E apenas recentemente, o mercado come\u00e7ou a formar e reconhecer a profiss\u00e3o de FinOps. Essa \u00e9 a pessoa especificamente treinada cuja fun\u00e7\u00e3o \u00e9 controlar a compra e o uso de recursos. E, em \u00faltima an\u00e1lise, reduzir os custos da empresa nesse sentido.<\/p>\n

N\u00f3s n\u00e3o recomendamos abrir m\u00e3o de solu\u00e7\u00f5es caras e eficazes: cada neg\u00f3cio deve decidir por si mesmo o que precisa para uma exist\u00eancia confort\u00e1vel em termos de hardware e tarifas de nuvem. No entanto, n\u00e3o podemos ignorar o fato de que a compra imprudente \"por lista\" sem controle e an\u00e1lise posterior de uso resulta em perdas significativas para muitas empresas devido \u00e0 gest\u00e3o ineficaz dos \"ativos\" de seu back-end.<\/p>\n

Quem \u00e9 FinOps<\/h4>\n

\nSuponhamos que voc\u00ea tenha uma empresa s\u00f3lida, da qual os vendedores falam com admira\u00e7\u00e3o como \"enterprise\". Provavelmente, voc\u00ea comprou uma d\u00fazia ou mais de servidores, AWS e outras coisas \"menores\" de forma \"por lista\". O que faz sentido: em uma grande empresa, sempre h\u00e1 algum movimento acontecendo \u2014 algumas equipes crescem, outras se desfazem, e outras s\u00e3o transferidas para projetos vizinhos. E assim, a combina\u00e7\u00e3o desses movimentos junto com o mecanismo de compras \"por lista\" acaba levando a alguns fios grisalhos ao revisar a fatura mensal da infraestrutura. <\/p>\n

Ent\u00e3o, o que fazer \u2014 continuar a ficar grisalho pacientemente, cobrir ou investigar as raz\u00f5es por tr\u00e1s desses numerosos zeros horr\u00edveis na fatura? <\/p>\n

O que pode ser oculto: a aprova\u00e7\u00e3o, consentimento e o pr\u00f3prio pagamento do pedido dentro da empresa para a mesma tarifa da AWS nem sempre (na verdade \u2014 quase nunca) \u00e9 r\u00e1pido. E justamente devido ao constante movimento corporativo, parte dessas aquisi\u00e7\u00f5es pode se \"perder\" em algum lugar. E simplesmente ficar paradas. Se um administrador atento notar um servidor abandonado em sua sala de servidores, no caso das tarifas de nuvem, a situa\u00e7\u00e3o \u00e9 muito pior. Eles podem ficar \"aninhados\" por meses \u2014 pagos, mas ao mesmo tempo j\u00e1 n\u00e3o necess\u00e1rios para o departamento ao qual foram adquiridos. Enquanto isso, colegas do escrit\u00f3rio ao lado come\u00e7am a arrancar seus cabelos ainda n\u00e3o grisalhos \u2014 eles n\u00e3o conseguem que uma tarifa AWS similar, urgentemente necess\u00e1ria, seja paga h\u00e1 semanas.<\/p>\n

Qual \u00e9 a solu\u00e7\u00e3o mais \u00f3bvia? Certo, passar as r\u00e9deas para quem precisa, e todos ficam satisfeitos. Mas as comunica\u00e7\u00f5es horizontais nem sempre est\u00e3o bem estruturadas. E o segundo departamento pode simplesmente n\u00e3o saber sobre a riqueza do primeiro, que, por sua vez, n\u00e3o parece precisar muito dessa riqueza.<\/p>\n

Quem \u00e9 o culpado? \u2014 Na verdade, ningu\u00e9m. Assim \u00e9 como tudo est\u00e1 organizado at\u00e9 agora.
\nQuem sofre com isso? \u2014 Todos, toda a empresa.
\nQuem pode corrigir a situa\u00e7\u00e3o? \u2014 Sim, FinOps.<\/p>\n

FinOps n\u00e3o \u00e9 apenas uma camada entre desenvolvedores e o equipamento de que precisam, mas uma pessoa ou uma equipe que sabe onde, o que e qu\u00e3o bem est\u00e3o dispostos em termos das tarifas de nuvem adquiridas pela empresa. De fato, essas pessoas devem trabalhar em conjunto com o DevOps de um lado e o departamento financeiro do outro, exercendo o papel de intermedi\u00e1rio eficaz e, o mais importante, analista.<\/p>\n

Um pouco sobre otimiza\u00e7\u00e3o<\/h4>\n

\nNuvens. Relativamente baratas e muito convenientes. Mas essa solu\u00e7\u00e3o deixa de ser econ\u00f4mica quando o n\u00famero de servidores se torna de dois ou tr\u00eas d\u00edgitos. Al\u00e9m disso, as nuvens oferecem a oportunidade de utilizar cada vez mais servi\u00e7os que antes estavam indispon\u00edveis: como bancos de dados como servi\u00e7o (Amazon AWS, Azure Database), aplica\u00e7\u00f5es serverless (AWS Lambda, Azure Functions) e muitos outros. Todos eles s\u00e3o incr\u00edveis por serem simples de usar \u2014 comprou e levou, sem problemas. S\u00f3 que quanto mais uma empresa e seus projetos se aprofundam nas nuvens, pior o diretor financeiro dorme. E mais r\u00e1pido o CEO fica grisalho.<\/p>\n

O fato \u00e9 que as faturas de v\u00e1rios servi\u00e7os em nuvem s\u00e3o sempre extremamente confusas: voc\u00ea pode receber uma descri\u00e7\u00e3o de tr\u00eas p\u00e1ginas sobre uma \u00fanica linha, explicando para onde, como e por que seu dinheiro foi gasto. Isso, claro, \u00e9 agrad\u00e1vel, mas \u00e9 praticamente imposs\u00edvel compreend\u00ea-las. E nossa opini\u00e3o sobre isso n\u00e3o \u00e9 a \u00fanica: para traduzir faturas de nuvem para um formato compreens\u00edvel, existem servi\u00e7os inteiros, como www.cloudyn.com<\/a><\/noindex> ou www.cloudability.com<\/a><\/noindex>. Se algu\u00e9m se preocupou em criar um servi\u00e7o separado para decifrar faturas, ent\u00e3o a escala do problema superou o custo da tinta para cabelo.<\/p>\n

Ent\u00e3o, o que o FinOps faz nessa situa\u00e7\u00e3o:<\/p>\n