Sam Newman, consultor independente e autor do livro "Building Microservices", falou na conferência Velocity em Londres sobre alguns dos desafios enfrentados quando os sistemas híbridos contam com arquiteturas sem servidor e infraestrutura tradicional. Em particular, Newman discutiu o quanto arquiteturas serverless mudam a nossa noção de resiliência e como os dois paradigmas se chocam em tempos de alta carga no sistema.
A resiliência em sistemas de arquiteturas tradicionais dependem de estado (por exemplo, um pool de conexão de banco de dados para acelerar e controlar a quantidade de solicitações que batem o banco de dados em qualquer ponto específico). A estabilidade neste tipo de sistema é mantida controlando a carga de entrada e equilibrando-a em múltiplas instâncias. Mas com funções efêmeras (lambdas) não há lugar para armazenar o estado de controle, portanto, precisa haver uma paridade entre as funções de auto-escala com carga e a forma como os bancos de dados do backend também se dimensionam.
Os bancos de dados da nuvem de escala automática, como o DynamoDB da Amazon ou o Bigtable da Google, se encaixam bem no paradigma serverless, mas Newman ressaltou que a maioria dos sistemas conta com bancos de dados tradicionais, e, simplesmente, as funções "sem efeito" serverless em um sistemas legados podem ter consequências drásticas. Newman destacou o fato de que até mesmo a Bustle enfrentava desafios inesperados. Embora eles tenham configurado explicitamente uma restrição de 1000 conexões lambda para qualquer um dos seus nó Redis (sabem que são capazes de lidar com 10 vezes esse número de conexões), eles ainda viram nós com falha porque as funções lambda parecem manter a conexão viva até três minutos depois de terem sido interrompidos (com base em evidências anormais). A engenharia da Bustle teve que aprofundar o funcionamento interno de Redis para corrigir esse problema (forçando essas conexões de zumbis a expirar mais rápido), o que evidencia a incompatibilidade entre arquiteturas servidor e serverless quando lidam com carga e resiliência, argumentou Newman.
Outro desafio que Newman mencionou é o fato de que os circut breakers, tipicamente usados em microserviços para lidar suavemente com falhas - efetivamente controlando a carga(shedding load), tornando o sistema mais resiliente - dependem de manter o estado em várias requisições. Por exemplo, para poder fechar o circuito (auto-cura), uma vez que o serviço se mostrou estar estável novamente.
Newman disse que as malhas de serviços, como a Istio ou a Linkerd, podem ajudar com alguns desses problemas, atuando como proxies persistentes com estado que podem coordenar a carga entre as funções do microserviço.
Finalmente, do ponto de vista da segurança, as funções estão sendo executadas por contêineres e, portanto, são vulneráveis a exploits em que um contêiner invade outro que esteja executando no mesmo host. Mas isso torna-se bastante difícil, pois o contêiner onde uma função é executada vive por um curto período de tempo, não podendo ser explorado depois que a função é encerrada. Especialistas em segurança, como Guy Podjarny, advertem, no entanto, que funções serverless transferem as preocupações de segurança para o nível da aplicação, e uma cadeia de chamadas de função pode ser explorada se não estiver segura corretamente.
Newman também mencionou a preocupação que muitas pessoas têm em torno do lock-in ao selecionar a implementação de uma Função como Serviço (FaaS) de um determinado fornecedor da nuvem, uma questão que foi abordada em um eMag do InfoQ. Passar a discussão de lock-in para compreender (e aceitar) o trade-off entre ir mais rápido (com menos carga cognitiva) e o custo da migração (que está diminuindo à medida que os conjuntos de recursos se tornam semelhantes em diferentes provedores de FaaS) é a chave para lidar essa preocupação.