Containers salvam recursos e reduzem o tempo de implementação, assim como o serverless. Containers são excelentes hosts para microserviços, assim como o serverless. Contudo, as opções de implementação são mais diferentes do que parecidas, e é sobre isso que vamos falar nesse post.

A computação serverless pode ser tanto a resposta perfeita para o problema relacionado a implementação de uma aplicação quanto um desastre muito caro esperando para ocorrer.

VMs, containers e arquitetura serverless possuem pontos distintos a favor e contra, contudo, o serverless pode acabar quebrando tudo se as aplicações não são condicionadas para serem usadas nessa arquitetura. Para prevenir uma implosão da TI, certifique-se de que os desenvolvedores tenham as informações e tomem uma decisão correta sobre como proceder com novas implementações e quando usar containers ou serverless.

Para determinar qual dos dois é mais apropriado, ponha em contraste o que cada arquitetura oferece, a base de usuários da aplicação e o que é requerido para que o projeto de implementação seja considerado um sucesso.

As VMs, apesar de não estarem no escopo desse artigo, são mais comumente usadas e compreendidas como uma arquitetura de host de aplicações nas empresas. Esse artigo compara primariamente a arquitetura serverless, que tiram a responsabilidade sobre os recursos totalmente, e os containers, que são uma camada mais rápida e leve de se lidar que os sistemas operacionais.

 

O que um app necessita

O benefício econômico da computação serverless é que a empresa paga pelos recursos de computação e execução de aplicações apenas quando a aplicação é executada, tempo ocioso não possui custos. O serverless é melhor indicado para aplicações e componentes que precisam estar “sempre disponíveis”, mas nem sempre em execução.

Por exemplo, uma aplicação de IoT usada em uma fazenda gera um evento quando o sensor de umidade indica que o solo está seco e precisa ser irrigado. Essa aplicação em uma arquitetura tradicional poderia permanecer ociosa por muitos dias em tempos chuvosos, esperando para ser ativada e no processo consumindo recursos que poderiam ser melhor aplicados. Um sistema de container reduz a quantidade de recursos que essa aplicação consome, mas a computação serverless iria eliminar esse consumo sem necessidade durante os tempos de espera. Então, podemos concluir que, quanto mais tempo uma aplicação fica em espera, mais atrativo o serverless se torna, certo?

Como sempre, a resposta é mais complexa do que parece à primeira vista. Os benefícios de uma arquitetura serverless incluem o exemplo anterior do app IoT pronto em milésimos de segundos, ao passo que o sistema de conteinerização um tempo um pouco maior, mas que não afeta o desempenho do app. Além disso, nem toda aplicação que gasta mais tempo ocioso do que em produção é um bom candidato para arquitetura serverless. Os sistemas serverless é tecnicamente diferente de um sistema de container.

 

Tecnologia Serverless vs Container

Quando você entra mais a fundo nos detalhes da arquitetura serverless, se depara com termos como:

  • Microserviços: aplicações divididas em componentes menores, independentemente escaláveis e implementados
  • Computação Funcional: execução sob demanda de funções do aplicativo, como serviço pelo host da nuvem
  • Funções Lambda: funções anônimas C++ que transformam as coleções de dados passados e produzem novas coleções subsequentes
  • Stateless: uma aplicação que não usa ou não requer dados de eventos anteriores

 

A computação em nuvem serverless mira em processamento independente de contexto, para aplicações stateless. Quando apps serverless são ativados em um evento, eles iniciam uma cópia fresca do código, que não leva em consideração nenhum evento anterior. Qualquer evento que necessita de eventos ou requisições anteriores que precedem sua ocorrência são considerados stateful. Se você inicia uma segunda cópia da arquitetura serverless para incrementar o trabalho a ser feito, essa segunda cópia não vai automaticamente saber o que a primeira cópia esteve fazendo anteriormente.

É possível tornar aplicações stateful utilizáveis em arquiteturas serverless por meio de controle back-end de estado ou por uso de client, mas isso precisa estar escrito dentro do código da aplicação. Essa opção dificilmente existe um software de partes terceiras. Mesmo que as aplicações sejam desenvolvidas internamente, implementar um comportamento stateful em implementações serverless requer um conjunto difícil de skills e provável custo alto.

Os containers por sua vez podem rodar virtualmente qualquer aplicação ou componente de aplicação sem uma mudança significativa no código, o serverless não. A maior parte das aplicações do negócio performam processos de transação onde uma ou mais base de dados são atualizadas, o que apresenta ainda mais desafios para o comportamento stateless. Tornar aplicações stateless capaz de fazer processamento de transações pode gerar colisões: dois requerimentos em um inventário ou conta de balanço que reporta uma venda ou saque de forma individual, resultando em um balanço que não tenha soma zero. As empresas podem redesenhar ou readequar as aplicações com uma mistura de comportamentos stateless e transacionais, mas é um processo complicado que requer muito tempo de trabalho e experiência. Containers simplesmente não possuem esse requerimento.

 

Conectado à Realidade

A abordagem dos desenvolvedores sobre serverless vs container em geral busca entender o que é melhor para a aplicação, mas também deve ser levado em consideração o processo de implementação para ambos os casos. A rede de container é explícita e baseada em subrede de IP, o modelo mais comum de implementação de apps. Os sistemas de container usam um endereço privado de IP dentro de uma aplicação, mas os administradores podem seletivamente expor endereços dos componentes para prover serviço aos usuários ou outras aplicações em uma VPN ou na internet. Com a computação serverless, o adereçamento de rede e load balacing, assim como outros aspectos operacionais, são gerenciados pelo framework serverless da nuvem, e você pode necessitar de passos especiais para integrar os componentes serverless com aplicações e componentes presentes em uma nuvem mais tradicional ou no seu próprio data-center.

Os containers requerem uma locação de host de longo termo, enquanto o serverless não. Containers podem suportar suportar um volume amplo de requisições e serviços com bons tempos de resposta, mas apenas se você implementar cópias em cada área geográfica. Esse modelo de implementação divide a carga de trabalho, cria mais tempo ocioso ao longo das várias aplicações e aumenta os custos. Por contraste, os apps serverless podem rodar qualquer número de cópias em uma carga de trabalho em qualquer lugar que tenha os recursos necessários.

 

Como fazer o host de microserviços

Microserviços – componentes auto-contidos de código aplicações distribuídas que podem ser divididas e escaladas de forma independente – podem ser implementadas em containers ou serverless. A diferenciação se dá sobre qual tipo de microserviços você possui. Como os microserviços são stateless, eles são fortes candidatos para implementação serverless. Contudo, quando microserviços são frequentemente componentes gerais compartilhados por múltiplas aplicações. Quando microserviços são compostos por diversas aplicações diferentes, o container é uma opção melhor de implementação que o serverless. Microserviços em arquitetura serverless, quando usados regularmente, podem resultar em aumento significativo do tempo de resposta da aplicação, devido a requisições de componentes sob demanda.

O Serverless certamente irá evoluir, mas existem diferenças claras entre serverless e containers tanto em termos técnicos quanto em níves de custo de gerenciamento. Em alguns casos, essas diferenças vão tornar a escolha fácil, contudo, em outros, a equipe deve adotar um modelo misto, mesmo que isso adicione um pouco de complexidade.