Node.js: desenvolvendo aplicações serverless na nuvem

Serverless: o que muda na arquitetura - Apresentação

Apresentando o curso e o instrutor

Olá! Sejam muito bem-vindos a mais este curso de Node. Desta vez, vamos discutir sobre serverless. Meu nome é Vinícius de Neves, conhecido como o Dev careca, Oldboy barbudo, que já é seu melhor amigo aqui na Alura.

Audiodescrição: Vinícius é um homem branco, careca, com barba cheia e óculos. Ele veste uma camiseta preta e está em um ambiente de estúdio com fundo neutro.

Introduzindo a motivação e objetivos do curso

A ideia é começarmos pela motivação: o que nos leva a adotar esse tipo de abordagem e quais alternativas devemos considerar. Vamos entender qual é a premissa e adquirir uma bagagem arquitetural sobre o que significa trabalhar com serverless.

Em seguida, utilizaremos a AWS para aprender e entender todos os conceitos relacionados que já discutimos no início. O curso será bastante prático, com muito código.

Desenvolvendo aplicações práticas com AWS

No final, vamos desenvolver um CRUD utilizando o DynamoDB e realizar o upload de imagens para o S3, o repositório de imagens do S3. Caso não conheçamos a AWS em profundidade, não precisamos nos preocupar, pois disponibilizaremos bastante material para nos familiarizarmos com os termos e a terminologia.

Focando na prática com serverless

Vamos focar na parte de serverless. É essencial que tenhamos prática com o uso do terminal e com o Node.js. Não vamos nos concentrar na sintaxe da linguagem, mas sim no que é serverless e como implementá-lo na prática utilizando a AWS.

Esperamos que estejamos tão animados quanto o instrutor, que nos aguarda no próximo vídeo para começarmos a programar. Vamos em frente!

Serverless: o que muda na arquitetura - Por que falar sobre serverless?

Introduzindo a importância dos servidores

Como já diziam os mestres, "de meio começado, metade feito". Vamos iniciar nossa jornada com servidores utilizando Node. Antes de começarmos a programar e desenvolver, é importante entender a premissa. Por que falamos de servidores atualmente?

Vamos começar pela jornada. A primeira coisa a destacar é que a Cloud (nuvem) e certos provedores de Cloud revolucionaram a forma como gerenciamos servidores. Antes disso, tínhamos servidores on-premise (locais). Isso significa que, na empresa onde trabalhávamos, havia um servidor físico. Estávamos em contato direto com esse servidor, e às vezes até montávamos o servidor. Sabíamos qual era a memória, o HD, a velocidade do HD, a placa de rede, e até o IP de cabeça. Esse servidor estava fisicamente presente, e podíamos literalmente puxar uma cadeira, ligar um monitor e realizar qualquer tarefa nele.

Explorando a relação com servidores físicos

Existem várias histórias de apelidos interessantes para servidores. Muitas empresas davam nomes criativos, fazendo referências. Por exemplo, em uma empresa onde trabalhamos, havia um servidor chamado Enterprise, em referência à nave de Star Trek. Estávamos muito próximos desse servidor.

No entanto, havia um paradoxo. Tínhamos um hardware com, por exemplo, 16 GB de RAM, CPU X, Y, Z, disco e velocidade de disco, mas não utilizávamos 100% desses recursos o tempo todo. É como ter um cano para passar água, mas não utilizar sua capacidade máxima constantemente. Isso dependia de diversos fatores, como a hora do dia e os horários de pico do sistema. Por exemplo, um sistema de ponto teria picos de acesso pela manhã, na hora do almoço e na saída. Portanto, o uso era sazonal.

Comparando soluções para uso de recursos

Diante desse cenário, surge a questão: como resolver o problema da reserva improdutiva? Podemos comparar com a escolha entre almoçar em casa, assinar um plano de marmita ou pedir um delivery pontual. Às vezes, estamos sem tempo para cozinhar. Qual seria a melhor opção?

Se pensamos em controle, liberdade e personalização, é evidente que, quando cozinhamos em casa, temos tudo isso. Nós escolhemos quais ingredientes usar, de onde eles vêm, e, se não temos um ingrediente específico, podemos substituí-lo por outro. Às vezes, a receita pede cebola, mas, se não gostamos de cebola, não a colocamos. Assim, temos controle e liberdade total sobre o que estamos cozinhando.

Considerando alternativas para eficiência

Agora, se consideramos um cenário em que estamos trabalhando e com pouco tempo, nosso objetivo é simplesmente nos alimentar de forma razoavelmente saudável, sem recorrer a um fast food. Qual seria a melhor opção? Se não temos tempo para cozinhar, como podemos encontrar uma alternativa ou uma solução híbrida? Existem várias opções.

O servidor funciona de maneira semelhante. Temos diversas opções para escolher como hospedar nossa aplicação, e precisamos tomar uma decisão baseada em dados concretos. William Edwards Deming disse: "Sem dados, você é apenas uma pessoa qualquer com uma opinião." Isso é verdade. Sem dados para fundamentar nossas decisões, estamos apenas tentando adivinhar o que fazer.

Analisando a viabilidade do serverless

Quando falamos de serverless, a decisão deve ser muito consciente. Por que serverless é o melhor caminho? Precisamos começar analisando o consumo. Quando temos nossa infraestrutura, esperamos que ela seja estável e escalável. Ela entrega o que promete ou está sobrando recurso? Quando há um pico de acesso, a carga aumenta e escalamos? Escalamos o suficiente ou estamos desperdiçando recursos? E quando o uso está baixo? Quanto estamos gastando nesse período em que ninguém está usando nosso sistema? Lembrando do nosso sistema de ponto, provavelmente de madrugada ou à noite, se não houver um período de outubro, ninguém estará usando. Portanto, nosso consumo é zero.

Preparando para decisões baseadas em dados

Precisamos tomar decisões baseadas em dados. O que vamos discutir a seguir? Vamos começar a analisar quais dados devemos observar e como identificar o melhor caso de uso para uma arquitetura serverless. Já começamos a adicionar várias palavras ao nosso vocabulário tecnológico, como on-premise, cloud, serverless e consumo. Vamos entender quais dados devemos considerar ao tomar essa decisão.

Estou esperando vocês no próximo vídeo.

Serverless: o que muda na arquitetura - O que é uma arquitetura serverless?

Introduzindo o conceito de serverless

Nós já descrevemos como era o cenário na época em que tínhamos contato físico com o hardware do nosso servidor e começamos a migrar para um provedor de nuvem. Agora, vamos focar na parte de serverless. O que isso significa, afinal? Vamos começar com uma definição.

Serverless é um modelo de desenvolvimento de aplicações nativas em nuvem que permite às pessoas desenvolvedoras criar e executar aplicações sem se preocupar com o provisionamento ou gerenciamento de servidores e recursos de back-end. Ou seja, estamos delegando a manutenção do servidor para o nosso provedor. A ideia do serverless é "sem servidor", mas uma arquitetura serverless obviamente possui servidores. Precisamos de alguma máquina responsável por entregar as respostas ao serviço que recebemos.

Explorando a pirâmide de infraestrutura

Vamos começar a definir e empilhar esses conceitos que vimos até agora. Na base da pirâmide, temos os servidores on-premise. O que é on-premise? É o contato direto com o hardware do nosso servidor, onde temos controle absoluto. Isso vai escalando para cima. Temos a Infrastructure as a Service (IaaS), onde não temos mais um servidor físico e estamos alugando um pedaço de um servidor em algum lugar.

Subindo mais um degrau, temos a Platform as a Service (PaaS), um cenário em que não temos mais noção do que está acontecendo por trás. Pode ser um serviço como o Heroku, onde conectamos o GitHub e não sabemos o que está acontecendo com o servidor. Estamos usando apenas a plataforma. No topo, temos o Function as a Service (FaaS), que é o que estamos discutindo agora.

Comparando níveis de controle na pirâmide

Antes de prosseguir, uma menção honrosa ao Software as a Service (SaaS), que significa que não temos controle algum. Estamos usando um produto de prateleira, como o Salesforce. O Software as a Service também se encaixa nessa pirâmide.

Voltando à nossa análise, quanto mais subimos na pirâmide, menos controle temos sobre o hardware. No on-premise, temos controle total, podendo escolher a marca do pente de memória, o HD, a rotação do HD, e até o cabo que conecta o HD. Temos controle absoluto. À medida que subimos na pirâmide, perdemos esse controle. Quanto mais alto, menos controle sobre o hardware.

Detalhando a infraestrutura on-premise e IaaS

Na arquitetura on-premise, temos a infraestrutura física em nossas mãos, com controle total sobre o hardware, como fazer backup, recovery, e instalar o servidor, se necessário. Está tudo em nossas mãos para usarmos da forma que melhor atender aos nossos objetivos.

Ao dar um passo para cima, no Infrastructure as a Service, não temos mais nosso hardware. Temos um hardware compartilhado. Às vezes, alugamos uma instância na Amazon com CPU, memória e disco específicos. Isso não é um para um; é um pedaço de hardware compartilhado que utilizamos. No Infrastructure as a Service, temos esse hardware compartilhado.

Analisando PaaS e FaaS

Nós alocamos os recursos que desejamos. Pegamos o pedaço necessário e delegamos algum controle. Ainda mantemos um controle lógico sobre o que estamos fazendo, mas não precisamos mais interagir diretamente com o hardware. Não precisamos nos preocupar com isso, pois é exatamente esse serviço que estamos contratando. Contratamos para que alguém gerencie o datacenter e cuide da saúde dos servidores. Nossa preocupação é com uma camada mais lógica.

Quando utilizamos Platform as a Service (Plataforma como Serviço), estamos cada vez mais distantes do servidor. Por exemplo, com a Heroku ou a Ocean, basicamente pegamos nosso código do GitHub Action ou Jenkins e enviamos para o provedor. Tudo relacionado a backup e manutenção é um serviço. Estamos delegando a gestão completa da infraestrutura para essa plataforma, embora ainda façamos alguma alocação. Indicamos, por exemplo, qual hardware desejamos, o tamanho do container e coisas do tipo.

Explorando o Function as a Service

Quanto mais nos afastamos do on-premise (local), menos controle temos sobre o hardware. Até chegarmos ao foco principal, que é o Function as a Service (Função como Serviço). Queremos pegar um bloco de código e executá-lo sem nenhuma alocação prévia. Não queremos pré-alocar nada, delegamos tudo. Não queremos nem saber qual versão do sistema operacional está sendo usada, desde que seja compatível. Pegamos o trecho de código e executamos.

Delegamos todas as responsabilidades operacionais. Do que estamos falando exatamente? Falamos sobre o provisionamento das máquinas, a manutenção do sistema operacional e a gestão do ambiente. Tudo isso é delegado no Service, no Function as a Service. Além disso, o balanceamento de carga é delegado, não configuramos nada nesse sentido. Parte do monitoramento e segurança também é usada como serviço. Delegamos tudo, não queremos nos preocupar em implementar isso. Utilizamos o que está disponível, todos os serviços disponíveis para nós.

Compreendendo a efemeridade das funções

Podemos dizer que funções são efêmeras. O que significa efêmero? Vamos entender a etimologia da palavra. Efêmera é o feminino singular de efêmero, e seu sentido literal é algo que dura apenas um dia. O sentido figurado é de curta duração. Portanto, uma função é efêmera. Ela existe apenas durante o período em que é executada e depois não mais. Não há controle de estado para descontrolar o estado anterior. Ela é executada por aquele período e, em seguida, deixa de existir.

Nesse tipo de cenário, pagamos apenas pelo que usamos. Se não estamos usando, não estamos pagando. Se estamos usando muito, obviamente, pagamos mais. O paradoxo da alocação de recursos não existe aqui. Pagamos apenas pelo que utilizamos e consumimos. Não pagamos por uma função parada, por exemplo.

Concluindo a análise da pirâmide de infraestrutura

Agora que começamos a entender essa pirâmide da infraestrutura e as principais referências em relação ao controle, vamos dar mais um passo em nossa jornada. Estamos aguardando na sequência. Até lá.

Sobre o curso Node.js: desenvolvendo aplicações serverless na nuvem

O curso Node.js: desenvolvendo aplicações serverless na nuvem possui 195 minutos de vídeos, em um total de 42 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:

• Serverless: o que muda na arquitetura
• Entendendo o ecossistema AWS e o SAM
• Criando uma REST API
• Persistência e CRUD
• Upload de imagens