You are on page 1of 24

Em direção a uma ferramenta para a realização de ​benchmarking 

de funções ​serverless ​em ambientes possivelmente ​multi-cloud 


Eduardo S. d. Moura​1 

Orientador por Vinicius C. Garcia 

Centro de Informática – Universidade Federal de Pernambuco (UFPE)​1 


Av. Jornalista Aníbal Fernandes, s/n - Cidade Universitária - Recife - PE 
esm7@cin.ufpe.br
Resumo.  O  objetivo  deste  trabalho  é  a  compreensão  e o aprimoramento do processo de 
benchmarking  de  funções  serverless  do  ponto  de  vista  de  engenheiros  de  software 
em  ambientes  possivelmente  multi-cloud.  Para  alcançar  este  objetivo,  foi feita uma 
análise  do  estado  da  arte,  para  mapear  quais  parâmetros  são  os  mais  relevantes 
para  se  realizar  esse  benchmarking,  e  quais  métricas  devem  ser  levadas  em 
consideração  ao  se  comparar seus resultados. A partir desse estudo, foi projetada e 
desenvolvida  uma  ferramenta  capaz  de  realizar  o  benchmarking  de  funções 
serverless  em  ambientes  possivelmente  multi-cloud,  e de consolidar seus resultados 
em  um  relatório,  de  forma  comparativa,  possibilitando-a  a  visualizar  os  dados  de 
performance  das  funções  testadas,  e  ajudando-a  a  ter  intuições  sobre  o 
comportamento  das  mesmas.  Além  disso,  também  foram  realizados  experimentos 
com  a  tal  ferramenta,  com  alguns  dos  casos  de  uso  mais  comuns  de  funções 
serverless,  que  por  sua  vez,  exercitam diversos recursos computacionais. Com base 
nesses  experimentos,  houve  a  coleta  de  resultados  para  o  levantamento  de 
discussões  acerca  da  ferramenta,  a  fim  de  validar  sua  viabilidade  e  mapear 
possíveis melhorias que poderão ser implementadas em trabalhos futuros. 
 
 
Palavras-chave​: S​erverless functions​, ​benchmarking​. 

1. Introdução 
Esta  Seção  tem  o  objetivo  de  fornecer  uma  visão  geral  acerca  do  trabalho,  apresentando  o 
contexto  e  as  motivações  que  levaram  ao  desenvolvimento  deste,  além  de  mapear  os 
principais  objetivos  a  serem  alcançados  com  o  seu  desdobramento  e  conclusão,  tanto  os 
gerais,  quanto  os  específicos.  E  ao  final,  é  possível  ter  um  panorama  do  que  será  tratado em 
cada uma das seguintes seções do trabalho. 

1.1 Contexto e Motivação 


Um  dos  fenômenos  que  mais  impactou  no  aumento  da  velocidade  da  troca  de  informação 
entre  indivíduos  na  era  moderna  com  certeza foi o uso e popularização da Internet. Tal se fez 
gradualmente,  com  a  invenção  do  telégrafo,  do  telefone,  e  por  último  do  computador,  que 
vem  provendo  capacidades  de  integrações  nunca  vistas  antes,  o  que  tornou  possível  a 
disseminação  desse  mecanismo  de  difusão de informação e meio de interação entre pessoas e 
sistemas, independente de região geográfica [1]. 
A  partir desse advento, algumas organizações enxergaram o potencial da rede, que em 
um  primeiro  momento,  consistia  em  sua  grande  maioria  de  sites  que  não  tinham  finalidades 
intrinsecamente  lucrativas,  para  começar  a  promover  seus  negócios  físicos  para  os  usuários 
da  internet.  Nessa  direção,  junto  com  melhoras  na  infraestrutura  da  rede,  e  com  seu  acesso 
cada  vez  mais  facilitado,  a  internet  começa  a  se  tornar  um  ponto  de  interesse  de  empresas  e 
empreendedores,  motivados  progressivamente  a  fazer  uso  da  mesma  para  se  alavancarem. 
Esse  movimento  foi  tão  grande  a  ponto  de  serviços  começarem  a  surgir  para  operar  apenas 
por meio da rede. 
Com  o  crescimento  dos  negócios  online,  as  empresas  começaram  a  investir  em 
infraestruturas  próprias,  para  poder  dar  suporte  a  suas  plataformas  digitais.  Nessa  época,  era 
muito  comum  as  organizações  gerenciarem  o  seu próprio parque de máquinas e ​data centers​, 
o  que gerava custos elevados, tanto referente à compra de novos equipamentos, à manutenção 
dos  mesmos.  Esse  tipo  de  abordagem  é  conhecida  como  aplicações  servidas  ​On-premise,​  
sendo  operadas  pelas  próprias  organizações.  Apesar  de  tecnicamente  prover  um  maior 
controle  de  observabilidade,  comparadas  com  aplicações  que  não  seguem  essa  abordagem, 
também implica em um maior risco de investimento em casos de falha de projeto [2]. 
Continuando  na  mesma  direção,  com  o  avanço  da  tecnologia,  aumento no número de 
pessoas  conectadas  na  internet,  muitos  sistemas  e  até  mesmo  negócios  foram  migrando  para 
plataformas  conectadas  na  rede,  e  dessa  forma,  em  considerável  parte  dos  casos,  crescendo 
sua  base  de  usuários.  Nesse  cenário  de  alta  competitividade,  os  sistemas  também  crescem  à 
medida  que  novas  funcionalidades  são  demandadas,  e  assim,  tornando  cada  vez  mais 
complexo o processo de desenvolvimento desses. 
Na  tentativa  de  amenizar  os  efeitos  do  crescimento  dos  sistemas,  em  questões  de 
agilidade  na  entrega  de  novas  funcionalidades,  e  até  mesmo em termos de escalabilidade das 
aplicações,  vários  estudos  foram  desenvolvidos  nessa mesma linha. Uma corrente afirma que 
para  alguns  casos,  faz  sentido  a  fragmentação  da  aplicação  em  partes  menores,  capazes  de 
serem  entregues,  escaladas  e  testadas  de  forma  independente, com cada uma delas possuindo 
apenas uma responsabilidade [3]. 
Nessa  ótica,  um  das  arquiteturas  de  sistema  distribuído  que  surgem,  impulsionadas 
pelo  advento  da  ​Cloud  Computing​,  foi  a  Arquitetura  ​Serverless​,  que  incorpora  serviços  de 
“​Backend  as  a  Service​”  (BaaS)  e  agrega  códigos  que  são  rodados  em  contêineres  efêmeros 
numa  plataforma  de  “​Function  as  a  Service​”  (FaaS),  tendo  como  principais  objetivos  a 
redução de custos e de complexidade [4]. 
Nesse  contexto,  vários  provedores  de nuvem como ​Amazon Web Services [5], ​Google 
Cloud  Platform  [6]  e  ​Microsoft  Azure  [7],  lançaram  suas  próprias  soluções  de  funções 
serverless,  respectivamente  as  ​AWS  Lambdas  [8],  as  ​Google  Cloud  Functions  [9]  e  as ​Azure 
Functions​ [10]. 
Pelo  fato  desse  paradigma  ser  consideravelmente  novo,  e  pelas  suas  implementações 
nessas  plataformas  serem  recentes,  ainda  é  uma  atividade  pouco  consolidada  a  comparação 
de  performance  entre  essas  funções,  agravada  pelo  fato  de  cada  provedor  disponibilizar  sua 
própria  implementação  de  serverless.  Dessa  forma,  surge  assim  a  necessidade  do 
entendimento  da  prática  de  ​benchmarking de funções serverless, para que assim seja possível 
um aprimoramento nesse processo. 

1.2 Objetivos 
O  objetivo  principal  deste  trabalho é compreender e o aprimorar o processo de ​benchmarking 
de  funções  ​serverless  do  ponto  de  vista  de  engenheiros  de  software  em  ambientes 
possivelmente ​multi-cloud​. Para se alcançar este objetivo, faz-se necessário: 
● Identificar  quais  os  parâmetros  mais  importantes  em  testes  de  performance  sobre 
essas funções; 
● Identificar  quais  são  as  métricas  mais  relevantes  no  processo  de  comparação  dos 
resultados desses testes de performance; 
● Averiguar  se  as  ferramentas  existentes  possibilitam  a  comparação  de  funções 
implantadas em provedores distintos. 

1.3 Estruturação do Trabalho 


Este trabalho está estruturado da seguinte forma:  
● Seção 2​: apresenta conceitos; 
● Seção  3​:  explica  a  metodologia  do  trabalho,  apresentando  a  sua  meta  e  as  questões 
que serviram de guia para o desenvolvimento do mesmo;  
● Seção  4​:  expõe  a  análise  do  estado  da  arte  acerca  do  tema  do  trabalho,  tentando 
responder as questões levantadas; 
● Seção  5​:  apresenta  a  ferramenta  que  foi  desenvolvida  com  base  na  avaliação  feita do 
estado da arte;  
● Seção  6​:  apresenta  os  experimentos  realizados  utilizando  a  ferramenta,  sob  funções 
serverless com casos de uso comuns; 
● Seção  7​:  apresenta  os  resultados  dos  experimentos  e  inicia  uma  discussão  acerca dos 
mesmos; 
● Seção  8​:  levanta  a  conclusão  do  trabalho,  avaliando  o  atingimento  da  meta  e 
viabilidade da ferramenta proposta; 
● Seção  9​:  aponta  pontos  que  podem  ser  atacados  em  trabalhos  futuros,  tanto  sobre 
limitações  enxergadas  no  próprio  trabalho,  quanto  acerca  de  funcionalidades  novas 
que podem ser desenvolvidas. 

2. Conceitos fundamentais 
Esta  Seção  apresenta  e  explica  os  principais  tópicos  que  o  trabalho  aborda.  Por  meio  deles, 
será  possível  ter  um contexto para uma efetiva compreensão da ferramenta proposta na Seção 
5. 

2.1 Cloud Computing 


Segundo  Wang  [11],  Computação  em  Nuvem  é  um  conjunto  de  serviços  habilitados  para  a 
rede, que provêm infraestruturas computacionais sobre demanda, de forma escalável, com um 
uma  qualidade  de  serviço  garantida,  normalmente  personalizadas  e  pouco  custosas, podendo 
ser  acessadas  de  uma  forma  simples.  Pode-se  então  concluir  que  uma  das  principais 
vantagens  desse  modelo  de computação é a abstração da infraestrutura, que em outro cenário, 
deveria  ser  administrada e mantida pela própria organização, o que provavelmente acarretaria 
em custos mais altos do que a contratação de um provedor cloud especializado. 
O  NIST  (​National  Institute  of Standards and Technology​) afirma que o esse modelo é 
constituído de cinco características fundamentais [12]: 
● O  consumidor  pode  provisionar  recursos  computacionais  que  necessitar,  sem 
interferência humana por parte do provedor do serviço; 
● Os  recursos  provisionados  devem  ser  acessíveis  ao  consumidor  por  meio  de 
mecanismos convencionais, como por exemplo, aparelhos celulares, ​laptops​ e ​tablets;​  
● Os  recursos  de  computação  do  provedor  são  agrupados  para  atender  a  vários 
consumidores,  com  diferentes  recursos  físicos  e  virtuais  dinamicamente  atribuídos  e 
reatribuídos de acordo com a demanda do consumidor; 
● Os  recursos  devem  ter  a  possibilidade  de  serem  elasticamente  escalados,  ou  seja, 
escalados  rapidamente,  tanto  aumentando  quanto  diminuindo  suas  capacidades  de 
forma dinâmica; 
● Sistemas  de  nuvem  devem  automaticamente  controlar  e  otimizar  seus  recursos 
utilizando métricas, para diferentes tipos de serviço.  
Além  disso,  o  NIST  constata  que  o  Computação  em  Nuvem  é  apresentado  em  três 
diferentes modelos de serviço [12], que serão explicados logo em seguida. 

2.1.1 Software as a Service (SaaS) 


O  modelo  de  Software  como  um  Serviço  é  aquele  no  qual  os  clientes  são  possibilitados  de 
usar  e  ou  alugar  aplicações  licenciadas  de  provedores  sem  a  necessidade  de  instalar  em seus 
próprios  dispositivos,  acessando-as  por  algum  tipo  de  interface,  como  por  exemplo  um 
navegador  de  internet,  ou  uma  API  Rest  [13].  Dessa  forma,  esse  modelo  traz  algumas 
vantagens,  como  um  maior  controle  de  atualizações  e  versões  por  parte  do  provedor  do 
software  e  redução  no  custo  de  licenciamento  por  parte  dos  clientes,  que  terão  que  se 
preocupar  bem  menos  em  ter  uma  própria  infraestrutura  para  a  disponibilização  desse 
software em específico. 

2.1.2 Platform as a Service (PaaS) 


O  modelo  de  Plataforma  como  um  Serviço  é  aquele  que  o  cliente  não busca apenas o uso de 
um  software,  mas  sim  busca  uma  solução  para  prover  o  desenvolvimento  de  aplicações  por 
completo,  ao  mesmo  tempo a hospedando e a entregando como um serviço de nuvem [14], se 
situando  uma  camada  abaixo  do  SaaS.  Dessa  forma,  o  consumidor  não  gerencia  a 
infraestrutura  cloud  que  roda  por  baixo  (a  exemplo  de  rede,  servidores,  armazenamento  e 
sistemas  operacionais),  mas  possui  o  controle  sobre  suas  aplicações  e  possivelmente  de 
algumas configurações do ambiente de hospedagem [12]. 

2.1.3 Infrastructure as a Service (IaaS) 


A  Infraestrutura  como  um  Serviço é o modelo que está situado na camada com o menor nível 
de  abstração  que  provedores  de  nuvem  fornecem,  a  ponto  de  o  mesmo  ocasionalmente  ser 
referido  como  HaaS  (​Hardware  as  a  Service)​ .  Segundo  ARORA  et  al,  esse  modelo  é 
observado  quando uma organização terceiriza os equipamentos que utiliza para dar suporte às 
suas  operações,  sendo  que  os mesmos são mantidos pelo provedor do serviço [15]. A grande 
diferença  é  que  o  cliente  tem controle também sobre recursos que são abstraídos em camadas 
superiores, como os sistemas operacionais e armazenamento. 
É  importante  notar  que  essa  Seção,  assim  como  as  imediatamente  anteriores,  foi  de 
fundamental  importância para se ter um contexto, e se entender em que camada que se situam 
tais  funções  serverless,  que  serão  bastante abordadas durante todo o trabalho, e explicadas de 
forma mais específica na próxima Seção. 

2.2 Serverless Computing 


Computação  Serverless  é  um  novo  paradigma  que  vem  ganhando  bastante  tração  cada  vez 
mais  em  sistemas  que  são  hospedados  em  nuvem,  em  decorrência  de  uma  grande  mudança 
em  arquitetura  de  aplicações,  em  considerável  parte  empresariais,  com  a  utilização  de 
microserviços e contêineres [16]. 
Este  é  baseado num novo modelo de computação em nuvem chamado FaaS (​Function 
as  a  Service​),  que faz um uso direto da camada de PaaS (vista na Seção 2.1.2), no qual utiliza 
funções  efêmeras  (que  não  guardam  estado)  disparadas  por  eventos,  sendo  executadas  em 
contêineres  gerenciados  pelos  provedores  de  cloud  [17].  Esse  modelo  permite  que  os 
desenvolvedores  criem  e  hospedem  aplicações  dinamicamente  escaladas  sob  demanda,  que 
performam  uma  determinada  função  [18].  Dessa  maneira,  não  haverá  um  servidor  que  vai 
ficar  sempre  no  ar,  mesmo  que  não  hajam  requisições  para  o  mesmo  atender.  Nesse  caso, 
haverá  contêineres  que  apenas  estão  ativos  enquanto  a  função  que  eles  contém  estiver 
rodando, assim, podendo trazer ganhos financeiros tanto por parte do cliente, quanto por parte 
do provedor, pela economia no consumo de recursos. 
No  intuito  de otimizar ainda mais o uso de recursos, em implementações de serverless 
em  algumas  plataformas,  existem  algumas  técnicas  de caching e reuso de contêineres para os 
casos  em  que  a  aplicação  é  acessada  sucessivamente  [19].  Esse  efeito  é  perceptível  quando 
uma  função  passa  algum  tempo  sem  ser  invocada.  Na  próxima  vez  que  ela  for  chamada, 
haverá  uma  latência  um  pouco  maior  na  primeira  requisição,  por causa do tempo de carregar 
o contêiner, sendo nomeado como o efeito de “​cold-start”​ [20]. 
As  principais  implementações  de  funções  serverless  existentes,  AWS  Lambda  [8], 
IBM  Cloud  Functions  [21],  Google  Cloud  Functions  [9],  e  Microsoft  Azure  Functions  [10], 
oferecem  modelos  de  programação  simplificados  e  muito  fáceis  de  serem  configurados  para 
executar as funções. 
É  importante  também  de  se  destacar  que,  como outros cenários na computação, o uso 
de  funções  ​serverless  pode  não  ser  o  mais  efetivo  em  todas  as  situações.  Casos  em  que 
fazem-se  necessários  um  maior  controle  sobre  a  observabilidade  da  aplicação,  em  que  uma 
baixa  latência  é  uma  necessidade  crítica,  e  em  casos  que  não  se  pode  ter  uma  grande 
dependência  com  o  provedor  cloud, não são recomendados para o uso de FaaS. Ao passo que 
cenários  onde  uma  aplicação  fique  latente  uma  significante  parte  do  seu  tempo  e  onde  a 
organização  não  se  tenha  expertise  em  manutenção  de  servidores,  o  uso  de  ​serverless  pode 
ser bastante recomendado [49]. 

2.3 Testes de software 


Como  o  trabalho  relacionado  a  testes  de  carga  em  funções  serverless,  é  de  fundamental 
importância pelo menos o entendimento dos conceitos básicos de teste de software. 
Teste  de  software  é  definido  por  qualquer  atividade  que visa avaliar as características 
de  um  sistema  ou  mesmo  de  um  simples  programa,  sendo  um  indicador  da  qualidade  do 
software  [22].  Além  disso,  o  ato  de  testar  deve  fazer  parte  do  processo  de  engenharia  de 
software,  utilizando  e  mantendo  o  código  de  teste,  melhorando  assim  a qualidade do sistema 
sob teste [23]. 
Testar  o software se torna cada vez mais importante, ao mesmo tempo que sistemas se 
tornam  cada  vez  mais  complexos,  no  objetivo  de  avaliar  se  alguns  de  seus  critérios  de 
aceitação  estão  sendo  atingidos  e  descobrir problemas, já que o código muitas vezes é escrito 
por  humanos,  sendo  assim  suscetíveis  a  erro,  especialmente  num  ambiente  regido 
majoritariamente por sistemas controlados por software [24]. 
De  acordo  com  Jorgensen  [25],  testes  são  derivados  de  requisitos  e  especificações, 
artefatos  de  design  ou  de  código  fonte.  Dessa  maneira,  cada  nível  de  teste  deve  estar  lado  a 
lado com cada atividade de desenvolvimento. Esses níveis são: 
● Testes de Aceitação​: referentes aos requisitos do software; 
● Testes de Sistema​: referentes ao desenho arquitetural do software; 
● Testes de Integração​: referentes ao desenho dos subsistemas; 
● Testes de Unidade​: referentes à implementação do software. 

2.3.1 Testes de Carga 


Testes  de  carga,  também  conhecidos  como  testes  de  performance  é  uma  categoria  de  testes 
não  funcionais,  ou  seja,  que  verificam  o  comportamento  de  determinado  sistema,  quando  o 
mesmo  está  sob  um  volume  considerável  de  carga,  a  fim  de  se  ter  um  maior  entendimento 
sobre aspectos de disponibilidade e estabilidade do sistema [26]. 
Um  teste  de  performance  normalmente  simula  uma  carga  grande  de  usuários 
simultaneamente,  realizando  diversas  ações  e  normalmente  transferindo  um  grande  volume 
de  dados.  Por  essa  razão,  esse  tipo  de  teste  é  naturalmente  um  dos  mais  custosos,  tanto  em 
questão de recursos computacionais, quanto no fator tempo, que pode levar até dias. 

2.4 ​Benchmarking 
Para  poder  se  comparar  a  performance  as  funções  ​serverless​,  a  fim  de  avaliar  seus 
comportamentos  mediante  determinadas  situações,  torna-se  necessário  a  realização  do 
processo de ​benchmarking​ sobre as mesmas. 
O  processo  de  ​benchmarking  é  definido pela quantificação dos níveis de performance 
entre  diferentes  participantes  a  partir  de  ​métricas​,  para  assim  identificar  suas  diferenças  de 
performance,  a  fim  de  se  mapear  quais  deles  tiveram  os  melhores  resultados. Dessa forma, é 
possível  quantificar  potenciais  melhorias  para  os  participantes  que  não  tiveram  os  melhores 
resultados, visando alcançar o nível dos melhores [50]. 
No  objetivo  de  se  dinamizar  o  cenário  no  qual  todos  os  participantes  de  um 
benchmarking  irão  se  submeter,  são definidos ​parâmetros​. Dessa maneira torna-se factível a 
comparação  dessas  métricas  de  performance  advindas  de  diferentes  configurações, provendo 
a possibilidade de uma definição de cenário específica pelo requisitante do ​benchmarking.​  

3. Metodologia do Trabalho 
Para  esse  trabalho,  foi  adotada  a  abordagem  do  GQM  (​Goal  Question  Metrics​)  [47]  como 
metodologia.  A  Figura  1  ilustra  a  meta  que  se  busca  alcançar  na  conclusão  do  trabalho,  as 
questões  que  precisam  ser  levadas  em  conta  e  respondidas  para  que  a  meta  seja  cumprida,  e 
por fim, as métricas que devem ser consideradas para se responder essas perguntas: 
 

Figura 1. Diagrama representando o modelo GQM utilizado

4. Análise do Estado da Arte 


 

4.1 Método 
Para  a  análise do estado da arte, foram utilizados os principais portais científicos, em especial 
o  IEEE  [27],  ACM  [28]  e  Springer  [29],  e  também  portais  agregadores,  como  o  Google 
Acadêmico [30] para a busca de trabalhos e artigos relacionados. 
Como strings de busca, foram empregadas: 
Tabela 1. Palavras-chaves utilizadas para compor a string de busca 

Serverless Functions  Benchmarking  Tool  Multi-cloud 


FaaS  Load Testing  Techniques  Heterogeneous Cloud 
Function as a Service 

4.2 Resultados 
Com  base  na  pesquisa,  foi  possível  observar  que  a  literatura  acerca  de  benchmarking  de 
funções  serverless  em  geral  não  é  muito  extensa,  em  decorrência  do  fato  de  FaaS  ser  um 
modelo  de  computação  cloud  consideravelmente  novo.  Para  se  ter  ideia,  a  primeira  das 
plataformas  mais  bem  sucedidas  desse  tal  modelo foi apenas lançada em 2014, pela AWS, as 
chamadas  Lambda  Functions  [31].  Contribuindo  também  para a análise desse fato, também é 
possível  constatar  que  o  framework  mais  conhecido  para  a  utilização  dessas  funções,  o 
Serverless Framework, teve sua versão 1.0.0 liberada em 2016 [32]. 
4.2.1 Parâmetros Mais Utilizados 
Durante  a  fase  de  pesquisa  do  trabalho,  para  entender  melhor  o  uso  de  testes  de  carga  em 
funções  serverless,  foi  de  fundamental  importância  determinar  quais  são  os  parâmetros  mais 
relevantes  na  configuração  desses  testes.  Para  apontar  os mesmos, foi utilizado como critério 
a  quantidade  de  vezes  que  foram  citados  e/ou  utilizados  em  outras  ferramentas  que  se 
propõem a realizar esse tal benchmarking. 
Em  primeira  análise,  fácil  perceber  que  o  parâmetro  mais  utilizado  é  o  número  de 
requisições,  o  que  faz  bastante  sentido  ao  se levar em consideração a natureza de um teste de 
carga  inserido  num  contexto  de  requisições  HTTP.  É  possível  constatar  que  todos  os  artigos 
analisados  utilizam  o  número  de  requisições  como  o  parâmetro  de  configuração  principal, 
dando base ao processo de benchmarking [32, 33, 34, 35, 36, 37, 38]. 
Em  segundo  lugar  no  ranking,  vem o número de requisições concorrentes, que simula 
o  comportamento  de  múltiplos  clientes  realizando  requisições  simultaneamente.  Apesar  de 
ser  menos  presente nos trabalhos de referência [36, 38], tem um grande impacto nas métricas, 
e  torna  os  casos  de  teste  muito  mais  fiéis  em  vários  contextos  do  cotidiano  onde  as  funções 
são aplicadas. 

4.2.2 Métricas Mais Utilizadas 


Durante  o  processo  de  análise  do  estado  da  arte,  foi  possível  constatar  que  em  todos  os 
trabalhos  considerados,  tinham  como  a  base  para  todas  as  métricas, dois fatores associados a 
uma requisição [32, 33, 34, 35, 36, 37, 38], sendo eles: 
● Latência na resposta da requisição 
● Sucesso na requisição 
A  partir  desses  dois  fatores,  é  possível  derivar  outros,  que  tem  a  função de facilitar o 
entendimento  do  comportamento  das  funções  testadas,  de  uma  forma  mais  holística,  sem  a 
necessidade  de  ficar  calculando  o  agregado  manualmente  a  partir  de  cada  requisição.  Essas 
métricas normalmente se encontram no formato de: 
● Número de requisições por segundo 
● Latência média das requisições 
● Taxa de sucesso 
● P95  (​ nesse  escopo,  representa  que  95%  das  requisições  tiveram  uma  latência  de 
resposta menor que o tempo apontado pela métrica) [48] 
● P99 [​ 48] 

4.2.3 Visualização dos Resultados dos Testes 


Em  relação  à  visualização  dos  resultados  dos  testes,  poucas  ferramentas  apresentam  alguma 
solução, principalmente quando se trata de alguma interface gráfica que apoie essa análise. 
A  solução  que  se  mostra  mais  comum [34, 37], é a de agregar os resultados dos testes 
numa  base  de  dados  em  série  temporal  ,  como  o  ​InfluxDB  ​[45],  e  por  meio  dele  conectar 
ferramentas  de visualização gráfica, como o ​Grafana [46], permitindo a observação em séries 
temporais. 
4.2.4 Capacidade de Testes Multi-cloud 
Nesse  contexto  de  benchmarking  de  funções  serverless,  um  dos  principais  pontos  de 
comparação  é  a  performance  das  funções  implantadas  em  diferentes  provedores  cloud, 
principalmente  entre  os  três  mais  conhecidos  (AWS,  GCP,  Azure). Dessa forma, por padrão, 
os  trabalhos  que  surgem  com  esse  tema  [32,  33,  34,  35,  36,  37,  38],  focam  exatamente  em 
testes  entre  provedores  diferente,  com  um  conjunto  de  funções  limitadas  e  predefinidas, 
apenas  focando  em  fazer  seu  benchmarking  como  sua  contribuição,  e  não  oferecendo 
propostas  de  ferramentas  com  utilidade  no  dia  a  dia  de  um  engenheiro  de  software,  mas sim 
algo pontual. 

5. Proposta de Ferramenta 
A  ​load-donkey ​(disponibilizada conforme o explícito na Seção 5.2) é uma ferramenta que foi 
desenvolvida  com  o  propósito  de  gerar  relatórios  comparativos  a  partir  dos  resultados  de 
testes  de  carga  configuráveis,  realizados  sobre  funções  serverless,  que  por  sua  vez  podem 
estar implantadas em provedores cloud distintos. 
Essa  ferramenta  visa  facilitar  o  processo  de  benchmarking  nesse  modelo  FaaS, 
ajudando  principalmente  engenheiros  de  software  na  visualização,  e  dessa  forma  apoiando o 
surgimento de ​insights​ sobre o comportamento dessa funções sob teste. 

5.1 Arquitetura 
A  load-donkey  foi  desenvolvida  numa  arquitetura  com  a  necessidade  de  facilidade  de 
extensão  em  mente.  Para  tal,  a  mesma  foi  implementada  em  dois  principais  pacotes,  sendo 
eles o ​load-donkey-core​ e o ​load-donkey-cli​ como é possível visualizar na Figura 2. 

Figura 2. Representação das camadas da ferramenta


Com  o  sistema  estruturado  dessa  maneira,  é  possível  a  implementação  de  diferentes 
tipos  pacotes  de  apresentação,  que  irão  fazer  reuso  do  pacote  no  qual  a  lógica  está  presente, 
tendo  assim,  pouco  o  acoplamento  entre  os  módulos  e  tornando  a  aplicação 
consideravelmente mais extensível. 
5.1.1 load-donkey-cli 
O  pacote  load-donkey-cli,  como  citado  anteriormente,  funciona  apenas  como  camada  de 
apresentação, ou seja, torna possível a interação do usuário com o sistema. 
Para  se  instalar  a  ferramenta,  basta  executar  a  seguinte  linha  de  comando  num 
terminal: 
bash install-cli

E para se utilizar a mesma, basta utilizar a seguinte linha de comando num terminal: 
load-donkey /path/to/specfile

Ao  final  da  execução,  será  gerado  um  diretório  chamado  ​load-donkey-reports  na 
pasta  ​home  do  usuário.  Dentro  dele, constará um os arquivos de report, com a extensão ​html​, 
contendo  um  relatório  comparando  os  resultados  do  benchmark  que  acabou  de  ser 
performado. 
5.1.1.1 Specfile 
O  ​Specfile  é  um  arquivo  no  formato  ​YAML​,  utilizado  pelo  load-donkey-cli  para  descrever  a 
suíte  de  testes  de  carga  que  devem  ser  executados.  Para  facilitar  o  entendimento,  é  possível 
observar um exemplo de Specfile a seguir: 
testEngine: ab
functions:
- address: http://host-aws.com
provider: aws
- address: http://host-gcp.com
provider: gcp
- address: http://host-azure.com
provider: azure
request:
method: POST
contentType: application/json
headers:
- key: Authorization
value: 123
queryParameters:
- key: pageSize
value: 25
bodyFile: /path/to/file/containing/body
parameters:
requestCount: 10000
concurrencyCount: 100 
O  mesmo  utiliza  os  parâmetros  apontados  como  os  mais  relevantes  na  Seção  4.2.1 
(Número  de  requisições  e  Número  de  requisições  concorrentes),  assim  como  outros  campos 
que  são  usados  para  descrever  a requisição que vai ser disparada, os endereços das funções, e 
qual o motor de testes que deve ser utilizado. 
5.1.1.2 Report 
O  ​Report  é  um  arquivo  html  que  consolida  as  métricas  dos  resultados  dos  testes  de 
performance  executados  sobre  as  funções  definidas.  Ele  é gerado de forma dinâmica, a partir 
dos resultados fornecidos. Atualmente ele dispõe as seguintes métricas: 
● Total  Time  (in  seconds)​:  tempo  total  que  se  levou  para  realizar  os  testes  sobre  uma 
função; 
● Success Count​: quantidade de requisições que retornaram resposta; 
● Fail Count:​ quantidade de requisições que não retornaram resposta; 
● Requests Per Second:​ quantidade média de requisições por segundo; 
● Mean  Time  Per  Request  (in  milliseconds)​:  tempo  médio  por  requisição  em 
milisegundos; 
● P95  (in  milliseconds):​   representa  que  95%  das  requisições  foram  completas  em 
menos de X milisegundos; 
● P99  (in  milliseconds):​   representa  que  99%  das  requisições  foram  completas  em 
menos de X milisegundos; 
● Longest  Request  (in  milliseconds):​   tempo  de  resposta  mais  longo  dentre  todas  as 
requisições em milisegundos. 
Um exemplo de métrica apresentada no report é apresentada na Figura 3: 
 

Figura 3. Métrica representando o tempo médio por requisição 


É  possível  verificar  que  para  cada  métrica  apresentada  no  Report,  seus  dados  estarão 
dispostos  em  forma  de  gráfico  de  barra,  no  qual  seu eixo Y representa o valor numérico para 
a  determinada  métrica,  relacionando-se  com  cada  provedor  em  que  a  função  foi  testada, 
representando as variáveis categóricas logo abaixo de cada barra. 
5.1.2 load-donkey-core 
O  módulo  load-donkey-core  é  o  responsável  por  receber  as  especificações  dos  testes  de 
performance,  e  assim  executá-los  com  essas  configurações.  Por  fim,  retornar  ao  requisitante 
os resultados consolidados de benchmarking. 
A estrutura deste módulo está disponibilizada conforme apresentado na Figura 4: 

Figura 4. Diagrama representando os módulos do load-donkey-core 


É  possível  então  enxergar  que  o  módulo  ​LoadTester  é  o  responsável  por  receber  as 
especificações  dos  testes  que  devem  ser  realizados,  delegar  para  o  TestEngine  (explicado 
detalhadamente  na  Seção  5.1.2.1)  realizar  os  testes,  e  por  fim  devolver  o  resultado  para  o 
requisitante. 
5.1.2.1 TestEngine 
TestEngine  é  o  módulo  que  envolve  o  motor  de  testes  que  de  fato  vai  realizar  o 
benchmarking.  Ele  é composto pelas interfaces com as TestEngines em si, como por exemplo 
o ​Apache AB​ [39], e por dois outros componentes, o ​Decider​ e o ​ResultParser​. 
O  ​Decider  é  o  componente  responsável  por  interpretar  as  configurações  do  teste  que 
foram  passadas  e  decidir  qual  motor  de  testes  utilizar.  No  estado  atual  da  ferramenta,  é 
possível  a  utilização  de  apenas  um  motor,  o  anteriormente  citado,  ​Apache  AB,​   que  foi 
escolhida por ser uma solução gratuita e já consolidada nesse escopo. 
Já  o  ResultParser,  é  responsável  por  interpretar  o  resultado  retornado  pelo  motor  de 
testes  e  estruturá-lo  em  um  formato  genérico,  possibilitando  que  o  consumidor  do  mesmo, 
consiga  montar  suas  visualizações  de  forma  totalmente  dinâmica  a  partir  de 
TestEngineResultConfigs​.  No caso da TestEngine implementada para se fazer interface com 
o Apache AB, foram utilizadas ​regular expressions​ para a interpretação de seus resultados.  
É  possível  conferir  um  exemplo  de  métrica  (tempo  médio  por  requisição,  a  mesma 
utilizada na Figura 4) mapeado no ​ApacheABResultConfigs​ logo a seguir: 
{
title: 'Mean Time Per Request (in milliseconds)',
key: 'meanTimePerRequest',
regex: /Time per request:\s*(\d+\.\d+) \[ms] \(mean\)/
}

Tal  módulo  foi  construído  desta  forma  para  se  adequar  ao  princípio  ​Open-Closed  do 
SOLID  (conjunto  de  princípios  ajudam  a  tornar  mais  fácil  a  manutenção  e  extensão  do 
código)  [40],  dessa  forma,  fazendo  com  que  a  ferramenta  seja  facilmente  estendida,  sem 
afetar  o  funcionamento  do  que  já  foi  previamente  implementado.  Nessa  ótica,  se  torna  uma 
atividade  relativamente  trivial  a  implementação  de  outras  interfaces  com  outros  motores  de 
teste, como o ​Loadtest​[41] e o ​Artillery​ [42]. 

5.2 Disponibilização da Ferramenta 


A  disponibilização  da  ferramenta  foi  feita  em  um  único  repositório  do  ​GitHub,​  sob a licença 
MIT​, de possível acesso pelo seguinte link: ​https://github.com/eduardosm7/load-donkey​. 

6. Experimentos com Diferentes Casos de Uso 


Já  possuindo  um  prévio  contexto  da  load-donkey,  e  compreendendo  o  seu  funcionamento 
apresentado  na  Seção  anterior,  a  atual  se  propõe  a  realizar  alguns  experimentos  com  a 
ferramenta,  utilizando-se  de  alguns  exemplos  de  casos  de  uso  de  funções  serverless, 
priorizando os que exercitam diferentes recursos computacionais. 
Devido ao fato de essa ferramenta já ser uma ferramenta que se propõe a realização de 
benchmarking​,  e  de  não  ser  comum  o  ​benchmarking  desse  tipo  de  ferramenta,  os  trabalhos 
utilizados  como  referência  [32,  33,  34,  35,  36,  37, 38] não disponibilizam esses dados acerca 
de suas ferramentas.  
Dessa  maneira  a  avaliação  da  viabilidade  da  load-donkey  será  feita  levando  em 
consideração  a  sua  capacidade  de  configuração  diferentes  cenários  de  teste,  de  apresentação 
das  métricas  de  performance  das  funções  de  modo  a  tornar  possível  a  identificação  das 
funções  que  tiveram  melhores  resultados  e  assim  completando  o  processo  de  ​benchmarking 
(definido na Seção 2.4). 
Dessa  forma,  busca-se  abranger  vários  cenários  que  usam  esses  mesmos  recursos, 
para  que  assim,  seja  possível  analisar  não  apenas  como  se  a  ferramenta  se  comporta,  mas 
também como as funções reagem ao serem testadas pela mesma. 

6.1 Processamento de Imagem 


Para  o  primeiro  conjunto  de  experimentos,  foi  decidido  realizá-lo  utilizando  funções 
serverless que se propõem a realizar um processamento de imagens. No caso abordado, foram 
implantadas  três  funções,  uma  em  cada  provedor  cloud, sendo eles AWS, GCP e Azure, com 
códigos  similares,  utilizando  ​Node.js  [43]  na  versão  12.  É  importante  também  salientar  que 
na  hora  do  teste,  todas  possuíam  ​256mb  de memória e se localizavam na região do ​Norte da 
Virgínia​, na região Leste dos Estados Unidos. 
Além  de  exercitar  uma  série  de  importantes  recursos  computacionais,  segundo  a 
CNCF  (​Cloud  Native  Computing  Foundation)​ ,  o  processamento  de  multimídia  é  um  dos 
casos  de  uso  mais  comuns  para  funções  serverless  [44], fazendo assim com que esse seja um 
exemplo bastante acurado com a realidade. 
É  possível  observar  na  Figura  5  um  diagrama  de  como  se  dá  o  fluxo  desse 
experimento, no contexto de uma requisição: 

Figura 5. Diagrama representando o fluxo do experimento de processamento de imagem 


Essas  funções  recebem  uma  imagem  no  formato  de ​base64  pelo corpo da requisição. 
Logo  após  o  recebimento  da  requisição,  ela  é  interpretada  para  que  logo  em  seguida,  seja 
aplicado  um  filtro  de  borrado  sobre  a  imagem  em  questão.  Após  esse  processamento  ser 
realizado,  imagem  é  salva  em  disco  e  é  retornada  uma  resposta  com  ​status  200  caso  tudo 
tenha  ocorrido  com  sucesso.  Logo  em  seguida,  é  exposta  a  implementação  de  uma  dessas 
funções, em específico a da AWS:
'use strict';

const jimp = require('jimp');

exports.handler = async (event) => {


const image = JSON.parse(event.body).image;
blur(image, console.log("Success"));
return {
statusCode: 200
};
};

function blur(base64Image, callback) {


const base64Data =
base64Image.replace(/^data:image\/png;base64,/, "");
const imageBuffer = Buffer.from(base64Data, 'base64');
jimp.read(imageBuffer, function(err, image) {
image.blur(10);
image.write('output.png', callback)
});
}
Com  esse  fluxo,  torna-se  possível  o  teste  de  três  dos  recursos  computacionais  mais 
comumente utilizados. São eles a CPU (processador), memória e disco. 
Para  a  realização  dos  testes,  serão  utilizadas  as  configurações  descritas  na  Tabela  2, 
que  foram  definidas  a  partir  das  combinações  entre  parâmetros  base  e o tamanho da imagem 
a  ser  processada,  no  objetivo  de  se  observar  o  efeito  dessa  variação  de  configuração  nas 
métricas: 
Tabela 2. Configurações utilizadas para o experimento de processamento de imagem 
Número de requisições  Número de requisições  Tamanho da imagem 
concorrentes 

10  1  90kb 

100  10  90kb 

1000  100  90kb 

10  1  180kb 

100  10  180kb 

1000  100  180kb 

6.2 Variação no Tamanho do Payload 


Para  esse  experimento,  foi  mais  uma  vez  tomado  como  base  o  estudo  da  CNCF,  que  aponta 
que  um  dos  outros  casos  de uso mais frequentes para a utilização de FaaS é o de ​HTTP REST 
API, que por sua vez, podem ter tamanhos de ​payload​ variáveis. 
Nessa  ótica,  este  experimento  vai  na  linha  de  analisar  os  efeitos  da  mudança  do 
tamanho  do  payload  de  resposta  na  performance  das  funções,  baseado  no  feito  por 
MARTINS et al [36]. 
Da  mesma  forma  que  para  o  experimento  anterior,  também  foram  implementadas 
funções  nos  3  principais  provedores  cloud  (AWS,  GCP,  Azure),  tendo  como  ambiente 
Node.js  12,  todas  com  256mb  de  memória  alocada  e  localizadas  na  região  do  Norte  da 
Virgínia. 
Diferente  do  experimento  da  Seção  6.1,  o  atual  é  bem  mais  simples.  As  funções 
recebem  na  requisição  o  tamanho  do  payload  em  ​kilobytes  que  a  resposta  deve  conter.  Para 
que  evitar  um  processamento  desnecessário  que  causaria  ruído  nas  métricas,  foram  pré 
definidas  no  código  4  ​strings  contendo  tamanhos  de  respectivamente  32kb,  64kb,  128kb  e 
256kb, e nessa ótica, focando no recurso de rede. 
O  trecho  de  código  seguinte  representa  a  implementação  da  função  em  questão,  na 
AWS,  com  os valores das strings dos payloads substituídos por placeholders, dado o tamanho 
das mesmas : 
'use strict';

exports.handler = async (event) => {


const responsePayloadSize =
event.queryStringParameters.responsePayloadSize;
const payload = getPayload(responsePayloadSize);
return {
statusCode: 200,
body: JSON.stringify({
message: `Payload[${responsePayloadSize}] ${payload}`,
}),
};
};

function getPayload(size) {
switch (size) {
case '32':
return '<32kb_string>';
case '64':
return '<64kb_string>';
case '128':
return '<128kb_string>';
case '256':
return '<256kb_string>';
}
}

 
Para  rodar  os  testes,  serão  utilizadas  as  configurações  descritas  conforme  a  Tabela 3, 
que  foram  definidas  a  partir  das  combinações  entre  parâmetros  base e o tamanho do ​payload 
que  constará  na  resposta  de  cada  requisição,  no  objetivo  de  se  observar  o  efeito  dessa 
variação de configuração nas métricas: 
Tabela 3. Configurações utilizadas para o experimento de variação no tamanho do payload
Número de requisições  Número de requisições  Tamanho do payload de 
concorrentes  resposta 

10  1  32 

100  10  32 

1000  100  32 

10  1  64 

100  10  64 

1000  100  64 

10  1  128 

100  10  128 

1000  100  128 

10  1  256 
100  10  256 

1000  100  256 


 

7. Resultados e Discussões 
 

7.1 Resultados dos Experimentos 


As  Tabelas  4  e  5  apresentam  respectivamente  os  resultados  dos  experimentos  de 
processamento de imagem e do impacto do tamanho do payload. 
É  importante  salientar  que  todos  os  testes  foram  feitos  com  as  funções  serverless 
“aquecidas”,  ou  seja,  todas  as  funções  foram  previamente  rodadas  num  intervalo  de  até  2 
minutos, na tentativa de se reduzir um possível efeito de cold-start, citado na Seção 2. 
Tabela 4. Resultados do experimento de processamento de imagem
Nº de  Nº de  Tamanh Provedor  Tempo  Nº de  P95 (em  P99 (em 
requisições  requisições  o do  total (em  sucessos  segundos)  segundos) 
concorrentes  arquivo  segundos) 

10  1  90kb  AWS  29,270  10  4,377  4,377 

10  1  90kb  GCP  35,181  10  13,990  13,990 

10  1  90kb  Azure  22,098  10  4,710  4,710 

100  10  90kb  AWS  34,505  100  5,073  6,428 

100  10  90kb  GCP  33,522  100  3,854  14,908 

100  10  90kb  Azure  33,778  100  7,181  9,043 

1000  100  90kb  AWS  112,808  1000  18,431  24,589 

1000  100  90kb  GCP  113,591  998  17,796  27,709 

1000  100  90kb  Azure  228,072  997  17,179  112,310 

10  1  180kb  AWS  26,922  10  4,672  4,672 

10  1  180kb  GCP  23,325  10  4,278  4,278 

10  1  180kb  Azure  24,896  10  5,427  5,427 

100  10  180kb  AWS  37,138  100  5,537  7,079 

100  10  180kb  GCP  30,261  100  5,374  8,968 

100  10  180kb  Azure  37,980  100  5,813  8,968 


1000  100  180kb  AWS  249,253  1000  39,022  49,923 

1000  100  180kb  GCP  253,691  998  36,199  60,495 

1000  100  180kb  Azure  316,497  1000  36,662  203,807 

Tabela 5. Resultados do experimento de variação no tamanho do payload


Nº de  Nº de  Tamanh Provedor  Tempo  Nº de  P95 (em  P99 (em 
requisições  requisições  o do  total (em  sucessos  segundos)  segundos) 
concorrentes  payload  segundos
de  ) 
resposta 

10  1  32  AWS  6.903  10  1,047  1,047 

10  1  32  GCP  5.033  10  0,622  0,622 

10  1  32  Azure  8.591  10  0,921  0,921 

100  10  32  AWS  5.891  100  0,695  0,736 

100  10  32  GCP  5.453  100  0,545  1,037 

100  10  32  Azure  9.709  100  1,251  4,545 

1000  100  32  AWS  17.169  1000  3,164  5,474 

1000  100  32  GCP  6.258  1000  0,911  1,199 

1000  100  32  Azure  46.491  999  1,899  3,138 

10  1  64  AWS  7.060  10  0,819  0,819 

10  1  64  GCP  5.033  10  0,606  0,606 

10  1  64  Azure  8.535  10  0,921  0,921 

100  10  64  AWS  5.493  100  0,550  0,643 

100  10  64  GCP  5.576  100  0,950  1,394 

100  10  64  Azure  9.103  100  0,956  0,957 

1000  100  64  AWS  16.509  1000  2,987  4,838 

1000  100  64  GCP  6.421  1000  1,119  1,492 

1000  100  64  Azure  19.098  1000  2,875  4,772 

10  1  128  AWS  7.364  10  0,819  0,819 


10  1  128  GCP  4.848  10  0,514  0,514 

10  1  128  Azure  8.781  10  0,973  0,973 

100  10  128  AWS  7.077  100  0,719  0,742 

100  10  128  GCP  5.726  100  1,070  1,140 

100  10  128  Azure  9.271  100  0,923  0,968 

1000  100  128  AWS  17.305  1000  3,812  5,466 

1000  100  128  GCP  12.461  1000  2,392  4,016 

1000  100  128  Azure  17.238  1000  2,616  3,914 

10  1  256  AWS  7.168  10  0,819  0,819 

10  1  256  GCP  5.279  10  0,614  0,614 

10  1  256  Azure  8.932  10  1,017  1,017 

100  10  256  AWS  5.749  100  0,718  0,792 

100  10  256  GCP  5.547  100  0,541  1,111 

100  10  256  Azure  9.052  100  0,921  0,922 

1000  100  256  AWS  20.855  1000  3,623  5,522 

1000  100  256  GCP  7.072  1000  1,299  1,722 

1000  100  256  Azure  19.122  1000  2,972  4,589 

7.2 Discussões dos Experimentos 


Analisando  os  resultados  de  performance  do  primeiro  experimento,  que  tem  foco  no 
processador, memória e disco, é perceptível que para os testes que com as configurações mais 
leves  (10  requisições  com  1  concorrente  e  100  requisições  com  10  concorrentes)  não  é 
possível  concluir  de  maneira  muito  assertiva  qual  das  funções  possui  a  melhor  performance, 
já  que  os  resultados  não  apresentam  uma  correlação  entre  o  tamanho  da imagem enviada e o 
tempo  médio  por  requisição. Essa relação apenas é constatada claramente quando se compara 
as amostras com as configurações mais pesadas (1000 requisições com 100 concorrentes).  
Nesses  casos  é  perceptível  que  as  funções  implantadas  na AWS e GCP possuem uma 
performance  equiparável.  Já  a  função  implantada  na  Azure  apresentou  tempos  médios  por 
requisição consideravelmente maiores, assim como suas taxas de falha.  
Um  fator  que  pode  justificar  determinado  comportamento,  pode  ser  suposto  a  partir 
métrica  de  P99,  que  indicou  valores  excessivamente  maiores  que  os  concorrentes, 
possivelmente  por  configuração  de  ​timeout  muito  grande,  fazendo  com  que  algumas 
requisições  demorassem  mais  a  responder  ao  invés  de  falhar,  o  que  em  determinados 
cenários, pode fazer bastante sentido. 
Para  o  segundo  experimento,  que  por  sua  vez, não exigia tantos recursos das funções, 
mas  mais  a  rede  envolvida,  foi exposto que nesse específico cenário, as funções conseguiram 
lidar  muito  melhor  com  número  de  requisições  mais  elevados  (1000  requisições  com  100 
concorrentes), tendo latências médias por requisição consideravelmente inferiores.  
Ao  se  analisar  o  efeito  do  tamanho  do  payload  de  resposta  na  performance  das 
funções,  não  foi  possível  notar  alguma  efeito  de  causalidade  direto,  pelo  menos  não  para  as 
configurações  utilizadas,  mas aparenta que o aumento no tempo de resposta e as taxas de erro 
subiam  em  decorrência  do  aumento  de  requisições.  A  função  implantada  na  GCP  foi  a  que 
apresentou  a  maior  estabilidade  às  variações  das  configurações,  se  comportando 
consideravelmente  melhor  principalmente  nos  casos  de  maior  estresse,  em  comparação  às 
outras. E como no experimento anterior, mais uma vez a da Azure foi a que pior performou. 
Sumarizando,  foi  notável que a load-donkey possibilitou de forma simples a definição 
de  diferentes  casos  de  testes  de  performance,  sob  todas  as  funções  ​serverless  definidas,  de 
maneira simples a partir dos SpecFiles (definidos na Seção 5.1.1.1). 
Logo  após  a  realização  dos  testes,  a  ferramenta  foi  capaz  de  apresentar  de  forma 
comparativa  as  métricas  de  performance  das  funções  testadas,  facilitando  o  processo  de 
identificação  de  quais  funções  apresentaram  melhores  resultados  referentes  às  determinadas 
métricas, assim possibilitando a quantificação das diferenças entre suas performances. 
Além  disso,  foi possível perceber que a load-donkey não demonstrou nenhum sinal de 
instabilidade  nem  de  lentidão  durante  todos  os  experimentos  realizados.  Por  meio  dela,  foi 
possível a obtenção de todos os resultados e também dos insights destacados anteriormente. 

8. Conclusão 
Pode-se  então  concluir  que  este  trabalho  atinge  satisfatoriamente  seu  propósito,  exposto  na 
Seção  3,  de  entender  e  aprimorar  o  processo  de  benchmarking  em  funções  serverless 
implantadas em ambientes possivelmente multi-cloud.  
A  partir  de  uma análise do estado da arte, vista na Seção 4, foi viável a elucidação das 
questões  fundamentais  que  nortearam  o  trabalho.  Com  essas respostas, foi desenvolvida uma 
ferramenta  capaz  de  realizar  o  benchmarking  de  funções  serverless,  que  fizesse  uso  dos 
parâmetros  e  métricas  mais  relevantes  envolvidas  nesse  processo e que pode ser utilizada em 
um  contexto  cotidiano,  sobre  funções  definidas  pelos  próprios  engenheiros  de  software,  em 
ambientes multi-cloud ou não. 
Com  os  experimentos  realizados,  foi  perceptível  a  viabilidade  no  uso  da  ferramenta, 
que  tornou  possível  fácil  a  configuração  de  inúmeros  casos de teste, a apresentação de várias 
métricas  de  performance  já  consolidadas  de  forma  comparativa,  e  que  demonstrou  total 
estabilidade em sua aplicação, apontando métricas capazes de fornecer insights valiosos sobre 
o  comportamento  das  funções  testadas,  que  por  sua  vez,  foram  implementadas  tendo  como 
base nos casos mais comuns de aplicações de serverless. 

9. Trabalhos Futuros 
Durante  o  desenvolvimento  deste  trabalho,  algumas  limitações  foram  percebidas  na 
ferramenta: 
● Aprimoramento  visual  do  report, utilizando-se de técnicas de design e visualização de 
dados,  a  fim  de  torná-lo  mais  fácil  de  se  interpretar  as  métricas  consolidadas,  assim 
aumentando a propensão de se tirar insights sobre os dados; 
● Criação de outros módulos na camada de interface de usuário, como por exemplo uma 
API REST, que pode ser consumida por outros serviços;  
● Implementação  de  interfaces  com  outros  motores  de  teste de carga, tornando possível 
suas utilizações e gerando métricas específicas desses motores; 
● Implementação  de  mecanismo  de  coleta  de  ​logs  dos  próprios  provedores  cloud, 
fornecendo  métricas  que  não  são  capazes  de  ser  obtidas  por  meio  dos motores, como 
por exemplo, o custo de cada execução das funções; 
● Fazer  com  que  a  própria  ferramenta  aponte  qual  das  funções  sob  teste  teve  o  melhor 
desempenho, a partir de uma função utilidade com fatores definidos pelo usuário. 

10. Referências 
[1]LEINER,  Barry  M.  et  al.  A  brief  history  of  the  Internet.  ACM  SIGCOMM  Computer 
Communication Review, v. 39, n. 5, p. 22-31, 2009. 
[2]WINKLER,  Till  J.;  BROWN,  Carol  V.  Horizontal  allocation  of  decision  rights  for 
on-premise  applications  and  software-as-a-service.  Journal  of  Management  Information 
Systems, v. 30, n. 3, p. 13-48, 2013. 
[3]THÖNES, Johannes. Microservices. IEEE software, v. 32, n. 1, p. 116-116, 2015. 
[4]ROBERTS,  Serverless  Architectures.  2018.  Acesso  em:  09/04/20.  Disponível  em: 
<https://martinfowler.com/articles/serverless.html>. 
[5]Amazon  Web  Services,  AWS.  Acesso  em:  09/04/20.  Disponível  em: 
<https://aws.amazon.com/pt/>. 
[6]Google  Cloud,  Google  Cloud  Platform.  Acesso  em:  09/04/20.  Disponível  em: 
<https://cloud.google.com/>. 
[7]Microsoft  Azure,  Microsoft  Azure.  Acesso  em:  09/04/20.  Disponível  em: 
<https://azure.microsoft.com/pt-br/>. 
[8]Amazon  Web  Services,  AWS  Lambda.  Acesso  em:  09/04/20.  Disponível  em: 
<https://aws.amazon.com/pt/lambda/>. 
[9]Google  Cloud,  Cloud  Functions.  Acesso  em:  09/04/20.  Disponível  em: 
<https://cloud.google.com/functions?hl=pt-br>. 
[10]Microsoft  Azure,  Azure  Functions.  Acesso  em:  09/04/20.  Disponível  em: 
<​https://azure.microsoft.com/pt-br/services/functions/​>. 
[11]WANG,  Lizhe  et  al.  Cloud  computing: a perspective study. New Generation Computing, 
v. 28, n. 2, p. 137-146, 2010. 
[12]MELL, Peter et al. The NIST definition of cloud computing. 2011. 
[13]BOKHARI,  Mohammad  Ubaidullah;  SHALLAL, Qahtan Makki; TAMANDANI, Yahya 
Kord.  Cloud  computing  service  models:  A  comparative  study.  In:  2016  3rd  International 
Conference  on  Computing  for  Sustainable  Global  Development  (INDIACom).  IEEE, 
2016. p. 890-895. 
[14]Khalidi,  Y.  A.  2011.  "Building  a  Cloud  Computing  Platform  for  New  Possibilities," 
Computer (44), pp 29- 34. 
[15]ARORA,  Pankaj;  WADHAWAN,  Rubal  Chaudhry;  AHUJA,  Er  Satinder  Pal.  Cloud 
computing  security  issues  in  infrastructure  as  a  service.  International  journal  of  advanced 
research in computer science and software engineering, v. 2, n. 1, 2012. 
[16]NGINX  Announces  Results  of  2016  Future  of  Application  Development  and  Delivery 
Survey.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://www.nginx.com/press/nginx-announces-results-of-2016-future-of-application-dev
elopment-and-delivery-survey/​>. 
[17]Larry  Seltzer.  2018.  Serverless  computing  explained  |  HPE.  Acesso  em:  12/11/20. 
Disponível  em: 
<​https://www.hpe.com/us/en/insights/articles/serverless-computing-explained-1807.html​>. 
[18]HALL,  Adam;  RAMACHANDRAN,  Umakishore.  An  execution  model  for  serverless 
functions  at  the  edge.  In:  Proceedings  of  the  International  Conference  on  Internet  of 
Things Design and Implementation. 2019. p. 225-236. 
[19]Tim  Wagner.  2014.  Understanding  Container  Reuse  in  AWS  Lambda.  Acesso  em: 
12/11/20.  Disponível  em: 
<​https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/​>. 
[20]Colby  Tresness.  2018.  Understanding  serverless  cold  start.  Acesso  em:  12/11/20. 
Disponível  em: 
<​https://azure.microsoft.com/pt-br/blog/understanding-serverless-cold-start/​>. 
[21]IBM  Cloud,  IBM  Cloud  Functions.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://www.ibm.com/br-pt/cloud/functions​>. 
[22]Hetzel,  Bill  (1984).  The  Complete  Guide  to  Software  Testing.  QED  Information 
Sciences. ISBN 0-89435-110-9. 
[23]CRAIG,  Rick  David;  JASKIEL,  Stefan  P.  Systematic  software  testing.  Artech  house, 
2002. 
[24]JORGENSEN, Paul C. Software testing: a craftsman’s approach. CRC press, 2018. 
[25]AMMANN,  Paul;  OFFUTT,  Jeff. Introduction to software testing. Cambridge University 
Press, 2016. 
[26]Sten  Pittet.  The  different  types  of  software testing. Acesso em: 12/11/20. Disponível em: 
<​https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testin
g​>. 
[27]IEEE,  IEEE  Xplore.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://ieeexplore.ieee.org/Xplore/home.jsp​>. 
[28]ACM  Digital  Library,  ACM  Journals.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://dl.acm.org/journals​>. 
[29]Springer,  Springer  Link.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://link.springer.com/​>. 
[30]Google,  Google  Acadêmico.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://scholar.google.com.br/?hl=pt​>. 
[31]JANGDA,  Abhinav  et  al.  Formal  foundations  of  serverless  computing.  Proceedings  of 
the ACM on Programming Languages, v. 3, n. OOPSLA, p. 1-26, 2019. 
[32]Austen  Collins.  2016.  Releasing  Serverless  Framework  V.1  &  Fundraising.  Acesso  em: 
12/11/20.  Disponível  em: 
<​https://www.serverless.com/blog/releasing-serverless-framework-v1-and-fundraising​>. 
[33]KIM,  Jeongchul;  LEE,  Kyungyong.  Functionbench:  A  suite  of  workloads  for  serverless 
cloud  function  service.  In:  2019 IEEE 12th International Conference on Cloud Computing 
(CLOUD). IEEE, 2019. p. 502-504. 
[34]MALAWSKI,  Maciej  et  al.  Benchmarking  heterogeneous  cloud  functions.  In:  European 
Conference on Parallel Processing. Springer, Cham, 2017. p. 415-426. 
[35]SOMU,  Nikhila  et  al.  PanOpticon:  A  Comprehensive  Benchmarking  Tool for Serverless 
Applications.  In:  2020  International  Conference  on  COMmunication  Systems  & 
NETworkS (COMSNETS). IEEE, 2020. p. 144-151. 
[36]MARTINS,  Horácio;  ARAUJO,  Filipe;  DA  CUNHA,  Paulo  Rupino.  Benchmarking 
Serverless Computing Platforms. Journal of Grid Computing, p. 1-19, 2020. 
[37]MAISSEN,  Pascal  et  al.  FaaSdom:  A  Benchmark  Suite  for Serverless Computing. arXiv 
preprint arXiv:2006.03271, 2020. 
[38]ROBSON,  Ricardo.  2018.  Em  direção  a  um  Framework  Serverless  para  Docker  Swarm. 
Trabalho  de  Conclusão  de  Curso  (Bacharelado  em  Sistemas  de  Informação)  -  Centro  de 
Informática, Universidade Federal de Pernambuco. 2018 
[39]Apache,  ab  -  Apache  HTTP  server  benchmarking  tool.  Acesso em: 12/11/20. Disponível 
em: <​https://httpd.apache.org/docs/2.4/programs/ab.html​/​>. 
[40]Samuel  Oloruntoba.  2020.  S.O.L.I.D:  The  First  5  Principles  of  Object  Oriented  Design. 
Acesso  em:  12/11/20.  Disponível  em: 
<​https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-prin
ciples-of-object-oriented-design​>. 
[41]Loadtest.  Acesso  em:  12/11/20.  Disponível  em: 
<​https://github.com/alexfernandez/loadtest​>. 
[42]Artillery. Acesso em: 12/11/20. Disponível em: <​https://artillery.io/​>. 
[43]Node.js. Acesso em: 12/11/20. Disponível em: <​https://nodejs.org/en/​>. 
[44]Cloud  Native  Computing  Foundation,  CNCF  WG-Serverless  Whitepaper  v1.0.  Acesso 
em:  16/11/20.  Disponível  em: 
<​https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf
_serverless_whitepaper_v1.0.pdf​>. 
[45]InfluxData,  InfluxDB.  Acesso  em:  15/11/20.  Disponível  em: 
<​https://www.influxdata.com/products/influxdb/​>. 
[46]GrafanaLabs, Grafana. Acesso em: 15/11/20. Disponível em: <​https://grafana.com/​>. 
[47]BASILI,  V.  GQM  approach  has  evolved to include models. IEEE SOFTWARE, v. 11, n. 
1, p. 8-8, 1994. 
[48]Zachary  Tong.  2014.  Averages  Can  Be  Misleading:  Try  a  Percentile.  Acesso  em: 
16/11/20.  Disponível  em: 
<​https://www.elastic.co/blog/averages-can-dangerous-use-percentile​>. 
[49]Andrea  Passwater.  2017.  When  (and  why)  not  to  go  serverless.  Acesso  em:  07/12/20. 
Disponível em: <​https://www.serverless.com/blog/when-why-not-use-serverless​>. 
[50]STAPENHURST, Tim. The benchmarking book. Routledge, 2009.