Serverless Computing – Aula 4 – Parte 1
Serverless Computing – Aula 4 – Parte 1
Professor: Fernando Sapata
Possibilidades que serverless conseguem entregar:
Modernização de aplicações por meio do padrão de projeto de “estrangulamento” Strangler pattern.
Na pratica: Recortar pequenas partes da aplicação e mover para novas arquitetura, estratégias ou até mesmo novo paradigma.
A modernização de uma aplicação para por um processo de desidratação da aplicação de forma sequencial e enquanto aplicação monolítica principal ainda esta em execução. Desta forma conseguimos criar pequenos recortes da aplicação em funções que são chamadas de forma individual e que entregam o resultado que se espera para cada uma delas.
Exemplos de de estratégias combinadas:
1- Primeiro exemplo: Sistema já em nuvem, mas utilizando IaaS somente.
2- Isolando funcionalidades utilizando funções lambdas como mecanismo de processamento: (Hibrido entre IaaS e Faas)
ELB – Faz redirecionamento de portas. (Elastic load balancer)
ALB - Faz load balance de aplicação, atuando na camada 7 do modelo de rede.
3- Cenario onde temos, (FaaS, Paas e Iaas) com Lambda (Faas), EKS(Paas) e Maquinas EC2(IaaS).
4- Neste desenho a aplicação já esta toda redesenhada e temos domínios de dados para cada um dos domínios de funções.
Dica: O processo de modernização não precisa ocorrer do dia para a noite ou vice-versa.
Serverless Computing – Aula 4 – Parte 2
Professor: Fernando Sapata
- Utilize sempre um gateway de API na frente das suas funções.
Motivo: O gateway de API ajuda na abstração da sua função do seu chamador. Isso ajuda não só a proteger a sua função, como também evita quebras de código com futuras e necessárias atualizações das funções.
- Utilize uma única função por rota:
Motivo: Criar funções especializadas e uma rota por função.
- Não esqueça dos testes:
Motivo: Utilize as mesmas estratégias de testes do desenvolvimento tradicional nas funções serverless. Por meio das ferramentas já listadas (Serverless framework, ferramentas para integração com dependências externas e mockup ).
- Desenvolva localmente sempre que possível:
Motivo: Menor tempo de desenvolvimento de time to market.
- Salve configurações da aplicação fora da aplicação:
Motivo: Melhora a portabilidade do código.
- Utilize logs em todas as camadas:
Motivo: Observabilidade do ambitente. Saber exatamente como sua aplicação esta se comportando para poder otimizar sempre que necessário. Identificar comportamentos anormais da sua aplicação.
- Implementar ID único de transações:
Motivo: Ter um ID único preferencialmente criado na borda (inicio) para ter tracing da transação de ponta a ponta e identificar onde parou e por que parou. (Cuidado com LGPD)
- Considerar funções efêmeras:
Motivo: Criar o design da sua função sempre considerando que ela será iniciada a frio e todo o tempo que isso pode levar. Cuidado com dependências e tempo de carga devem ser tomados, pois funções como serviço são descartadas ao fim da sua execução e isso causa tempo e delay de carregamento em quase todas as chamadas.
- Considere sempre o Cold start:
Motivo: Informado no tópico de funções efêmeras. O tempo entre o momento que a função é chamada não é o tempo que de fato ela pode processar são diferentes e isso deve ser considerado.
- Evite Wait time no código:
Motivo: Não coloque eventos de espera no código, isso vai custar dinheiros para a execução da sua aplicação. (Criar orquestração ou coreografia para controlar a execução síncrona ou assíncrona para o seu código).
- Evitar funções monolíticas:
Motivo: Não criar mais de uma função por rota. Problemas de rota e de load (Cold start) podem ser criadas se criar funções com muitas responsabilidades e dependências.
- Gerenciar corretamente as dependências:
Motivo: Evitar carregar muitas dependências para a criação de uma função. Levar somente as dependências necessárias.
- Comece utilizando CI/CD:
Motivo: O custo de tempo e dinheiro para criar uma esteira de desenvolvido sera muito maior se comparado a criação deste modelo desde o início. Considere custos não somente dinheiro, mas riscos e tempo.
- Considere o tempo total de execução das suas funções:
Motivo: Considere monitorar o tempo total de execução de uma função pois se ela variar o custo de execução dela também deve variar e você pode ter surpresas na sua conta. Os fornecedores de cloud permitem o monitoramento destes dados.
- Faça fine tuning das configurações de memória:
Motivo: Existe uma relação entre CPU e memoria nos provedores de cloud, ou seja, como só conseguimos fazer tuning de memória nas funções como serviço, utilize maiores valores de memoria para atender funções que sejam mais dependentes de CPU, pois quanto mais memória, mais CPU estará disponível.
Faça testes constantes e identifique sempre que possível o valor optimal para cada uma das suas funções.
- Considere o custo total da solução:
Motivo: Os custos unitários de funções como serviço são muitas vezes muitos baixos e podem gerar a ideia que tudo será muito barato. Não se engane e calcule tudo muito bem para não ter surpresas. Custo não é valor, quando se deparar com custos divergentes, compare o valor de cada um deles, faça comparações justas considerando as características de cada um dos cenários.
Para comparar Lambda com maquinas EC2, o correto é comparar o 1 Lambda -> 3 EC2, considerando a questão da alta disponibilidade.
- Utilize funções para minificar o seu código:
Motivo: Economia de espaço, tamanho da função, tempo de cold start e consequentemente custo total de execução;
Outro aspecto na minificação é dificultar a interpretação do código e otimizar a camada de segurança do código.
A minificação pode ser implementada diretamente no pipeline de desenvolvimento. (Sempre avaliar se a linguagem permita esta técnica)
- Separar o Handler da função da sua lógica de negócio:
Motivo: Criar mecanismos de portabilidade e evitar vendor lock-in. Este processo pode ser integrado ao pipeline de desenvolvimento do seu código e ser feito de forma automatizada.
- Garantir a idempotência do código:
Motivo: Permitir e criar mecanismos para evitar duplicidade de execução de mecanismos do sistema. Isso é muito importante para não criar problemas de falta de integridade na sua aplicação ou bases de dados.
- Mais coreografia e menos orquestração:
Motivo: Evitar pontos únicos de falha e muita responsabilidade para um componente. A ideia de usar coreografia nos fluxos entre sistemas e funções é dividir a responsabilidade entre os componentes e entregar a cada um deles a responsabilidade de saber o que fazer com a informação recebida e para quem entregar após o processamento.
Serverless Computing – Aula 4 – Parte 3
Professor: Fernando Sapata
EP 10. Arquiteturas de referência
“Quais são as aplicações praticas de tudo que a gente viu até agora?”
