O que é Serverless?

Não tem servidor mesmo? Veremos!

latrova commited 1 ano, 11 meses ago
×

Antes de começar

Ao falarmos de serverless neste post acabamos entrando em outros assuntos como PaaS e microservices, é interessante conhecer um pouco sobre pra acompanhar.

O que você vai ver

  • Explicação sobre o que é serverless, vantagens e etc
  • Comparativo entre FaaS e PaaS
  • Como criar uma aplicação serverless com aws lambda e python3

Cadê o servidor?

Ao contrário do que o nome propõe, existe sim um servidor rodando se você prestar atenção.

Esse nome é usado para confundir identificar um modelo onde não é necessário se preocupar com quantidade de servidores, máquinas virtuais ou qualquer parte da escalabilidade. Todas essas preocupações ficam na mão do provedor do serviço, com a garantia de que sua aplicação executará e dará resposta em tempo hábil.

Devido a confusão que o nome traz, o termo FaaS também é usado para identificar esse tipo de serviço.

O provedor te entrega algo que escala dinamicamente por requisição, a proposta é focar no software, e esquecer o servidor.

Vos apresento FaaS

É uma plataforma que permite o desenvolvedor executar código em resposta a eventos, daí o nome Function as a Service. Você cria a função e determina qual evento vai invocar aquela função, podemos afirmar então que um FaaS é orientado a eventos.

Qual é o evento?

Entenda evento como algo que dispara a função. Como por exemplo uma requisição HTTP em determinado endpoint ou um timer.

Se você pensar em uma chamada HTTP (evento), cujo a função invocada retorna uma resposta em JSON, você acabou de imaginar uma API.

Porém esse não é o único tipo de evento possível, podemos também imaginar uma rotina que seja executada de 10 em 10 minutos, onde o evento que dispara a função seria o tempo (timer).

FaaS vs PaaS

A maior diferença do FaaS é na arquitetura, onde você quebra toda sua aplicação em pequenas funções que são responsáveis por executar uma determinada ação. Se novamente usarmos o exemplo da API, cada endpoint se torna um evento pra uma função diferente.

Essas funções são executadas por demanda, e diferente do PaaS, não ficam 24/7 em execução.

Em outras palavras:

Enquanto o PaaS requer que sua aplicação esteja constantemente em execução para poder funcionar apropriadamente, o provedor do FaaS é responsável por ao detectar um evento alocar os recursos pra sua função, executar a sua função, e desligar o servidor que executou sua função.

Esse processo é tão rápido que quando o usuário obtém o resultado, o servidor que deu a resposta já não existe mais. Mesmo que o PaaS também tentasse desligar e iniciar o servidor por demanda, não conseguiria alcançar a mesma velocidade que o FaaS.

Talvez você não tenha se dado conta, mas quando falamos em poupar recursos/reduzir funcionamento do servidor em tempo ocioso, também obtemos um impacto no custo.

Quando estamos num modelo PaaS, temos de pagar uma quantia para manter aquele servidor rodando no período, enquanto no modelo FaaS nós pagamos por quantidade de recursos alocados nos milésimos necessários para executar sua função, o que quer dizer se sua aplicação não for usada em um período, seu custo é 0.

Isso me lembra Microservices

Certo, certo, quando eu disse que:

A maior diferença do FaaS é na arquitetura, onde você quebra toda sua aplicação em pequenas funções que são responsáveis por executar uma determinada ação

Você deve ter lembrado de microservices. De fato, parece uma evolução, pois de aplicações monolíticas conseguimos chegar a microservices e agora parece que estamos indo rumo a funções. Porém as funções vão além e conseguem deixar as coisas ainda menores.

Enquanto um microservice poderia conter um pequeno grupo de funções, uma função é exatamente isso: Um único pedaço de código responsável por uma única ação.

No entanto nada impede de estas coisas coexistirem, um microservice pode utilizar um conjunto dessas funções livremente.

microservice calls functions

Enquanto microservice é uma arquitetura, FaaS é uma resposta a eventos que só é executado quando necessário.

Devo ir sempre de FaaS então?

Infelizmente não, nem tudo são flores. Se você conhece microservices, você sabe que em quantos mais pedaços você quebrar, mais complexo ficará.

Você deve estar ciente da dificuldade manutenção que você obtém ao trabalhar neste modelo. É muito fácil testar uma única função, mas é muito difícil criar testes de integração e manter todas as suas 258 funções funcionando em perfeita harmonia.

Para dificultar ainda mais o cenário, no momento não há ferramentas que deem suporte para monitorar todos os pequenos pedaços (funções) do sistema. Debugar também pode ser muito difícil, pois você passa a depender do provedor do serviço e das ferramentas que ele oferecer.

Hora da ação!

Controle - Leia como quiser
Vamos criar uma aplicação serverless agora mesmo! Vamos utilizar o Lambda da Amazon e o template em Python 3, mas você pode se aventurar e tentar usar um outro template enquanto segue o tutorial. Há outras opções como Node, F#, C#, Swift e etc.

Primeiro execute isto:

npm install -g serverless
mkdir serverless-python && cd serverless-python
serverless create -t aws-python3

Se tudo tiver dado certo, você receberá uma mensagem

Serverless: Successfully generated boilerplate for template: "aws-python3"

E você pode verificar isso usando o comando:

dir /b
ou ls

Vamos iniciar repositório e salvar o que fizemos até agora

git init .
git add .
git commit -m "Generated boilerplate"

Agora vamos seguir a recomendação que recebemos ao criar o projeto

NOTE: Please update the "service" property in serverless.yml with your service name

Vamos abrir nosso gerador de código incrível:

code .

Abra o arquivo serverless.yml. Você vai notar vários comentários bem explicativos que exemplificam algumas das possíveis opções que o Lambda oferece, bem como links para documentação. Porém deletaremos boa parte pra manter o arquivo limpo. No final ficou assim:

service: aws-python3 # NOTE: update this with your service name

provider:
  name: aws
  runtime: python3.6

functions:
  hello:
    handler: handler.hello

E vamos renomear o nome do service como sugerido

service: latrova-commits-serverless-py3-tutorial
...

E salvar

git commit -am "updated serverless.yml"

Agora iremos definir uma função posts que irá responder a um evento, e que será disparado através de uma chamada http.

serverless.yml

service: latrova-commits-serverless-py3-tutorial

provider:
  name: aws
  runtime: python3.6

functions:
  posts:
    handler: handler.posts
    events:
      - http:
          path: blog/posts
          method: get

handler.py

import json

def retrieve_posts():
    #Let's imagine that I made a SELECT from some db somewhere
    return [
        { "id": 1, "title": "Easy introduction to Redux", "publish_date": "2017-08-01" },
        { "id": 2, "title": "Serverless", "publish_date": "2017-08-11" },
    ]

def posts(event, context):
    posts = retrieve_posts()

    body = {
        "message": "Nice job! Your function executed successfully!",
        "data": posts
    }

    response = {
        "statusCode": 200,
        "body": json.dumps(body)
    }

    return response
git commit -am "Removed Hello function and added posts function"

Ótimo, agora é hora de publicar! Para isso vamos acessar o AWS e solicitar nossas credenciais. Se você ainda não criou sua conta, crie aqui.

Quando estiver no AWS console, precisaremos obter acesso para nossa aplicação! Vá para o IAM.

Em Create Individual IAM users, clique Manage users, e então Add user.

open IAM config

Dê o nome de usuário que mais fazer sentido pra você, e selecione Programmatic access.

set access

Clique Next: Permissions e Create group.

create group

Dê um nome ao grupo e procure por AWSLambdaFullAccess e AdministratorAccess.

select roles

Clique Next: Review e Create user.

Suas credenciais foram geradas! Clique em show na tabela.

create group

Tenha certeza de salvar isso em local seguro, você não conseguirá ver essas mesmas informações novamente.

Agora com você pode executar o seguinte comando:

Se desejar pode colar suas informações abaixo pra gerar o comando correto pra você, se não, pode copiar o comando e substituir manualmente.
serverless config credentials --provider aws --key YOUR_KEY --secret YOUR_SECRET

Se tudo correu bem até aqui, você verá a seguinte mensagem:

Serverless: Setting up AWS...
Serverless: Saving your AWS profile in "~/.aws/credentials"...
Serverless: Success! Your AWS access keys were stored under the "default" profile.

Agora, vamos lançar nossa aplicação!

serverless deploy

Se tudo tiver corrido bem, você verá algo como:

service: latrova-commits-serverless-py3-tutorial
stage: dev
region: us-east-1
api keys:
  None
endpoints:
  GET - https://ajy5vvu1n8.execute-api.us-east-1.amazonaws.com/dev/blog/posts
functions:
  posts: latrova-commits-serverless-py3-tutorial-dev-posts

É possível ver o código todo no GitHub.

Acesse o link e veja o resultado! Note como você obteve uma resposta rapida. Lembrando que antes de você acessar o link, o servidor estava desligado, ele te respondeu em bom tempo, e agora que você está lendo isso o servidor já deve ter desligado novamente :) .

Links interessantes

blog comments powered by Disqus