Home > Gestão

Serverless: 3 principais problemas e como resolvê-los

Siga estas dicas para eliminar estrangulamentos, gargalos injustificáveis e problemas de custo

Peter Holditch *, InfoWorld/EUA

07/02/2019 às 7h24

Foto: Shutterstock

Serverless computing oferece uma infraestrutura que permite que os recursos do servidor sejam aplicados a um sistema conforme necessário. Quando ocorre um evento pré-definido, o código escrito especificamente para executar uma função é acionado e a plataforma sem servidor executa a tarefa.

Isso significa que ninguém precisa se preocupar com servidores individuais em tempo de execução (francamente, ninguém se importou com eles). As economias de escala fazem com que seja rentável terceirizar o gerenciamento de uma frota de servidores para um provedor de nuvem, enquanto a interface “serverless” torna essa relação de terceirização o mais simples possível, minimizando o contrato. Os clientes não precisam dizer ao fornecedor da nuvem quantas vezes essas funções serão acionadas e pagam uma fração de um centavo toda vez que uma função é executada.

Essas arquiteturas sem servidor referem-se a aplicativos que dependem significativamente de serviços de terceiros — como Backend ou “BaaS” — ou no código personalizado que é executado em contêineres efêmeros — “FaaS” (Function as a Service) ou Plataforma de Função como Serviço.

Trocando em miúdos, o modelo serverless permite passar o controle de ajuste de desempenho de servidores individuais para unidades de consumo (como quantidade de armazenamento, throughput ou memória).

Aí, a reação imediata de muitas pessoas é tentar substituir os dashboards e alertas de controles de seus servidores por dashboards e alertas relacionados às suas funções serverless. Infelizmente, no entanto, isso não resolve fundamentalmente o desafio do gerenciamento de aplicativos. Porque assim como ninguém realmente se importava com servidores, ninguém realmente se preocupa com as funções serveless isoladamente.

Geralmente, as pessoas se importam é com o nível de serviço que o sistema está fornecendo aos seus usuários. Isso significa que o monitoramento, para ser valioso, deve se concentrar em coisas que podem dar errado, e no contexto de servidor, “dar errado” significa principalmente uma tentativa de violar as leis da física, já que “esgotar a capacidade do servidor” é cada vez mais difícil.

Então, quais são os problemas típicos do modelo sem servidor e como eles se manifestam? Aqui estão três grandes problemas que afetam as implantações serverless e as formas de mitigá-las.

1 - Custo inicial
Problema: Este é um problema frequentemente discutido com sistemas sem servidor. Para maximizar a utilização, os provedores sem servidor, às vezes, optam por encerrar totalmente as funções inativas. Quando a carga é retomada, o custo de inicialização da função causa um impacto no tempo de resposta. Quando uma função de negócios é composta por muitas funções sem servidor encadeadas, esse efeito pode ser agravado.

Mitigação: Muitos usuários fazem ping artificialmente em suas funções para garantir que permaneçam vivas. Para aplicar efetivamente essa estratégia a uma rede de serviços encadeados, é imperativo entender os relacionamentos de ponta a ponta entre eles, de modo que todos os serviços nas cadeias de dependência sejam mantidos ativos, tornando essencial o rastreamento de transações de negócios de ponta a ponta.

2 - Estrangulamento
Problema: Plataformas sem servidor limitam o número de solicitações simultâneas que as funções sem servidor executarão, geralmente na conta e no nível de função individual. Quando o limite de simultaneidade for atingido, outras solicitações do usuário serão enfileiradas, causando tempos de resposta estendidos. Embora possa parecer contra-intuitivo limitar nosso conjunto de recursos de computação efetivamente ilimitado, isso impede a exposição a faturas potencialmente ilimitadas (não se esqueça de que a capacidade é cobrada com base no consumo).

Mitigação: eleve os limiares! Ou, pelo menos, certifique-se de configurá-los com sabedoria para atender a quaisquer requisitos não funcionais que você tenha em termos de tempo de resposta e uso simultâneo. Novamente, a visibilidade de ponta a ponta é necessária para que você possa identificar precisamente o que foi limitado e o impacto que a otimização teve na experiência do usuário final.

3 - Gargalos injustificáveis
Problema: OK,  você removeu todos os estrangulamentos, e agora suas funções suportarão tantos pedidos simultâneos quanto você possa imaginar. Problema resolvido! Infelizmente, estaria mais para um caso de problema movido. Mais cedo ou mais tarde, suas funções precisarão persistir em algum estado em algum lugar. Dependendo de onde é, você pode ter mais problemas. Mais cedo ou mais tarde, você precisará aguardar para ler ou gravar dados, o que significa que seus lambdas infinitamente escalonados estarão aguardando o acesso aos dados - enquanto você está sendo cobrado pela espera improdutiva.

Armazenamento de dados em nuvem: os serviços de dados em nuvem estão se tornando cada vez mais elásticos, mas muitos ainda exigem que você configure recursos com base em volumes de leitura e gravação simultâneos.

Sistemas tradicionais: Nenhuma função é uma ilha, e muitos usuários empresariais de serverless estão agrupando sistemas existentes com funções sem servidor (às vezes, mainframes, às vezes, implantações convencionais baseadas em servidor). Embora seja fácil aumentar os limites para permitir que as funções sejam dimensionadas, isso simplesmente significa que é fácil sobrecarregar qualquer back-end que você não consiga escalar tão facilmente.

Mitigação: Para certificar-se de que seus sistemas de back-end podem lidar com a carga máxima teórica, ajuste-os em conjunto com os controles de estrangulamento. Isso ajudará você a garantir que o sistema funcione perfeitamente de ponta a ponta, evitando custos desnecessários e insatisfação do cliente. Em alguns casos, pode ser necessário replicar dados para permitir que sistemas diferentes o acessem de diferentes locais. (É claro que isso ocorre ao custo de maior complexidade de gerenciamento de dados e ao risco de inconsistências se infiltrarem nos dados.)

Novamente, entender os fluxos de ponta a ponta através de seu sistema no nível da transação é crítico para identificar e alertar sobre gargalos na produção, e também para analisar o sistema de ponta a ponta para ajustes.

Serverless ops é devops
Eu ouço o que você está dizendo: “Mas eu sou um desenvolvedor! Por que eu deveria me importar com essa coisa de implantação maluca e não funcional? ”

Aqui está a maior implicação sem servidor de todos: a configuração agora é no código (ou pelo menos parte dele). O que os desenvolvedores entregam à produção no mundo sem servidor é todo o pacote, não apenas peças funcionais.

Isso, por sua vez, significa que, quando você depurar problemas de produção com seu IDE, no mundo sem servidor, é melhor se familiarizar com algum tipo de solução de gerenciamento de desempenho. Pelo menos metade dos seus "bugs" pode ser relacionada à implantação. Não é mais “culpa deles” (isto é, Ops). O destino do sistema está totalmente em suas mãos e a visibilidade de ponta a ponta no nível do aplicativo se tornará essencial para você.

 

(*) Peter Holditch é gerente de produto principal sênior da AppDynamics

Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail