BT

Desafios de aplicações Serverless em ambientes híbridos

| por Manuel Pais Seguir 9 Seguidores , traduzido por Helio Silva Seguir 0 Seguidores em 11 mai 2018. Tempo estimado de leitura: 3 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar por dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT