O Buzz está construindo em torno da ideia de que é hora de recuperar nossos serviços em nuvem e reconstruir mais uma vez o data center da empresa. Repatriamento. É o ato de transferir o trabalho da nuvem e de volta para hardware local ou autogerenciado. E a principal justificação para este movimento é simples, especialmente num período de recessão económica. Economize dinheiro não usando AWS, Azure ou outros serviços de hospedagem em nuvem. Economize dinheiro construindo e gerenciando sua própria infraestrutura.
Desde que um post de Andreesen Horowitz catapultou esta ideia para os holofotes há alguns anos, ela parece estar ganhando força. A 37Signals, criadora do Basecamp e do Hey (um serviço de webmail pago), escreve regularmente em blogs sobre como eles repatriaram. E um relatório recente sugeriu que, de todos aqueles que falaram sobre voltar à auto-hospedagem, o principal motivo foi financeiro: 45% disseram que é por causa do custo.
Não deveria ser surpresa que a repatriação tenha ganhado tanto entusiasmo. A nuvem, que atingiu a maturidade durante um boom económico, está pela primeira vez sob pressão descendente, à medida que as empresas procuram reduzir os gastos. Amazon, Google, Microsoft e outros provedores de nuvem festejaram com a disposição de seus clientes em gastar. Mas a vontade foi agora atenuada por cortes orçamentais.
Qual é a resposta mais óbvia à sensação de que a nuvem ficou muito cara? É o toque de clarim da repatriação: mova tudo de volta para dentro de casa!
Kubernetes é caro na prática
A nuvem acabou sendo cara. O culpado pode ser as tecnologias que construímos para usar melhor a nuvem. Embora possamos analisar uma infinidade de serviços complementares, o problema surge no nível mais básico. Vamos nos concentrar apenas na computação em nuvem.
A proposta de valor original das máquinas virtuais hospedadas (a computação em nuvem OG) era que você poderia pegar todo o seu sistema operacional, empacotá-lo e enviá-lo para outro lugar para execução. Mas a parte operacional dessa configuração – aquilo com que pedimos que nossas equipes de desenvolvimento e engenharia de plataforma lidassem – não foi nada agradável. A manutenção era uma fera. As ferramentas de gerenciamento eram primitivas. Os desenvolvedores não participaram. As implantações foram mais lentas que o melaço.
Junto vieram os contêineres Docker. Quando se tratava de empacotar e implantar serviços individuais, os contêineres nos deram uma história melhor do que as VMs. Os desenvolvedores poderiam facilmente construí-los. Os tempos de inicialização foram medidos em segundos, não em minutos. E graças a um pequeno projeto do Google chamado Kubernetes, foi possível orquestrar o gerenciamento de aplicativos contêineres.
Mas o que não percebíamos enquanto construíamos este admirável mundo novo é o custo que incorríamos. Mais especificamente, em nome da estabilidade, subestimamos os custos. No Kubernetes, a forma preferida de implantar um aplicativo executa pelo menos três réplicas de cada aplicativo em execução, mesmo quando a carga de entrada não justifica isso. 24 horas por dia, 7 dias por semana, todos os servidores do seu cluster estão funcionando em triplicado (pelo menos), consumindo energia e recursos.
Além disso, colocamos em camadas uma grande quantidade de sidecars e serviços auxiliares, que consumiam mais recursos. De repente, aquele cluster Kubernetes “inicial” de três nós tinha sete nós. Depois uma dúzia. De acordo com uma pesquisa recente da CNCF, 50% dos clusters Kubernetes têm mais de 50 nós. O custo do cluster disparou. E então todos nós nos encontramos naquela posição ignóbil de instalar ferramentas de “controle de custos” para tentar nos dizer onde poderíamos encaixar nosso cluster Kubernetes em nosso novo orçamento de jeans skinny.
Discutindo isso recentemente com um amigo, ele admitiu que, neste ponto, o cluster Kubernetes de sua empresa estava preparado para uma grande aposta: em vez de provisionar quantos recursos precisavam, eles provisionaram de forma insuficiente, na esperança de que não muitas coisas falhassem ao mesmo tempo. . Eles reduziram o tamanho do cluster até que os requisitos de inicialização de todos os seus servidores, se acionados mutuamente, esgotassem os recursos de todo o cluster antes que pudessem ser reiniciados. Num padrão mais amplo, estamos agora a negociar estabilidade e tranquilidade por uma pequena redução percentual nos nossos custos.
Não é de admirar que a repatriação esteja a causar espanto.
Podemos resolver o problema na nuvem?
Mas e se fizéssemos uma pergunta diferente? E se perguntássemos se havia uma mudança arquitetônica que poderíamos fazer que reduziria enormemente os recursos que consumimos? E se pudéssemos reduzir o cluster Kubernetes de volta ao tamanho de um dígito, não apertando os cintos e esperando que nada quebre, mas construindo serviços de uma forma que seja mais sustentável em termos de custos?
A tecnologia e o padrão de programação já estão aqui. E aqui está o spoiler: a solução é WebAssembly sem servidor.
Vamos considerar esses termos um de cada vez.
As funções sem servidor são um padrão de desenvolvimento que ganhou grande impulso. AWS, o maior provedor de nuvem, afirma executar 10 trilhões de funções sem servidor por mês. Esse nível de vastidão é incompreensível. Mas é um indicador promissor de que os desenvolvedores apreciam essa modalidade e estão construindo coisas que são populares.
A melhor maneira de pensar em uma função sem servidor é como um manipulador de eventos. Um evento específico (uma solicitação HTTP e um item chegando a uma fila, etc.) aciona uma função específica. Essa função é iniciada, processa a solicitação e é encerrada imediatamente. Uma função pode ser executada por milissegundos, segundos ou talvez minutos, mas não mais.
Então, qual é o “servidor” que dispensamos no serverless? Não estamos afirmando que estamos de alguma forma além do hardware do servidor. Em vez disso, “sem servidor” é uma declaração sobre o padrão de design de software. Não há processo de servidor de longa duração. Em vez disso, escrevemos apenas uma função – apenas um manipulador de eventos. E deixamos para o sistema de eventos acionar a invocação do manipulador de eventos.
E o que sai dessa definição é que funções sem servidor são muito mais fáceis de escrever do que serviços – até mesmo microsserviços tradicionais. O simples fato de que as funções sem servidor exigem menos código, o que significa menos desenvolvimento, depuração e aplicação de patches. Isso por si só pode levar a alguns grandes resultados. Como David Anderson relatou em seu livro The Value Flywheel Effect: “Um único aplicativo web na Liberty Mutual foi reescrito como sem servidor e resultou em custos de manutenção reduzidos de 99,89%, de US$ 50.000 por ano para US$ 10 por ano.” (Anderson, Davi. O efeito volante de valor, pág. 27.)
Outro resultado natural de ficar sem servidor é que executamos pedaços menores de código por períodos de tempo mais curtos. Se o custo da computação em nuvem for determinado pela combinação de quantos recursos do sistema (CPU, memória) precisamos e quanto tempo precisamos para acessar esses recursos, então deve ficar claro imediatamente que a tecnologia sem servidor deve ser mais barata. Afinal, ele usa menos e funciona por milissegundos, segundos ou minutos, em vez de dias, semanas ou meses.
As arquiteturas sem servidor mais antigas de primeira geração reduziram um pouco os custos, mas como por baixo do capô havia tempos de execução realmente volumosos, o custo de uma função sem servidor cresceu substancialmente ao longo do tempo, à medida que uma função lidava com mais e mais solicitações.
É aqui que entra o WebAssembly.
WebAssembly como um melhor tempo de execução sem servidor
Como um tempo de execução isolado altamente seguro, o WebAssembly é uma excelente estratégia de virtualização para funções sem servidor. Uma função WebAssembly leva menos de um milissegundo para iniciar a frio e requer pouca CPU e memória para ser executada. Por outras palavras, reduzem tempo e recursos do sistema, o que significa que poupam dinheiro.
Quanto eles cortam? O custo variará dependendo da nuvem e do número de solicitações. Mas podemos comparar um cluster Kubernetes usando apenas contêineres com outro que usa WebAssembly. Um nó Kubernetes pode executar um máximo teórico de pouco mais de 250 pods. Na maioria das vezes, uma máquina virtual de tamanho moderado atinge os limites de memória e poder de processamento em apenas algumas dezenas de contêineres. E isso ocorre porque os contêineres consomem recursos durante toda a sua atividade.
Na Fermyon, conseguimos executar rotineiramente milhares de aplicativos WebAssembly sem servidor, mesmo em nós de tamanho modesto em um cluster Kubernetes. Recentemente, carregamos 5.000 aplicativos sem servidor testados em um cluster de dois nós de trabalho, alcançando mais de 1,5 milhão de invocações de função em 10 segundos. Fermyon Cloud, nosso sistema de produção público, executa 3.000 aplicativos desenvolvidos pelo usuário em cada máquina virtual de 8 núcleos e 32 GiB. E esse sistema está em produção há mais de 18 meses.
Resumindo, alcançamos eficiência por meio de densidade e velocidade. E a eficiência se traduz diretamente em economia de custos.
Mais seguro que a repatriação
A repatriação é um caminho para a redução de custos. Outra é mudar os padrões de desenvolvimento de serviços de longa execução para funções sem servidor baseadas em WebAssembly. Embora não sejam, em última análise, mutuamente exclusivos, um dos dois é de alto risco.
Mudar da nuvem para o local é um caminho que mudará seus negócios, e possivelmente não para melhor.
A repatriação se baseia na ideia de que a melhor coisa que podemos fazer para controlar os gastos com nuvem é mover todas essas coisas – todos aqueles clusters, proxies e balanceadores de carga do Kubernetes – de volta para um espaço físico que controlamos. Claro, nem é preciso dizer que isso envolve a compra de espaço, hardware, largura de banda e assim por diante. E envolve transformar a equipe de operações de uma mentalidade de software e serviços para uma mentalidade de gerenciamento de hardware. Como alguém que se lembra (não com carinho) de colocar servidores em rack, solucionar problemas de hardware quebrado e ver a meia-noite ir e vir enquanto eu fazia isso, a ideia de repatriar inspira tudo, menos uma sensação de antecipação edificante.
A transição de volta para o local é uma tarefa pesada e difícil de rescindir caso as coisas dêem errado. E as poupanças ainda não serão vistas até que a transição esteja concluída (na verdade, com as despesas de capital envolvidas na mudança, pode demorar muito tempo até que as poupanças sejam realizadas).
Mudar para funções sem servidor baseadas em WebAssembly, por outro lado, é mais barato e menos arriscado. Como essas funções podem ser executadas dentro do Kubernetes, a tese da economia pode ser testada simplesmente separando alguns serviços representativos, reescrevendo-os e analisando os resultados.
Aqueles que já investiram em uma arquitetura estilo microsserviço já estão bem configurados para reconstruir apenas fragmentos de um aplicativo multisserviço. Da mesma forma, aqueles que investem em cadeias de processamento de eventos, como pipelines de transformação de dados, também acharão fácil identificar uma ou duas etapas em uma sequência que pode se tornar o ambiente de teste para experimentação.
Isso não é apenas uma barreira menor à entrada, mas, quer funcione ou não, sempre há a opção de selecionar a repatriação sem ter que realizar uma segunda reviravolta, já que as funções sem servidor do WebAssembly funcionam tão bem no local (ou no limite). , ou em outro lugar) como fazem na nuvem.
Economia de custos a que custo?
Já é hora de aprendermos a controlar nossas despesas com nuvem. Mas há formas muito menos drásticas (e arriscadas) de fazer isto do que a repatriação. Seria prudente explorar primeiro as soluções mais baratas e fáceis, antes de entrar no movimento… e depois carregá-lo com racks de servidores. E a boa notícia é que, se eu estiver errado, será fácil repatriar essas funções WebAssembly de código aberto e sem servidor. Afinal, eles são mais leves, mais rápidos, mais baratos e mais eficientes do que o status quo de ontem.
Uma maneira fácil de começar a usar o WebAssembly nativo da nuvem é experimentar a estrutura Spin de código aberto. E se o Kubernetes for seu ambiente de implantação de destino, um ambiente WebAssembly sem servidor em cluster pode ser instalado e gerenciado pelo SpinKube de código aberto. Em apenas alguns minutos, você poderá ter uma ideia se a solução para suas necessidades de controle de custos não será a repatriação, mas a construção de aplicativos mais eficientes que aproveitem melhor os recursos da nuvem.
Matt Butcher é cofundador e CEO da Fermyon, a empresa WebAssembly sem servidor na nuvem. Ele é um dos criadores originais de Helm, Brigade, CNAB, OAM, Glide e Krustlet. Ele escreveu e co-escreveu muitos livros, incluindo “Learning Helm” e “Go in Practice”. Ele é co-criador da série “Guia ilustrado para crianças sobre Kubernetes”. Atualmente, ele trabalha principalmente em projetos WebAssembly como Spin, Fermyon Cloud e Bartholomew. Ele possui um Ph.D. em filosofia. Ele mora no Colorado, onde bebe muito café.
–
O New Tech Forum oferece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Envie todos consultas para [email protected].
