Serverless com Node.js: aplicações eficientes na Cloud

A arquitetura Serverless - Apresentação

Olá! Meu nome é Lucas Santos e serei seu instrutor nesse curso em que aprenderemos a trabalhar com Node.js e Serverless Framework.

Lucas Santos é um homem de pele clara e rosto arredondado. Tem cabelos e barba castanhos, ambos curtos. Tem olhos verdes, usa óculos com armação quadrada na cor preta com detalhes vermelhos nas laterais e um piercing na orelha direita. Está de camiseta cinza. O fundo está desfocado, uma luminária com luz azul está apontada para uma parede lisa.

Esse curso é para pessoas que querem aprender a trabalhar com arquitetura Serverless ("sem servidores") de forma eficiente e sem abandonar os ambientes mais tradicionais como JavaScript e Node.js. Trabalharemos tudo isso em cima do AWS Lambda.

Usaremos, como exemplo, a aplicação de um corretor de atividades de prova. Uma aplicação em que as pessoas podem colocar seu nome e responder a perguntas de múltipla escolha para, em seguida, ao clicar no botão "Enviar", visualizarem o resultado e o total de perguntas que acertaram.

Vamos migrar essa aplicação de uma arquitetura tradicional (máquina virtual) para arquitetura Serverless. Vamos entender como essas arquiteturas funcionam, quais seus prós e contras e porquê faz sentido migrar essa aplicação de uma máquina virtual para uma arquitetura Serverless.

O que aprenderemos sobre Arquitetura Serverless:

• Como funciona?
• Quais são as vantagens?
• Por que é mais eficiente?
• Principais provedores
• O que é o Serverless Framework e como ele funciona?

Além disso, vamos aprender sobre modificações necessárias na aplicação para migrar de uma arquitetura tradicional para uma arquitetura Serverless.

Pré-requisitos

Lembre-se de fazer os cursos que são pré-requisitos para este curso. Como vamos trabalhar bastante com infraestrutura e com JavaScript é bom que você tenha conhecimento prévio de Linux, JavaScript, Docker e um pouco de AWS.

Se você já tem os pré-requisitos necessários, vamos desbravar esse mundo da arquitetura Serverless!

A arquitetura Serverless - Arquiteturas atuais

Primeiro, vamos entender os conceitos que originaram a arquitetura Serverless.

Imagine o seguinte exemplo: trabalhamos na Alura e fazemos parte de um time que cuida de vários projetos, um desses projetos é o projeto de correção de atividades e recebemos uma requisição externa solicitando um upgrade desse projeto.

Nós recebemos o código para analisar como ele está funcionando atualmente e verificamos que ele está funcionando através de uma máquina virtual.

No VS Code, ao abrir o projeto, vemos que ele tem um arquivo index.mjs, que está sendo a base de toda a aplicação. Mas como isso tudo funciona?

Vamos abrir o console do VS Code e executar o comando:

npm start

Podemos verificar no código do arquivo index.mjs que o servidor está rodando na porta 3000.

// código omitido

app.use(express.static(join(__dirname, 'interface')))
app.listen(process.env.PORT || 3000, () => {
  console.log('Server started')

Vamos abrir o navegador e acessar a porta 3000 para acessar a aplicação:

http://localhost:3000

No navegador, estamos na página inicial do nosso sistema. Essa página é intitulada "Atividades do curso", tem um campo "digite seu nome" e logo abaixo tem 4 perguntas de múltipla escolha em que as respostas possuem radio buttons para selecionarmos.

No fim da página temos dois botões: um azul "Enviar" e um vermelho "Limpar".

Ao clicar no botão "Enviar", vamos para a página "Resultados", que informa quantas perguntas nós acertamos. No caso, apareceu:

Lucas Santos você acertou 0 de um total de 4 perguntas

E abaixo temos um botão "Tentar novamente".

Podemos ver no index.mjs que as quatro perguntas são fixas, não temos um banco de dados. Elas são guardadas em um Map().

// código omitido

const correctQuestions = [3, 1, 0, 2]
const previousResults = new Map()

Imagine que, após analisarmos o código e a aplicação, nós perguntamos qual era o motivo para a solicitação de uma melhoria e responderam que precisamos melhorar os custos, porque a máquina virtual está muito cara.

Vamos entender porque isso está caro.

Para entender melhor como isso funciona, precisaremos entender como as arquiteturas tradicionais funcionam.

Máquinas Virtuais

Monólitos - Tudo no mesmo lugar

Existem vários tipos de arquiteturas dentro de uma máquina virtual, essa é a mais comum: monólitos. Neste caso temos uma única aplicação e está tudo no mesmo lugar, na mesma máquina.

Esse é o caso do nosso projeto atualmente.

Microsserviços – Serviços agrupados por responsabilidades

Os microsserviços são uma evolução da arquitetura de monólito onde separamos os serviços por responsabilidade. Imagine, por exemplo, que temos um serviço de usuário, um serviço de login, um serviço de cursos, cada um tem sua própria responsabilidade e esses serviços podem rodar na mesma máquina virtual ou em máquinas virtuais diferentes e se comunicam pela rede.

Então você precisa entender como essa comunicação funciona, como funciona a autenticação, entre outras coisas. Eles ficam mais complexos, sim, porque neste caso temos mais de um serviço. É como se pegássemos um serviço grande e o quebrássemos em várias partes.

Vantagens

As principais vantagens, tanto dos monólitos quanto dos microsserviços, é que eles tornam o processo de publicação mais simples.

Como está tudo no mesmo lugar, principalmente no monólito, só publicamos tudo uma vez e em uma só máquina.

Eles também são sistemas estabelecidos, são sistemas provados e robustos.

E também tem a questão mais controversa de todas, que são os recursos compartilhados. Esses recursos compartilhados são bons quando temos, por exemplo, um sistema de arquivos compartilhados onde temos que servir ou buscar arquivos em um mesmo lugar.

Desvantagens

Como qualquer tipo de tecnologia, elas têm alguma desvantagem.

A principal desvantagem das máquinas virtuais é emrelação à eficiência: máquinas virtuais sempre ativas gastando dinheiro e computação ociosa.

As máquinas sempre online, não conseguimos desligar uma máquina virtual e só ligar quando estamos executando um serviço. Por exemplo, sábado e domingo a aplicação interna de uma empresa não vai rodar porque as pessoas não trabalham nesses dias. Então, às vezes não faz sentido manter esse tipo de aplicação.

Outra desvantagem é em relação à complexidade e segurança, a máquina é o único ponto de falha. Se você conseguir acessar uma máquina de uma aplicação monólito, você pode quebrar a aplicação. Além disso, a complexidade tende a aumentar ao longo do tempo quando temos uma única aplicação, uma coisa fechada. É algo complicado de manter bem a longo prazo.

Também temos desvantagens nos recursos compartilhados. Compartilhar alguns recursos pode ser uma vantagem, mas compartilhar outros pode ser uma desvantagem: CPU e RAM compartilhadas são limitantes.

Ao compartilhar serviços em uma só máquina, estamos compartilhando CPU e RAM. Ou seja, estaremos compartilhando o que faz o computador funcionar. Se, por algum motivo, esgotar um serviço, ou se um serviço começar a utilizar mais do que outro, podemos ter problemas.

Chegamos ao fim desse vídeo. Nas próximas aulas vamos investigar qual pode ser a solução para a nossa aplicação!

A arquitetura Serverless - Arquitetura Serverless

Já entendemos como funcionam as arquiteturas tradicionais. Neste vídeo, vamos entender como podemos melhorar o serviço de correção de atividades usando uma arquitetura Serverless.

Mas, antes, precisamos entender mais alguns detalhes sobre o funcionamento das arquiteturas de microsserviços e monólitos.

Como disse anteriormente, microsserviços são sistemas distribuídos que estarão em várias máquinas e vamos comunicá-los pela rede.

Já citamos algumas vantagens e desvantagens no vídeo anterior, mas vamos discutir sobre mais alguns problemas:

Responsabilidade (agrupamento)

Um dos problemas da arquitetura de microsserviços é em relação à responsabilidade. Quanto mais longo for o seu projeto, mais difícil garantir que um serviço não vai sobrepor a responsabilidade de outro serviço.

Por exemplo, podemos ter um serviço simples de separar as responsabilidades, como um serviço de autenticação, tudo que for relacionado a autenticação é mais simples de fazer porque é um serviço mais fechado.

Mas quando temos processos que começam no serviço e vão para outro serviço fica difícil identificasr qual é a sobreposição de responsabilidades existente. É complicado ,acaba ficando numa zona cinzenta.

Monitoramento (visibilidade)

O monitoramento é um grande problema de microsserviços porque, como são sistemas distribuídos, você precisa garantir que o monitoramento de todos os lugares estejam bem corretos.

Porque se chamarmos um serviço e esse serviço chama outros quatro ou cinco serviços, e um deles dá algum erro e acaba não tendo o monitoramento correto, não saberemos que esse serviço está com erro. Porque não conseguiremos saber qual é a origem do serviço.

Já existem ferramentas para garantir um melhor monitoramento. Mas o problema dessas ferramentas é que elas são caras e tornam-se um custo a mais no seu desenvolvimento.

Compartilhamento (segurança)

O terceiro problema é o compartilhamento de segredos, coisas pela rede, etc. Como sempre, o compartilhamento é bastante complicado.

Servidores

O maior problema ao lidar com serviços que estão em máquinas virtuais é lidar com o servidor. Existem vários problemas, os três maiores são os seguintes:

1 - Configuração (manutenção e backup)

Precisamos configurar toda a máquina e fazer backups para garantir que não perderemos dados.

2 - Monitoramento (disponibilidade)

Precisamos garantir que o servidor fique online, mas para isso temos que ter um monitoramento constante. É bem trabalhoso fazer esse tipo de coisa.

3 - Custo (sempre ativo)

Por fim, temos o custo. Além do custo de manter o servidor, também existe o custo de segurança, por exemplo, quando fazemos manutenção e atualização do sistema operacional.

O custo é o maior dos problemas, com certeza. Porque o servidor está sempre online, não pagamos o servidor só pelos momentos em que ele está computando alguma coisa. Estamos pagando uma máquina virtual e essa máquina vai ficar online 100% do tempo e vai ter momentos de computação ociosa.

Esse é o maior agravante para nosso sistema de provas, esse sistema só precisa estar online quando as pessoas forem fazer as provas. Então não tem porquê ficar online o tempo inteiro.

Nanosserviços

Então, podemos trabalhar com uma evolução dos microsserviços: os nanoserviços. Essa é a ideia de separar nossos serviços no menor nível possível. E qual é o menor nível possível de uma API? É uma rota, por exemplo.

Então, pegaríamos uma rota, uma função, e colocaríamos essa função para rodar em algum lugar. Mas essa função, diferente dos servidores, não estará ligada o tempo inteiro, vai responder a determinados eventos, por exemplo, a uma requisição HTTP.

Foi dessa ideia que surgiu o movimento Serverless, que é representado pela letra grega Lambda. Principalmente por causa do primeiro provedor Serverless, o AWS Lambda.

Serverless

O Serverless resolve grande parte dos problemas que temos com a arquitetura tradicional. Alguns deles são:

1 - Configuração (delegada para o servidor)

O primeiro problema que não teremos é a configuração, pois delegamos essa configuração para provedor do serviço.

2 - Monitoramento (nativo)

Como o provedor precisa cobrar de acordo com requisições, com execuções e tempo de resposta, toda função Serverless vai ter monitoramento ativo.

3 - Escala (virtualmente infinita)

Vamos rodar a função em um computador compartilhado com milhares de funções de outras pessoas. Então, basicamente, usaremos toda a estrutura do provedor para rodar a nossa função. Poderemos escalá-la de acordo com o provedor e de acordo com o que precisarmos.

4 - Custo (baseado em execuções)

O custo diminui porque será baseado em execuções.

Geralmente, três fatores determinam o preço de uma função:

• quantidade de execuções
• tempo que demorou para a função serem executadas
• quantidade de memória alocada para a função ser executada

Fica mais barato rodar uma função porque será compartilhado com toda a infraestrutura Serverless. Fica em torno de 60% mais barato.

5 - Disponibilidade (sempre disponível)

Os provedores vão garantir, quase sempre, que teremos a disponibilidade quando precisarmos dessas funções.

6 - Performance (alta devido à leveza)

Quanto mais rápido, menor será o custo. Elas são altamente performáticas, principalmente devido à leveza de como elas executam.

Mas ao ouvir ou ler a palavra "Serverless", você pode achar que não terá mais servidores. Não significa isso, não será a forma tradicional de ter um servidor.

Ao trabalhar com Serverless, vamos delegar o gerenciamento dos servidores para os provedores de cloud. Geralmente, nossas funções serão executadas numa arquitetura de contêineres. Mas não precisamos gerenciar isso.

Desvantagens

Mas o Serverless também tem algumas desvantagens, principalmente em relação a limitações. O tempo de execução é limitado, podemos executar uma função por determinado tempo e depois ela vai ser automaticamente cortada.

Uma das limitações que teremos é em relação ao estado. Funções Serverless não mantém estado, tudo o que você precisa guardar não será compartilhado entre as próximas execuções. Será guardado tudo em memória.

Outro problema é o cold start. O que é o cold start? Imagine o seguinte: você tem um carro que ficou completamente parado por meses, ele vai demorar mais tempo para ligar. O mesmo acontece com funções. Quanto mais executarmos uma função, ela será cacehada e será executada mais rápido nas próximas vezes.

Mas, se não executarmos algumas funções durante algum tempo, elas caem no que chamamos de cold start, elas terão que inicializar o ambiente todo novamente, o que adiciona alguns milisegundos na sua execução inicial. O que pode ou não ser um problema, depende da sua aplicação.

O principal problema do Serverless é que estamos delegando tudo para o provedor. Ao fazer isso temos uma desvantagem chamada "vendor lock-in". Porque a maioria dos provedores não quer que você saia deles para fazer alguma coisa, então acabamos utilizando cada vez mais serviços do provedor e acabamos preso ao provedor.

• Limitações (tempo, memória, uso de CPU)
• Estado (funções não mantém estado)
• Cold start (cache de execuções)
• Vendor lock-in

Mas existem formas de resolver problemas como o vendor lock-in, veremos sobre isso na próxima aula.

Sobre o curso Serverless com Node.js: aplicações eficientes na Cloud

O curso Serverless com Node.js: aplicações eficientes na Cloud possui 187 minutos de vídeos, em um total de 61 atividades. Gostou? Conheça nossos outros cursos de Node.JS em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• A arquitetura Serverless
• Migrando o projeto
• Secrets e bancos de dados
• Segurança e autenticação
• Adicionando o login