Repatriação é uma forma de economizar custos. Uma outra alternativa é a transição de padrões de serviços de longa duração para funções sem servidor utilizando recursos de WebAssembly.
O Buzz está enfatizando a importância de proteger os serviços de nuvem e reestruturar o data center da empresa. A repatriação envolve transferir o trabalho da nuvem de volta para um local ou hardware autogerenciado. A principal razão para essa mudança é econômica, visando economizar recursos ao evitar o uso de serviços de hospedagem em nuvem como AWS, Azure, entre outros, e optar por construir e gerenciar a infraestrutura internamente.
Após um post de destaque de Andreesen Horowitz há alguns anos, a ideia de repatriação parece estar se popularizando. A empresa 37Signals, responsável pelo Basecamp e Hey, discute regularmente sobre esse tema em seu blog. Um estudo recente indicou que a principal razão para as pessoas considerarem a volta para a auto-hospedagem é financeira, sendo que 45% citaram o custo como motivo.
Não é surpreendente que a repatriação tenha se tornado tão popular. A indústria de nuvem, que prosperou durante um período de crescimento econômico, agora enfrenta pressão devido à busca das empresas por redução de custos. Provedores de serviços de nuvem como Amazon, Google e Microsoft estão agora mais conscientes dos gastos de seus clientes, devido aos cortes no orçamento.
Qual seria a solução mais clara para a percepção de que a nuvem está se tornando muito cara? É simplesmente pedir para trazer de volta o que foi enviado para a nuvem.
Usar Kubernetes pode ser dispendioso na vida real.
A utilização da nuvem se mostrou dispendiosa, talvez devido às tecnologias que desenvolvemos para otimizar seu uso. Apesar de explorarmos uma variedade de serviços extras, a questão fundamental reside na computação em nuvem. Vamos nos concentrar apenas nesse aspecto.
A ideia original das máquinas virtuais hospedadas, também conhecida como computação em nuvem OG, era permitir que os usuários levassem seus sistemas operacionais, os embalassem e os movessem para outro local para serem executados. No entanto, a parte operacional desse processo, que exigia a intervenção de equipes de devops e engenharia de plataforma, era bastante desafiadora. A manutenção era complicada, as ferramentas de gestão eram rudimentares, os desenvolvedores não estavam envolvidos e as implantações eram lentas.
Com a chegada dos contêineres Docker, houve uma melhoria significativa na embalagem e implantação de serviços individuais em comparação com as máquinas virtuais. Os desenvolvedores podem criá-los facilmente, com tempos de inicialização mais rápidos, medidos em segundos em vez de minutos. Graças ao Kubernetes, um projeto do Google, foi possível coordenar o gerenciamento de aplicativos em contêineres.
Porém, não estávamos cientes do custo que estávamos assumindo ao construir esse novo mundo corajoso. Em nome da estabilidade, reduzimos os custos. No Kubernetes, a prática comum é implantar pelo menos três réplicas de cada aplicação, mesmo quando a carga de entrada não justifica isso. Consequentemente, 24 horas por dia, sete dias por semana, cada servidor no cluster é executado em triplicado, consumindo energia e recursos.
Além disso, adicionamos vários componentes e serviços extras ao nosso guisado chunky, todos os quais consumiam mais recursos. De repente, o cluster de Kubernetes, inicialmente composto por três nós, aumentou para sete e depois para uma dúzia. Segundo uma pesquisa recente da CNCF, metade dos clusters de Kubernetes possui mais de 50 nós. Como resultado, o custo do cluster aumentou significativamente. Agora nos vemos na situação desagradável de ter que instalar ferramentas de “controle de custos” para tentar descobrir onde podemos economizar em nosso cluster Kubernetes e ajustá-lo ao nosso novo orçamento mais restrito.
Conversando com um amigo recentemente, ele confessou que, atualmente, o cluster de Kubernetes de sua empresa estava configurado de forma arriscada: Em vez de estimar corretamente os recursos necessários, decidiram correr o risco de não enfrentar muitas falhas simultâneas. Isso resultou em uma queda do cluster, pois a demanda de inicialização de todos os servidores excedeu a capacidade do cluster antes que pudessem ser reiniciados. Num cenário mais amplo, estamos agora trocando estabilidade e tranquilidade por uma pequena redução de custos.
Não é surpreendente que a repatriação esteja gerando questionamentos.
Podemos encontrar uma solução na computação em nuvem?
E se mudarmos a pergunta? E se questionarmos se existe uma alteração na arquitetura que poderia significativamente diminuir os recursos que estamos utilizando? E se conseguirmos reduzir o conjunto de Kubernetes para um tamanho mínimo sem precisar fazer sacrifícios, mas sim desenvolvendo serviços de forma mais eficiente?
A tecnologia e o modelo de codificação já estão disponíveis. E aqui está a dica: A resposta é a utilização de WebAssembly sem a necessidade de servidor.
Vamos analisar esses termos individualmente.
Funções sem servidor são uma tendência de programação em ascensão, com a AWS, o principal provedor de serviços em nuvem, relatando a execução de 10 trilhões de funções sem servidor por mês. Esse volume impressionante indica a crescente popularidade e apreciação dos desenvolvedores por essa abordagem, refletindo na criação de soluções populares.
Uma forma eficaz de compreender uma função sem servidor é considerá-la como um controlador de eventos. Cada evento específico, como uma solicitação HTTP ou a chegada de itens em uma fila, aciona uma função particular. Essa função é executada, processa a requisição e finaliza imediatamente. Embora a função possa durar milissegundos, segundos ou até minutos, não se prolonga além disso.
Portanto, o que significa “serverless” é que não estamos fazendo um servidor sem servidor. Não estamos afirmando que estamos além do hardware do servidor de forma radical. Em vez disso, “serverless” refere-se a um padrão de design de software no qual não há um processo contínuo do servidor. Em vez disso, escrevemos apenas uma função – um manipulador de eventos – e é o sistema de eventos que invoca o manipulador de eventos.
A definição sugere que as funções sem servidor são mais simples de serem criadas em comparação aos serviços, incluindo os microsserviços convencionais. Isso se deve ao fato de que as funções sem servidor demandam menos código, o que resulta em menos etapas de desenvolvimento, depuração e correções. Essa simplicidade pode gerar resultados significativos, como exemplificado por David Anderson em seu livro “O Efeito de Volante de Valor”, onde uma aplicação web na Liberty Mutual foi reescrita sem servidor, resultando em uma redução de custos de manutenção de quase 100%.
Outra consequência natural de não usar um servidor é que estamos executando partes menores de código por períodos mais breves. Se o custo da computação em nuvem é determinado pela quantidade de recursos do sistema (CPU, memória) necessários e pelo tempo necessário para acessá-los, então é evidente que o serverless deve ser mais econômico. Afinal, ele requer menos recursos e é executado em milissegundos, segundos ou minutos, ao invés de dias, semanas ou meses.
As primeiras arquiteturas serverless, embora tenham inicialmente diminuído os custos, acabaram se tornando mais caras com o passar do tempo devido ao aumento no volume de execuções das funções sem servidor. Isso ocorreu devido ao processamento pesado por trás das cenas, conforme as funções lidavam com um número cada vez maior de solicitações.
Aqui é onde o WebAssembly se torna relevante.
WebAssembly é considerado um tempo de execução sem servidor superior.
WebAssembly é uma excelente opção de virtualização para funções sem servidor devido à sua segurança e eficiência. As funções WebAssembly iniciam rapidamente e exigem poucos recursos de CPU e memória, resultando em economia de tempo e dinheiro no sistema.
Quanto é descontado? O valor varia de acordo com o tipo de nuvem e a quantidade de solicitações. No entanto, é possível comparar um conjunto de Kubernetes que usa apenas contêineres com um que utiliza WebAssembly. Um nó Kubernetes pode executar no máximo pouco mais de 250 contêineres teoricamente. Normalmente, uma máquina virtual de porte moderado alcança limites de energia, memória e processamento com apenas algumas dezenas de contêineres. Isso ocorre porque os contêineres consomem recursos ao longo de toda a sua atividade.
Na Fermyon, conseguimos regularmente rodar uma grande quantidade de aplicativos WebAssembly sem servidor em nós de tamanho moderado em um cluster Kubernetes. Recentemente, testamos a capacidade de 5.000 aplicativos sem servidor em um cluster com dois nós, resultando em mais de 1,5 milhões de chamadas de função em 10 segundos. Na Fermyon Cloud, que é nosso sistema de produção público, cada máquina virtual de 8 núcleos e 32GiB executa 3.000 aplicativos criados pelos usuários. Este sistema está em operação há mais de 18 meses.
Resumindo, alcançamos eficiência por meio da concentração e rapidez, e essa eficiência resulta em economia de despesas.
Mais confiável do que o processo de repatriação.
A repatriação pode gerar economia de custos, assim como a transição de serviços de longa duração para funções sem servidor através da tecnologia WebAssembly. Embora não sejam necessariamente opostos, um dos dois representa um alto risco.
Transferir os dados do armazenamento em nuvem para um ambiente local pode ter um impacto significativo no seu negócio, e talvez não seja uma mudança positiva.
A repatriação consiste em transferir todas as operações da nuvem de volta para um espaço físico sob nosso controle, o que implica em adquirir espaço, hardware e largura de banda. Também requer uma mudança de mentalidade da equipe de operações, passando de foco em software e serviços para gestão de hardware. Para aqueles que já lidaram com servidores físicos e problemas de hardware, repatriar pode ser visto com apreensão e nostalgia.
A mudança para o novo local é um processo complicado e difícil de reverter se algo der errado. Além disso, as economias esperadas só serão percebidas após a conclusão da transição, o que pode demorar devido aos gastos de capital envolvidos na mudança.
Trocar para funções sem servidor WebAssembly é mais econômico e menos arriscado. É possível testar a economia simplesmente ao modificar alguns serviços representativos para serem executados dentro de Kubernetes, reescrevê-los e analisar os resultados.
Quem já adotou uma arquitetura baseada em microserviços está preparado para reconstruir partes específicas de um aplicativo com vários serviços. Da mesma forma, quem já usa cadeias de processamento de eventos, como pipelines de transformação de dados, encontrará facilidade em identificar etapas isoladas que podem ser utilizadas para experimentação.
Além disso, não apenas representa um obstáculo menor para a entrada, mas, independentemente de funcionar ou não, existe sempre a possibilidade de escolher a repatriação sem a necessidade de realizar uma segunda configuração, já que as funções sem servidor WebAssembly operam tão eficientemente localmente (ou na borda, ou em outro local) quanto na nuvem.
Em que área se economiza dinheiro ao reduzir custos?
É importante aprender a gerenciar nossos gastos com serviços em nuvem de forma mais eficiente. Existem alternativas menos extremas e arriscadas do que repatriar os dados. Seria sensato primeiro considerar soluções mais econômicas e simples antes de tomar uma decisão precipitada e investir em servidores. Uma vantagem é que, caso algo dê errado, é fácil transferir essas funções de código aberto do WebAssembly sem servidor de volta. Essas opções são mais leves, rápidas, econômicas e eficientes do que as práticas tradicionais.
Uma forma simples de iniciar no WebAssembly nativo em nuvem é testar o projeto Spin, que é um framework de código aberto. Se você utiliza o Kubernetes como plataforma de implantação, é possível instalar e gerenciar um ambiente WebAssembly sem servidor com o SpinKube, também de código aberto. Em questão de minutos, é possível avaliar se a solução para otimização de custos está em repensar a forma como suas aplicações utilizam os recursos de nuvem, em vez de trazê-las de volta ao ambiente local.
Matt Butcher é um dos fundadores da Fermyon, uma empresa de nuvem que se dedica ao WebAssembly sem servidor. Ele é responsável por várias criações, como Helm, Brigade, CNAB, OAM, Glide e Krustlet. Além disso, é autor e coautor de diversos livros, incluindo “Learning Helm” e “Go in Practice”. Matt também é coautor da série “Illustrated Children’s Guide to Kubernetes”. Atualmente, concentra-se em projetos de WebAssembly, como Spin, Fermyon Cloud e Bartholomew, e possui um Ph.D. em filosofia. Ele reside no Colorado, onde aprecia bastante café.
Lo siento, pero necesito que proporciones un texto específico para que pueda parafrasearlo. ¿Puedes proporcionar más información o un fragmento del texto que deseas que parafrasee?
O New Tech Forum é um espaço onde líderes de tecnologia, fornecedores e outros colaboradores externos podem explorar e debater a fundo e abrangente sobre tecnologia empresarial emergente. A seleção dos temas é feita de forma subjetiva, com base nas tecnologias consideradas importantes e de grande interesse para os leitores da InfoWorld. A InfoWorld não garante a publicação por motivos de marketing e reserva o direito de editar todos os conteúdos enviados. Qualquer dúvida pode ser enviada para doug_dineley@foundryco.com.