

Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
Uma instituição financeira está redesenhando sua arquitetura de TI, migrando de uma arquitetura monolítica para microsserviços executados em contêineres sobre Kubernetes. Em um segundo momento, alguns componentes pontuais (por exemplo, funções de validação de CPF, cálculo de score ou envio de notificações) foram implementados em modelo serverless (Functions as a Service), disparados sob demanda.
Para lidar com a complexidade crescente da comunicação entre microsserviços (observabilidade, tracing, retry, circuit breaking e políticas de segurança mTLS), a equipe está avaliando a adoção de um service mesh (como Istio ou Linkerd).
Com base nesse cenário, é correto afirmar que:
a adoção de serverless torna desnecessária a arquitetura de microsserviços, pois funções serverless substituem, por definição, serviços implantados em contêineres em qualquer cenário;
em uma arquitetura com service mesh, a comunicação entre serviços passa a ocorrer sem uso da rede, por meio de chamadas diretas em memória entre sidecars, eliminando latência e falhas de transporte;
a principal função de um service mesh é substituir o orquestrador de contêineres, assumindo responsabilidades de agendamento de pods, distribuição de carga entre nós físicos e detecção de falhas de hardware;
microsserviços e serverless são abordagens mutuamente excludentes, de forma que uma aplicação que utiliza funções serverless não pode, ao mesmo tempo, empregar serviços em contêineres para o mesmo domínio de negócio;
o uso de um service mesh busca externalizar, para a infraestrutura, diversas preocupações transversais, como roteamento de tráfego, telemetria, autenticação mútua (mTLS) e políticas de resiliência, reduzindo a necessidade de implementar essas funcionalidades no código de cada microsserviço.