Você está na página 1de 33

Serverless Broker

Aluno: Sergio Torres Teixeira Filho


Orientador: Vinicius Cardoso Garcia
Coorientador: Ricardo Robson Mendes da Silva
Roteiro da Apresentação

1. Introdução ao Tema
2. Projeto
3. Experimentação e Resultados
4. Conclusão
1. Introdução ao Tema
Uso da Internet ao longo dos anos

Pew Research Center, internet use over time[1]


Tipos de Infraestrutura

On premise Cloud computing


Modelos de Cloud Computing

Short comparison: On premise vs. IaaS vs. PaaS vs. FaaS vs. SaaS[2]
Serverless e FaaS

● A arquitetura Serverless busca tornar transparente o uso de servidores,


terceirizando o provisionamento e alocação de recursos para o provedor.
● FaaS é uma implementação da arquitetura Serverless onde sua unidade
computacional são funções.
○ Cada função é uma unidade lógica independente
○ Stateless
○ Efêmera
○ Disparadas por Eventos
○ Escalonáveis
○ Gerenciado por um provedor
Aplicações Serverless

Traditional vs Serverless[3]
Provedores de Cloud Computing
Vendor lock-in

● Interfaces
● Runtimes
● Eventos
● SDKs
● Serviços Exclusivos
2. Projeto
Cloud Broker

Provedor A

serverless-agnostic

Provedor B
serverless-agnostic

● Foi implementado como um plugin para o Serverless Framework


● Desenvolvido em Typescript
● Faz uso de transpilações(source to source compilations) para adequar
aplicações Express.js para o formato aceito por cada provedor
● Foi desenvolvido para as plataformas AWS Lambda e Google Cloud Function
Arquitetura da Solução
Módulos Internos da Solução

● Compile Service
● Deploy Service
● Provider Service
● transforms
● Models
Arquitetura Interna
Configuração da Ferramenta
Uso da Ferramenta
● serverless compile: comando para executar compilação do projeto para o formato adequado ao
provedor.

● serverless agnosticDeploy: comando que executa implantação em cada provedor configurado.


Código para um provedor específico
3. Experimentação e Resultados
Goal Question Metric
Experimento

● O experimento realizado consistiu em portar múltiplas aplicações Express.js


para minha ferramenta, analisando possíveis limitações e medindo o esforço
através da métrica de refatorações necessárias.
● As aplicações utilizadas pelo experimento foram retiradas do repositório oficial
do framework Express.js, somando no total 26 aplicações.
● Os experimentos foram realizados pelo autor e todos utilizaram a mesma
configuração da ferramenta.
Resultados
Aplicação Resultado na Resultado na Número de
AWS GCP refatorações
auth Sim, porém instável Sim, porém instável 0
por uso de in memory por uso de in memory
sessions sessions

content-negotiation Sim Sim 0

cookie-sessions Sim, porém instável Sim, porém instável 0


por uso de in memory por uso de in memory
sessions sessions

cookies Sim Sim 0

downloads Sim Sim 0

ejs Sim Sim 0

error-pages Sim Sim 0

error Sim Sim 0

hello-world Sim Sim 0


Resultados
Aplicação Resultado na Resultado na Número de
AWS GCP refatorações
markdown Sim Sim 0

multi-router Sim Sim 0

multipart Sim Não, incompatibilidade 0


de biblioteca usada no
upload de arquivos

mvc Sim, porém instável Sim, porém instável 0


por uso de in memory por uso de in memory
sessions sessions

online Sim, Alterando Sim, Alterando 1


endereço do Redis endereço do Redis

params Sim Sim 0

resource Sim Sim 0

route-map Sim Sim 0

route-middleware Sim Sim 0


Resultados

Aplicação Resultado na Resultado na Número de


AWS GCP refatorações
route-separation Sim Sim 0

search Sim Sim 0

session Sim, porém instável Sim, porém instável 0


por uso de in memory por uso de in memory
sessions sessions

static-files Sim Sim 0

vhost Não, por fazer uso de Não, por fazer uso de -


virtual hosts virtual hosts

view-constructor Sim Sim 0

view-locals Sim Sim 0

web-service Sim Sim 0


Discussão

● Das 26 aplicações utilizadas no experimento, 20 foram migradas sem


apresentar nenhum erro ou limitação aparente.
● O esforço referente ao número de refatorações não foi relevante, segundo os
dados da experimentação.
● Aplicações Serverless tem algumas limitações específicas que outros tipos de
aplicação não tem e isto pode impactar na adequação de algumas aplicações.
4. Conclusão
Conclusão

● A ferramenta desenvolvida apresenta indícios de facilitar o desenvolvimento


de aplicações Serverless em ambientes possivelmente Multi-Cloud.
● A ferramenta permite adequação ao formato da interface de cada provedor e
permite sua implantação em cada um.
● A ferramenta é extensível para novos provedores.
● A ferramenta permite o desenvolvimento de aplicações Serverless utilizando
uma interface familiar para o desenvolvedor.
Possíveis Limitações

● Enviesamento dos resultados.


● Amostra limitada.
● Dependência do Serverless Framework.
● Compilação específica por provedor.
Trabalho futuros

● Expandir os provedores de Cloud aceitos para incluir Microsoft Azure e IBM


Cloud
● Desenvolver comandos de monitoramento para o plugin
● Adicionar mais eventos aos triggers aceitos
● Investigar possíveis problemas de compatibilidade e avisar ao desenvolvedor
Obrigado!
Referências
Referências

1. Pew Research Centre, Internet/Broadband Fact Sheet -


https://www.pewresearch.org/internet/fact-sheet/internet-broadband/.
2. On Premise vs. Serverless - https://customers-love-solutions.com/?p=784.
3. Serverless Architectures and Continuous Delivery -
https://www.gocd.org/2017/06/26/serverless-architecture-continuous-delivery/.

Você também pode gostar