Serverless é um ótimo martelo, mas nem tudo é prego! De acordo com o site serverless.com, Serverless é sobre focar seus esforços no que traz valor para os seus usuários. Ou seja, como um desenvolvedor, você não precisa pensar em servidores, apenas no desenvolvimento do código.
Em outras palavras, a ideia é abstrair as partes mais complexas do desenvolvimento de uma aplicação, permitindo que o time se dedique no código. Você não precisa provisionar servidores (Virtual Machines, ou servidor virtual) ou pagar por recursos que você geralmente não usa.
Assim como a internet sem fio tem fios em algum lugar, a arquitetura serverless ainda tem servidores em algum lugar
Para usar um servidor, você precisa abrir o terminal de comando e escrever o que ele deve fazer. Quando pensamos em larga escala, vemos a dificuldade de gerenciar múltiplos servidores. E quando precisamos que escale, acaba não sendo uma tarefa simples e fluida.
Com o Serverless, isso se torna uma tarefa simples. Você não precisa configurar máquinas. Simplesmente você desenvolve uma função (menor objeto executável de uma aplicação) e sobe em alguma plataforma Serverless.
Vantagens
- Trabalhar com múltiplas linguagens, agregando o melhor de cada uma em uma só solução (bem parecido com uma solução que usa Docker/Kubernetes).
- Não há necessidade de gerenciar a infraestrutura.
- É facilmente escalável.
- A cobrança será feita pelo número de chamadas do Serverless (e algumas outras variáveis, dependendo da plataforma que escolher).
- O Deploy e atualização são rápidas de fazer.
Desvantagens
- Testes e debugging são mais difíceis de serem realizados.
- A arquitetura Serverless não é feita para executar processos longos (o tempo é contabilizado em algumas plataformas e cobrado junto com memória e número de execuções).
- A performance é afetada por conta do tempo de execução de todo o processo do Serverless.
- Risco de enfrentar Lock-in, por usar uma plataforma Serverless exclusivo de um único fornecedor (Vendor Lock-in).
Serverless ou FaaS (Function-as-a-Service)?
O Function-as-a-Service (ou simplesmente FaaS) é o serviço baseado na computação Serverless.
Aqui você começa a ser cobrado por um conjunto de chamadas das funções, criando um modelo de cobrança diferente do que já tínhamos visto antes, como o IaaS (Infrastructure-as-a-Service) ou o PaaS (Platform-as-a-Service), onde somos cobrados pelo tempo em que o servidor está ligado.
Em um FaaS, você consegue subir uma função ou utilizar o editor online do serviço (no caso do IBM Cloud Functions), para desenvolver e disponibilizar direto na plataforma.
Com a função na plataforma, você já consegue executar e retornar um valor. Após esta execução, o processo é dado como encerrado. Bem simples, não? Um ponto importante é a possibilidade de você separar todos os serviços e endpoints de uma solução em pequenos blocos de código, para formar diversos microserviços.
Boas Práticas no uso de Serverless
Depois de entender o que é um Serverless e como funciona, chegou a hora de ver a lista de boas práticas no seu uso.
1. Cada função deve fazer apenas uma ação
A função deve ser criada para realizar uma única operação. O erro é pensar em Serverless como uma maneira mais econômica de executar uma aplicação Monolítica. Aqui você desacopla as ações em funções diferentes, ou seja, cada função deve ser responsável por executar uma ação diferente. Quanto mais genérico, melhor a sua reusabilidade.
Caso uma função acumule mais de uma tarefa, você vai ter como resultado um código maior, tempo de execução maior e pode ter problema na escalabilidade. Quando você separa as tarefas, você consegue reverter os problemas mencionados e dessa forma consegue reutilizar a mesma função para outros cenários.
Um exemplo prático é o repositório serverless-chatbot. Nele você irá encontrar duas funções, uma para enviar a mensagem para o Watson Assistant e outra que insere o JSON de retorno em um MongoDB. Ambas executam uma ação diferente e são facilmente reutilizadas em outros cenários.
Veja meu GitHub sobre Serverless-Chatbot
2. Uma função não deve chamar outra função
Imagine que você criou uma cadeia de funções uma chamando a outra (n+1). A função inicial irá encerrar a execução quando a função seguinte encerrar a execução e retornar, e assim por diante. Seguindo nessa lógica, quanto mais funções você tiver executando em cadeia, maior será o tempo de execução da função inicial. Lembre-se que o tempo de execução da função é um dos fatores para gerar o custo mensal de Serverless. Por isso que ao seguir este formato, você estará usando um anti-pattern.
Para evitar este problema, você pode usar um componente que forme uma cadeia de funções, como é o caso da Sequence no IBM Cloud Functions (Apache OpenWhisk). A função é chamada, executada e encerrada (fechando o ciclo de vida), para depois iniciar a próxima função. Os parâmetros de saída da função se tornam os parâmetros de entrada da próxima função. Assim você otimiza a cadeia de execução das suas funções.
3. Use a menor quantidade possível de bibliotecas
As funções que são executadas passam por dois estados: “frio” e “quente”. Chamamos de estado “frio” quando você chama a função pela primeira vez. A plataforma Serverless precisa subir um container (pré-configurado para aquela linguagem) com o seu código. O estado muda para “quente” quando o ambiente está pronto para executar a sua função. O tempo de subir o container com a função depende de alguns aspectos, sendo um deles o tamanho do seu código incluindo pacotes e bibliotecas necessárias para a execução.
Quanto maior o seu código, mais pesado ele é. Ao chamar um método que usa apenas 10% de uma biblioteca que pesa 50 MB, você estará carregando 45 MB de código que não será usada em nada. Por isso é importante avaliar se é necessário usar uma biblioteca ou construir do zero.
Se a plataforma Serverless, como é o caso do IBM Cloud Functions, já disponibiliza uma lista de bibliotecas, priorize o uso destas ao invés de construir uma função com outras bibliotecas. No projeto Logdna-COS, todas as bibliotecas usadas já são disponibilizadas pela plataforma. Construir dessa forma ajudou na otimização e na portabilidade do código, além da velocidade de execução.
Veja o GitHub sobre Logdna-COS
4. Use com serviços de mensagerias e filas
As plataformas Serverless costumam ter melhor performance com aplicações assíncronas. Uma aplicação que trabalha com filas consegue ter um ótimo aproveitamento com o uso de funções construídas em Serverless.
Como é o caso do IBM Cloud Functions, é possível configurar a sua função para ser chamada pelo Event Streams (Apache Kafka-as-a-Service). A aplicação que enviou a mensagem no Event Streams não conhece a função no Functions e vice-versa. Assim que tiver alguma mensagem na fila, uma função é executada. Caso ocorra alguma falha, você pode enviar para uma fila para posteriormente avaliar e executar novamente.
5. Padronize o deploy de todas funções com um arquivo YAML
De um projeto que demande a construção de uma função, até um projeto de larga escala que demande 100 funções, você consegue controlar o deploy de todas em um único arquivo YAML. Ao invés de executar um comando de linha para cada função, você pode executar um único comando como ibmcloud fn deploy —manifest manifest.yml para subir as funções e outros componentes. Isso facilita a padronização de todos os itens do projeto.
No exemplo abaixo, em um único arquivo YAML, é definido a função chamada Index, um Trigger e um Rule (componentes do Apache OpenWhisk).
Conclusão
Existem ainda muitos outros pontos possíveis de serem explorados. Abordei aqui os 5 itens que,
conforme minha experiência em projetos envolvendo a tecnologia Serverless, são críticos e podem ajudar
a explorar da melhor forma esta tecnologia. Dominar esses passos chave pode ajudar na hora de avaliar
como fazer a arquitetura de um projeto ou planejar sua aplicação e vale continuar os estudos nessa tecnologia e em muitas outras para ampliar as capacidades de desenvolvimento e o potencial para inovar nas implementações.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?