Universidade de Brasília

Instituto de Ciências Exatas

Departamento de Ciência da Computação

Análise do Custo-benefício de Funções como Serviço

e Infraestrutura como Serviço

Waliff Cordeiro Bandeira

Monografia apresentada como requisito parcial

para conclusão do Curso de Engenharia da Computação

Orientadora
Prof.a Dr.a Aletéia Patrícia Favacho de Araújo Von Paumgartten

Coorientador
MSc Leonardo Rebouças de Carvalho

Brasília
2022
 Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação

Análise do Custo-benefício de Funções como Serviço

e Infraestrutura como Serviço

Waliff Cordeiro Bandeira

Monografia apresentada como requisito parcial

para conclusão do Curso de Engenharia da Computação

Prof.a Dr.a Aletéia Patrícia Favacho de Araújo Von Paumgartten (Orientadora)

CIC/UnB

Prof. Dr. Edison Ishikawa MSc Edward Ribeiro

CIC/UnB Senado Federal

Prof. Dr. João Luiz Azevedo de Carvalho

Coordenador do Curso de Engenharia da Computação

Brasília, 27 de setembro de 2022

 Dedicatória

Dedico este trabalho em especial à minha amada família, minha mãe Valentina Pires
Cordeiro Rosa, minha tia Gláucia Pires Cordeiro Rosa, minha avó Zuleica Cordeiro Cav-
alcante e a minha irmã Briany Cordeiro, que possuem papel fundamental em minha vida.
Elas sempre me deram amor, carinho, cuidado e proporcionaram o ambiente necessário
para me tornar a pessoa que sou hoje. Dedico também este trabalho à minha namorada
Bruna Mendonça de Morais que esteve ao meu lado dando todo apoio necessário.

iii
 Agradecimentos

Agradeço à Prof.a Dr.a Aletéia Patrícia Favacho de Araújo Von Paumgartten por ter me
orientado durante a longa jornada do Trabalho de Conclusão de Curso, tive a oportu-
nidade de conhecer mais sobre a extensa área de computação em nuvem além de conhecer
essa pessoa dedicada, paciente e que desempenha um incrível e relevante trabalho em
sua área de atuação. Agradeço também ao Leonardo Rebouças de Carvalho pelo tempo
dedicado me auxiliando no desenvolvimento do ambiente de testes e também na análise
dos resultados obtidos. Agradeço aos meus companheiros de curso João Pedro Assis dos
Santos, Pedro Augusto Ramalho Duarte e Estevan Alexander de Paula que participaram
ativamente de toda essa etapa da minha vida. Por fim, agradeço a todo o corpo do-
cente da Universidade de Brasília que me auxiliou durante a graduação, em especial o
Departamento de Ciências da Computação.
O presente trabalho foi realizado com apoio da Coordenação de Aperfeiçoamento de
Pessoal de Nível Superior - Brasil (CAPES), por meio do Acesso ao Portal de Periódicos.

iv
 Resumo

Função como Serviço (FaaS) e Infraestrutura como Serviço (IaaS) são tipos de serviço
com grande relevância no paradigma de computação em nuvem. Ao considerar crescente
demanda pelos serviços citados, o presente trabalho realiza uma análise de custo-benefício
para auxiliar usuários na tomada de decisão acerca de qual serviço melhor se enquadraria
em seus projetos. A análise envolve um caso de trade-off no qual torna-se necessário
avaliar o contexto da aplicação uma vez que desempenho e custo monetário são inver-
samente proporcionais nessa situação. Os resultados iniciais mostraram que o tipo de
serviço IaaS não suportou todos cenários de teste, enquanto o FaaS apresentou melhor
performance em troca de maior custo monetário.

Palavras-chave: função como serviço, infraestrutura como serviço, computação em nu-

vem, FaaS, IaaS

v
 Abstract

Function as a Service (FaaS) and Infrastructure as a Service (IaaS) are types of services
with great relevance in the cloud computing paradigm. Considering the growing demand,
the present work performs a cost-benefit analysis to assist users in making decisions about
which service would best fit their projects. The analysis involves a trade-off case in which
it is necessary to evaluate the application context since performance and monetary cost
are inversely proportional in this situation. The initial results showed that the IaaS service
type did not support all test scenarios, while the FaaS presented better performance in
exchange for higher monetary cost.

Keywords: function as a service, infrastructure as a service, cloud computing, FaaS, IaaS

vi
 Sumário

1 Introdução 1

2 Computação em Nuvem 3
2.1 Definição de computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Módelo de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Provedores de Nuvem Pública . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Amazon Web Services (AWS) . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Google Cloud Platform (GCP) . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Modelos de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Infraestrutura como um Serviço . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Plataforma como um Serviço . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Software como um Serviço . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.4 Tudo como um Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Função como um Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 AWS Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Azure Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.3 Cloud Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Custo Monetário do FaaS e IaaS . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.1 Custo dos Serviços no Provedor AWS . . . . . . . . . . . . . . . . . . . 16
2.6.2 Custo dos Serviços na GCP . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.3 Custo dos Serviços na Azure . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Benchmark 24
3.1 FaaSdom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Função Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Função Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 Função Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vii
 3.1.4 Função Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Ferramenta de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Serviço FaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Serviço IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Resultados 35
4.1 Análise do Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Análise de Casos Específicos de Tempo Médio de Resposta . . . . . . . 39
4.2 Análise da Taxa de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Casos Específicos com Alto Indíce de Erro . . . . . . . . . . . . . . . . 45
4.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Conclusão 48

Referências 50

viii
 Lista de Figuras

2.1 Quadrante mágico do Gartner [1]. . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Mapa da infraestrutura da AWS [2]. . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Mapa de infraestrutura da GCP [3]. . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Rede global da Microsoft [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Comparação dos modelos de serviço definidos pelo NIST. . . . . . . . . . . 10
2.6 Definição de preço do AWS Lambda [5]. . . . . . . . . . . . . . . . . . . . 17

3.1 Interface Web do FaaSdom. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Diagrama do fluxo de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Deploy da função filesystem no FaaSdom. . . . . . . . . . . . . . . . . . . . 32
3.4 Versão final das funções na AWS. . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Versão final das funções na GCP. . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Versão final das funções na Azure. . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Exemplo de tabela gerada no HTML por meio do Jmeter. . . . . . . . . . . 36

4.2 Resultado de desempenho agrupado por função. . . . . . . . . . . . . . . . 37
4.3 Resultado de desempenho agrupado por provedor. . . . . . . . . . . . . . . 38
4.4 Resultado de desempenho agrupado por linguagem de programação. . . . . 39
4.5 Função filesystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Função factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Função latency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Função matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Resultado comparativo do uso de ramp-up para a função latency. . . . . . . 41
4.10 Resultado comparativo do uso de ramp-up para a função latency. . . . . . . 42
4.11 Taxa de erro agrupado por função. . . . . . . . . . . . . . . . . . . . . . . 43
4.12 Taxa de erro agrupado por provedor. . . . . . . . . . . . . . . . . . . . . . 44
4.13 Taxa de erro agrupado por linguagem de programação. . . . . . . . . . . . 45

ix
 Lista de Códigos

1 Função Latency implementada em Go [6]. . . . . . . . . . . . . . . . . . . . . 26

2 Função Factors implementada em Node [7]. . . . . . . . . . . . . . . . . . . . 27
3 Função Matrix implementada em Python [8]. . . . . . . . . . . . . . . . . . . 28
4 Versão com trechos omitidos da Função Filesystem implementada em Node [9]. 29
5 Exemplo de execução do Jmeter através de CLI para gerar tabelas e gráficos
a partir dos resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Exemplo de execução do Jmeter através de CLI. . . . . . . . . . . . . . . . . 36
7 Exemplo de comando CLI para fazer cópia de arquivos remotamente. . . . . . 36

x
 Lista de Tabelas

2.1 Preço por hora do EC2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Preço por mês do EC2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Preço por milissegundo até 6 bilhões de GB-segundos/mês. . . . . . . . . . 18
2.4 Preço por hora das máquinas virtuais padrão E2. . . . . . . . . . . . . . . 18
2.5 Preço por mês das máquinas virtuais padrão E2. . . . . . . . . . . . . . . . 19
2.6 Preço por tempo de execução. . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Preço por quantidade de requisições. . . . . . . . . . . . . . . . . . . . . . 19
2.8 Preço por uso de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 Exemplo de custo de um caso de uso simples. . . . . . . . . . . . . . . . . 20
2.10 Exemplo de custo de um caso de uso robusto. . . . . . . . . . . . . . . . . 20
2.11 Preço por mês das máquinas virtuais padrão B. . . . . . . . . . . . . . . . 21
2.12 Plano Consumo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.13 Plano Premium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.14 Cálculo de cobrança de consumo de recursos. . . . . . . . . . . . . . . . . . 22
2.15 Cálculo de cobrança de execuções. . . . . . . . . . . . . . . . . . . . . . . . 22
2.16 Cálculo de cobrança de consumo total. . . . . . . . . . . . . . . . . . . . . 22

3.1 Máquinas virtuais utilizadas nos testes. . . . . . . . . . . . . . . . . . . . . 34

4.1 Taxas de erro acima de 50% na AWS. . . . . . . . . . . . . . . . . . . . . . 46

4.2 Taxas de erro acima de 50% na Azure. . . . . . . . . . . . . . . . . . . . . 46
4.3 Taxas de erro acima de 50% na GCP. . . . . . . . . . . . . . . . . . . . . . 46

xi
 Lista de Abreviaturas e Siglas

API Application Programming Interface.

AWS Amazon Web Service.

Azure Microsoft Azure.

BPaaS Business Process as a Service.

CaaS Communications as a Service.

CD Continuous Delivery .

CLI Command-line interface.

DaaS Desktop as a Service.

DBaaS DataBase as a Service.

FaaS Function as a Service.

GCP Google Cloud Platform.

IaaS Infrastructure as a Service.

MaaS Monitoring as a Service.

NaaS Network as a Service.

NIST National Institute of Standards and Technology.

PaaS Platform as a Service.

SaaS Software as a Service.

XaaS Anything as a Service.

xii
Capítulo 1

Introdução

A computação em nuvem surgiu no contexto de modificar a estrutura que, até o início

do século XXI, lidava com a gerência de recursos computacionais. Antes do surgimento
desse novo paradigma, ao demandar mais poder computacional, alocava-se mais máquinas
ou máquinas mais robustas para suprir a necessidade de recursos. Assim sendo, com o
aumento da demanda por poder computacional, empresas e pesquisadores se deparavam
com a necessidade de criar infraestruturas cada vez mais robustas para manter o bom
funcionamento de seus sistemas. Isso era economicamente inviável e insustentável.
O paradigma computação em nuvem utiliza a Internet para disponibilizar serviços
computacionais. O modelo permite a troca de recursos monetários por serviços compu-
tacionais por meio de uma interface de fácil utilização. Dessa forma, grandes provedores
(empresas) surgiram no contexto de disponibilização de serviços em nuvem, dentre as
maiores destacam-se a Amazon Web Service (AWS), a Microsoft Azure, e a Google Cloud
Platform (GCP). Assim, a principal funcionalidade dos provedores é o oferecimento de
diferentes serviços computacionais sob demanda.
Dada a pluralidade de recursos com possibilidade de disponibilização nesse paradigma,
diversos serviços foram criados. Entre esses é possível destacar Software como Serviço (do
inglês, Software as a Service - SaaS), Plataforma como Serviço (do inglês, Platform as
a Service - PaaS), Infraestrutura como Serviço (do inglês, Infrastructure as a Service -
IaaS), Banco de dados como Serviço (do inglês, DataBase as a Service - DBaaS), Função
como Serviço (do inglês, Function as a Service - FaaS) e outros. Para padronizar a grande
quantidade de serviços que estavam surgindo e, consequentemente as siglas, o National
Institute of Standards and Technology (NIST) publicou uma definição sobre computação
em nuvem [10] e padronizou três modelos de serviços (IaaS, PaaS e SaaS).
Dessa forma, um dos serviços disponibilizados pelos provedores de nuvem é a Infraes-
trutura como Serviço - IaaS, que permite a locação de recursos computacionais no formato
de máquinas virtuais. Nesse modelo de serviço o usuário pode escolher o sistema ope-

1
racional, a quantidade de memória RAM, o poder computacional e outras configurações
adicionais. O modelo IaaS facilita o acesso à infraestrutura e recursos computacionais.
Porém, percebe-se que toda a configuração de ambiente necessária para a utilização da
infraestrutura fica a cargo do cliente. Além disso, nota-se que em caso de necessidade de
mais recurso computacional, o cliente é responsável por decidir explicitamente por uma
resolução para o problema de falta de recursos. Por outro lado, o serviço do tipo Função
como Serviço (FaaS) permite a execução de códigos sem necessidade de configurações adi-
cionais por parte do cliente, ou seja, é só acessar e utilizar. O serviço também se propõe a
ser altamente escalável e elástico, permitindo que o cliente aumente a utilização do serviço
sem necessitar de medidas ou configurações adicionais.
Todavia, ao observar a descrição de ambos os serviços, fica evidente a facilidade pro-
porcionada pelo tipo de processamento do tipo função como serviço em comparação ao
serviço do tipo infraestrutura como serviço. Porém, observa-se que existe um valor mo-
netário envolvido na facilidade adicional proporcionada pelo FaaS. Diante do exposto,
este trabalho tem como objetivo analisar, por meio de testes em ambientes reais, o custo-
benefício dos serviços FaaS e IaaS, com a proposta de evidenciar o poder computacional
disponibilizado e qual o custo monetário dessa disponibilização nos casos testados. A
ideia é proporcionar ao usuário insumos para auxiliar na decisão de qual serviço contratar
para contextos semelhantes. O benchmark escolhido foi o FaasDom [11], que proporciona
quatro diferentes funções que possibilitam estressar ambos ambientes, provendo insumos
para a análise de custo-benefício.
Para isto, este trabalho está estruturado, além deste capítulo, em mais 5 capítulos.
O Capítulo 2 apresenta as definições de computação em nuvem e as suas características.
Ainda no Capítulo 2 são apresentados os principais serviços e provedores de computação
em nuvem. O Capítulo 3 apresenta o benchmark Faasdom [11] que foi usado na avaliação
dos serviços IaaS e FaaS neste trabalho. Também apresenta as funções utilizadas, assim
como exemplifica seus códigos e apresenta como foram implementados os ambientes de
testes de forma a aproximá-los ao máximo, proporcionando condições semelhantes para
obtenção de resultados mais justos. O Capítulo 4 apresenta os experimentos realizados
para avaliar o custo-benefício dos dois serviços em análise. Por fim, o Capítulo 5 apresenta
as conclusões finais a partir dos resultados obtidos, evidenciando também os passos futuros
para continuidade de avaliações mais aprofundadas desses serviços.

2
Capítulo 2

Computação em Nuvem

2.1 Definição de computação em nuvem

Computação em nuvem disponibiliza, através da Internet, recursos computacionais como
serviço. Até a implementação desse conceito no final da década de 1990, a disponibilização
de recursos computacionais demandava infraestrutura física, ou seja, para aumentar o
poder computacional, mais máquinas ou máquinas mais robustas faziam-se necessárias,
de forma que o custo monetário e a logística envolvida eram relevantes [12].
Há indícios históricos de que a ideia de computação em nuvem surgiu na década de
1960 através de John McCarthy [13] o qual defendeu a ideia de time-sharing, que consiste
em compartilhar o tempo ocioso das máquinas entre os usuários. Porém, pela falta de
tecnologias que permitissem a aplicação do conceito, somente na década de 1990, de fato,
começaram a surgir projetos que concretizaram o conceito enunciado por John McCarthy
[13].
O paradigma de computação em nuvem disponibiliza recursos de armazenamento e
de processamento sob demanda. Nesse caso, o cliente paga apenas pelo que utilizar,
tornando-se desnecessária a aquisição de componentes de alto valor monetário e, em al-
guns casos, muito espaço físico necessário para prover esse ambiente de alto poder compu-
tacional. Assim, a computação em nuvem possui algumas características relevantes, tais
como [14]:

• Elasticidade: facilidade em aumentar e reduzir dinamicamente recursos sob de-

manda;

• Disponibilidade: pela redundância das informações criadas nas diferentes camadas

da operação, a garantia de oferta dos serviço aumenta;

• Serviço sob demanda: o usuário pode requisitar os serviços e os recursos necessários

sem a necessidade de uma interação humana, pagando somente pelo que utilizar;

3
 • Mensuração do serviço: cada nuvem pode oferecer diferentes níveis de abstração,
mas são disponibilizadas métricas sobre os recursos utilizados como horas de CPU,
largura de banda, armazenamento e outros.

As nuvens computacionais são divididas em quatro principais modelos de implantação,

que são as nuvens públicas, privadas, híbridas e comunitárias. Na Seção 2.2 serão deta-
lhados esses modelos de implantação. Em seguida, a Seção 2.3 abordará os provedores
de computação em nuvem, que consistem em grandes empresas que disponibilizam seus
serviços no mercado. Por fim, a Seção 2.4 visa apresentar os serviços de computação em
nuvem e como eles são disponibilizados para o usuário.

2.2 Módelo de Implantação

A computação em nuvem apresenta diversos serviços e diferentes tipos. O National Ins-
titute of Standards and Technology (NIST) [10] classificou quatro tipos de nuvem [15]:

• Nuvem pública: é a mais popular fornecida pelo provedores para utilização do pú-
blico em geral. No caso das nuvens públicas o software e o hardware são gerenciados
pela empresa provedora, sendo que fica a cargo do usuário apenas a utilização e o
pagamento pelo serviço demandado. A infraestrutura utilizada é compartilhada por
diversos clientes;

• Nuvem privada: oferece os mesmos benefícios que a nuvem pública com a dife-
rença de ter a infraestrutura exclusiva para utilização da empresa proprietária. A
infraestrutura pode ser construída de forma própria pela empresa no formato de da-
tacenters, ou até mesmo contratado a partir de uma empresa provedora. Esse tipo
de nuvem é importante, principalmente, para empresas que trabalham com dados
críticos, uma vez que necessitam de maior segurança e controle sob seus dados;

• Nuvem comunitária: é administrada por grupos com interesses semelhantes. Esse

formato proporciona uma diluição dos custos entre o grupo, e facilita o comparti-
lhamento de dados;

• Nuvem híbrida: possibilita a integração entre qualquer tipo de nuvem citado an-
teriormente. Esse modelo é ideal para empresas que possuem uma infraestrutura
estabelecida, mas precisam expandir o seu poder computacional nas partes menos
críticas dos sistemas.

Na próxima seção serão detalhadas as principais empresas provedoras de ambientes de

computação em nuvem.

4
2.3 Provedores de Nuvem Pública
Com a crescente demanda de infraestrutura especializada e serviços de nuvem computa-
cional, algumas empresas se tornaram referência no mercado. Gartner é uma empresa
de consultoria que produz diversos relatórios e o Quadrante Mágico do Gartner [1] reune
os principais provedores de computação em nuvem, conforme apresentado na Figura 2.1.
Nessa figura é possível perceber sete grandes empresas: Amazon Web Service [16], Azure
Microsoft [17], Google Cloud Platform [18], Tencent Cloud [19], IBM [20], Oracle [21] e
Alibaba Cloud [22]. Dentre as sete empresas levantadas pela empresa Gartner, a AWS, a
Azure e a GCP lideram o mercado. Por isso, elas serão detalhadas nas próximas seções
deste trabalho.

Figura 2.1: Quadrante mágico do Gartner [1].

A AWS, a GCP e a Azure possuem zonas de disponibilidade, que juntas, abrangem

todos os continentes do mundo. Essas regiões podem ser entendidas como locais físicos
onde são agrupados datacenters. Essas regiões possuem o foco em alta disponibilidade,
redundância, e por estarem fisicamente em diversas regiões, eles possibilitam a escolha de
uma infraestrutura que reduza a latência da aplicação [23].

5
2.3.1 Amazon Web Services (AWS)
A Amazon possui sua história iniciada em 1994 como uma empresa vendedora de livros,
além de uma das maiores lojas online do mundo. Contudo, por volta dos anos 2000 a
Amazon identificou a crescente demanda de infraestrutura computacional, percebendo
uma oportunidade de ampliar sua carta de serviços e atuar no mercado de computação
em nuvem. Após seis anos de muita pesquisa e avanços tecnológicos, em 2006, surgiu a
Amazon Web Service (AWS) [24].
Entre os setores que a AWS atua tem-se: publicidade e marketing, tecnologia e jogos,
serviços financeiros e mídia, e entretenimento. A AWS atua com soluções em análises e
data lakes, machine learning, armazenamento, computação sem servidor e outros. Atual-
mente, a Amazon Web Service disponibiliza mais de 200 produtos [25], entre esses:

• Amazon Elastic Compute Cloud (Amazon EC2) [26]: permite alocação de máquinas
virtuais, disponibilizando infraestrutura remota para utilização instantânea;

• AWS Lambda [27]: serviço orientado a eventos que permite a execução de códigos
sob demanda sem a necessidade de preocupação com servidores;

• Amazon Simple Storage Service (Amazon S3) [28]: serviço de armazenamento de

objetos que oferece alta escalabilidade, segurança e disponibilidade;

• Amazon DynamoDB [29]: banco de dados chave-valor NoSQL totalmente gerenciado

e serverless (sem servidor);

• Amazon API Gateway [30]: facilita o projeto, a criação, a publicação, o monitora-

mento e a manutenção de APIs em qualquer escala.

A Nuvem AWS abrange 84 zonas de disponibilidade em 26 regiões geográficas em todo

o mundo. A empresa já divulgou planos para disponibilizar mais 24 zonas de disponi-
bilidade e outras 8 regiões na Austrália, Canadá, Índia, Israel, Nova Zelândia, Espanha,
Suíça e Emirados Árabes Unidos (EAU) [2]. A Figura 2.2 apresenta o atual mapa da
infraestrutura da AWS.

6
 Figura 2.2: Mapa da infraestrutura da AWS [2].

2.3.2 Google Cloud Platform (GCP)

Em 1997 o domínio google.com foi registrado, projeto iniciado na Stanford University [31]
por Larry Page e Sergey Brin. Em 1998 a Google Inc. [18] foi fundada com o objetivo
de evoluir como um software de motor de busca [32]. Em 2008 surgiu a Google Cloud
Platform (GCP), solução de computação em nuvem que compete entre os três maiores
provedores de serviços em nuvem. A GCP, atualmente, disponibiliza mais de 100 produtos
[18], entre eles:

• Cloud Functions [33]: serviço orientado a eventos que permite a execução de códigos
sob demanda;

• Compute Engine [34]: permite alocação de máquinas virtuais, disponibilizando in-

fraestrutura remota para utilização instantânea;

• Kubernetes Engine [35]: auxilia a criação e a gerência de aplicativos baseados em

contêiner, com tecnologia de código aberto Kubernetes;

• BigQuery [36]: facilita a análise de dados, tirando a responsabilidade de gerencia

de infraestrutura e necessidade de um administrador de banco de dados;

• Cloud Storage [37]: serviço de armazenamento de objetos que assegura simplicidade,

segurança, durabilidade e alta disponibilidade.

A Google Cloud Platform, atualmente, conta com infraestrutura física em 34 regiões,

73 zonas, 144 localizações de borda de rede, e mais de 200 países e territórios [38]. A

7
Figura 2.3 apresenta as regiões que possuem pelo menos 3 zonas de disponibilidade, assim
como as regiões que estão sendo implantadas com a mesma quantidade de zonas.

Figura 2.3: Mapa de infraestrutura da GCP [3].

2.3.3 Microsoft Azure

Bill Gates e Paul Allen iniciaram a Microsoft como é conhecida hoje em 1975. Os primeiros
produtos desenvolvidos foram com foco em interpretadores de linguagens como BASIC
e FORTRAN. Em 1980 eles pivotaram a empresa para o ramo de desenvolvimento de
sistemas operacionais [39]. A Microsoft conta hoje com extenso e relevante catálogo de
produtos, dentre eles, serviços de hardware como consoles do Xbox, smartphones como
o Microsoft Lumia, e softwares como o sistema operacional Windows, e o pacote Office
(excel, powerpoint, word e outros). Além disso, há também o popular serviço de armaze-
namento em nuvem, chamado OneDrive.
Em outubro de 2008 a Microsoft iniciou seus investimentos na área de computação
em nuvem, fundando um dos três maiores provedores de serviços em nuvem, a Microsoft
Azure. A Azure, atualmente, disponibiliza mais de 200 produtos [40], entre eles:

• Azure Functions [41]: serviço orientado a eventos que permite a execução de códigos
sob demanda;

• Virtual Machines (VMs) [42]: possibilita alugar máquinas virtuais, disponibilizando

infraestrutura remota para utilização instantânea;

• Facial recognition (Face API) [43]: serviço de IA (Inteligência Artificial) para análise
de rostos em imagens;

8
 • Queue Storage [44]: enfileiramento para serviços de nuvem com grande volume;

• Azure Backup [45]: solução centralizada de backups para, por exemplo, evitar ata-
ques de ransomware [46], que é um tipo de malware utilizado para infectar sistema,
criptografando os dados do sistema afetado.

A rede global da Microsoft (WAN) é uma parte central do fornecimento de uma ex-
periência em nuvem. Ela conecta os datacenters da Microsoft em 61 regiões do Azure e
grande malha de nós de borda. Eles são posicionados estrategicamente em todo o mundo,
oferecendo assim a disponibilidade, a capacidade e a flexibilidade para atender a qualquer
demanda [4].

Figura 2.4: Rede global da Microsoft [4].

2.4 Modelos de Serviço

O National Institute of Standards and Technology (NIST) define três modelos principais de
serviços em nuvem: Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS),
e Software como Serviço (SaaS) [10]. Cada modelo de serviço possui diferentes níveis de
responsabilidade quanto à gestão necessária para desenvolver determinada aplicação.
Ao desenvolver sistema no modelo tradicional, toda responsabilidade de desenvolvi-
mento (rede, armazenamento, servidores, virtualização, sistema operacional, middleware,
ambiente, dados e aplicações) é de inteira responsabilidade do desenvolvedor da solução.
Contudo, ao adicionar camadas de serviço em nuvem, criam-se certos níveis de abstração.
Na Infraestrutura como Serviço (IaaS) toda parte de rede, armazenamento, servidores,

9
virtualização e sistema operacional ficam encapsulados e são oferecidos como serviço. Isso
reduz a carga de trabalho em relação à gestão da infraestrutura, como por exemplo, a
criação de diferentes máquinas virtuais pelo serviço Compute Engine [34]. Na Plataforma
como um Serviço (PaaS) o desenvolvedor preocupa-se apenas com os dados e as apli-
cações, tendo como exemplo a plataforma Heroku [47]. No Software como um Serviço
(SaaS) tem-se o usuário apenas utilizando a aplicação de forma final, como exemplo é
possível citar o Dropbox [48]. Nas próximas seções serão detalhados os principais tipos
de serviços em nuvem.

Figura 2.5: Comparação dos modelos de serviço definidos pelo NIST.

10
2.4.1 Infraestrutura como um Serviço
Na TI Tradicional a solução é completamente implementada pela equipe que está desen-
volvendo determinado sistema. Isso inclui a criação da infraestutura, da rede, do sistema
operacional, da aplicação, do armazenamento de dados, do tratamento de dados e das
aplicações propriamente ditas. Em outras palavras, a empresa não terceiriza a proprie-
dade sobre o sistema, pode terceirizar a mão de obra para desenvolver, mas possui total
propriedade sobre a infraestrutura e a solução [49].
As empresas que possuiam grande infraestrutura especializada, mas não utilizavam
todo o recurso disponível começaram a fazer o que é conhecido como colocation [50]. Isso
significa que essas empresas disponibilizaram seus datacenters para empresas menos robus-
tas, alugando a infraestrutura e disponibilizando o espaço para outras empresas alocarem
seus hardwares. As empresas de telefonia foram umas das precursoras desse modelo. O
colocation evoluiu para o hosting, tendo o local de armazenamento e a infraestrutura ne-
cessária, as empresas começaram a alugar servidores físicos. Isso permitiu disponibilizar
servidores sob contrato de acordo com a demanda da contratante.
A Infrastructure as a Service (IaaS) veio para evoluir o hosting, adicionando a vir-
tualização do modelo. Assim, foi adicionada uma camada de virtualização, tornando
uma solução em nuvem em que o cliente pode facilmente alugar uma infraestrutura re-
motamente de acordo com a sua demanda [51]. Normalmente, o modelo de serviço IaaS
apresenta-se no formato de máquinas virtuais, na qual o cliente contrata/aluga de acordo
com suas necessidades o hardware que configurará e utilizará. Dessa meneira, fica sob a
responsabilidade da contratante toda parte de escolha de sistemas operacionais, banco de
dados, desenvolvimento da aplicação e o tratamento dos dados.
Os produtos de Infrastructure as a Service possibilitam implantação de aplicações
escaláveis ao prover um serviço web, que permite ao cliente alugar máquinas virtuais para
rodar suas próprias aplicações. Alguns exemplos de produtos oferecidos pelos maiores
provedores de serviço de computação em nuvem são:

• AWS: Amazon Elastic Compute Cloud (Amazon EC2) [26];

• GCP: Compute Engine [34];

• Azure: Virtual Machines (VMs) [42].

2.4.2 Plataforma como um Serviço

A Plataforma como um Serviço (Platform as a Service (PaaS)) é um ambiente de desen-
volvimento e implantação totalmente disponibilizado na nuvem, ou seja, é um conjunto
de aplicativos para criar e gerenciar aplicações na nuvem [52].

11
 O PaaS possibilita uma camada de abstração na qual o desenvolvedor não necessita
preocupar com a infraestrutura. O serviço proporciona componentes de linguagem de
programação prontos para uso, assim como bibliotecas e ambientes que facilitem o desen-
volvimento de aplicações. Algumas soluções de Plataforma como Serviço são:

• Kubernetes Engine (GKE) [35]: auxilia a criação e gerência de aplicativos baseados

em contêiner, com tecnologia de código aberto Kubernetes;

• Amazon Elastic Beanstalk [53]: solução da AWS que axilia a criação e a disponibi-
lização de aplicativos, e APIS;

• Azure Cloud Services [54]: solução da Azure que auxilia a criação e a disponibilização
de aplicativos, e APIS.

2.4.3 Software como um Serviço

No Software como um Serviço (SaaS) a camada de abstração é ainda maior, pois o soft-
ware é inteiramente disponibilizado como um serviço [55]. Assim, a segurança dos dados, a
conectividade e os servidores necessários para o funcionamento do software são garantidos
pela empresa provedora. Tem-se então que o Software como um Serviço é a disponibili-
zação do serviço através de uma interface no formato web ou alguma outra interface de
sistema, com foco no usuário final. Alguns exemplos de Software como Serviço são:

• Google Drive: plataforma de armazenamento em nuvem;

• Netflix: plataforma de streaming de vídeos;

• Clicksign: plataforma de assinaturas digitais.

2.4.4 Tudo como um Serviço

Com a criação de novos serviços possibilitados pela computação em nuvem, a definição
de modelos de serviços criada pelo NIST [10] não conseguiu suprir e enquadrar os novos
serviços, sendo criada a definição de Tudo como um Serviço (do inglês Anything as a
Service [56].
A ideia da sigla é que o "X"de XaaS possa ser substituído por "qualquer"serviço, dando
lugar para qualquer outro serviço existente, tais como DataBase as a Service (DBaaS),
Communications as a Service (CaaS) ou outros. Alguns exemplos de serviços que não
se enquadraram nas definições do NIST, sendo também motivadores da criação do "qual-
quer"coisa como serviço são:

• Desktop as a Service (DaaS): oferece desktops virtuais aos usuários finais;

12
 • Network as a Service (NaaS): interliga diversos serviços baseados em nuvem;

• Monitoring as a Service (MaaS): sistema de monitoramento em tempo real com foco

em garantir performance, segurança e disponibilidade;

• Business Process as a Service (BPaaS): integra serviços, processos, aplicações e

infraestrutura para ampliação de negócios com redução de custos;

• Communications as a Service (CaaS): oferece serviços de comunicação, geralmente

ligados à telefonia como a distribuição automática de chamadas (ACD);

• Function as a Service (FaaS): é um tipo de serviço orientado a eventos altamente

elástico e escalável, será descrito em detalhes na próxima seção.

2.5 Função como um Serviço

O FaaS é a categoria de serviço de computação em nuvem orientada a eventos, ou seja,
fornece uma interface simples para implementação e execução de funções [57]. Como
citado, as funções são executadas por eventos (gatilhos), os triggers, que podem ser, por
exemplo, métodos HTTP. A Função como um Serviço está ganhando espaço no mercado
por se mostrar escalável, com alta disponibilidade e desempenho [58].
Outro ponto relevante que torna a solução atrativa é o custo sob demanda, a cobrança
do serviço é feita com base no tempo de execução das funções implementadas. O serviço
tira também qualquer responsabilidade que o cliente possa ter com infraestrutura, por
isso o FaaS é conhecido também como um serviço serverless (do português, sem servidor)
[57].
O FaaS é um serviço orientado a eventos, permitindo fácil integração com diferentes
outros serviços, visto que possibilita ampla modularidade. Cada funcionalidade a ser
implementada nesse modelo pode ser uma função separada. Assim, essa função pode servir
como gatilho para que outros serviços sejam executados. Da mesma forma, essa função
pode ser chamada por outros serviços ou até mesmo outras funções. É importante perceber
que, por ser um serviço sob demanda, quando os gatilhos não estão sendo acionados para
que a função seja executada, o serviço fica "em stand-by", evitando custos desnecessários.
Os produtos de função como serviço possibilitam implantação de aplicações escaláveis
ao prover um serviço web que permite ao cliente rodar suas próprias aplicações, em forma
de funções, sem se preocupar com a infraestrutura envolvida. Alguns exemplos de produ-
tos oferecidos pelos maiores provedores de serviço de computação em nuvem são: AWS
Lambda [27], Cloud Functions [33] e Azure Functions [41], os quais serão descritos em
detalhes, nas próximas seções.

13
 Apesar dos diversos benefícios apresentados, os serviços serverless possuem limitações
e questionamentos relevantes sobre os padrões adotados e a flexibilidade fornecida. O
artigo [59] apresenta críticas e problemas a serem resolvidos para que o Function as a
Service atinja todo o seu potencial. Dentre os problemas apresentados destaca-se o arma-
zenamento inadequado para operações de baixa granularidade, desempenho inadequado
para standard communication patterns, dificuldade em predizer o tempo de cold start por
depender de três principais variáveis: tempo para iniciar o serviço de função respectivo ao
provedor, inicialização do ambiente das funções (carregamento de bibliotecas) e o overhead
proporcionado pelo próprio código do usuário. Além desses assuntos em aberto, o artigo
também cita desafios que o FaaS deve resolver para potencializar o serviço fornecido, por
exemplo, é possível definir o tempo máximo de execução e a memória RAM utilizada,
porém impossibilita o gerenciamento de outros recursos como CPUs e GPUS. Portanto,
fica evidente que a tecnologia, que possui menos de uma década de existência, vem ama-
durecendo e precisará resolver diversos problemas atuais para atingir todo potencial que
a ideia nos permite almejar.

2.5.1 AWS Lambda

A AWS Lambda foi lançada em 2014, sendo o primeiro serviço de computação sem ser-
vidor (serverless) disponível no mercado. O serviço disponibiliza amplo suporte para as
linguagens de programação Javascript, C#, Java, Go, Ruby, PHP, e Python. Além das
linguagens com suporte nativo, pois a API Runtime da AWS permite a utilização de
praticamente qualquer outra linguagem.
É possível perceber também na AWS Lambda uma forte possibilidade de integração
com os demais serviços da AWS. Como por exemplo, ao implementar uma função, caso
queira utilizar um trigger HTTP, deve-se manualmente fazer o vínculo com o serviço API
Gateway [30] da Amazon. Esse comportamento não é visto nos provedores concorrentes,
uma vez que os triggers HTTP já vêm configurados. Outra forma de visualizar o forte
incentivo na integração dos serviços é, por exemplo, no Amazon S3 [28] que é possível
configurar que uma função seja acionada a cada vez que um novo arquivo for carregado
no S3. Assim, é possível perceber que vários outros serviços possuem forte incentivo em
suas conexões. Contudo, a AWS Lambda possui algumas limitações, como o tempo de
execução da função que não pode ser superior a 15 minutos [60].

2.5.2 Azure Functions

A Microsoft lançou o Azure Functions, serviço serverless, seguindo os passos da Amazon.
Esse serviço foi lançado em março de 2016, sendo o segundo grande provedor a disponibi-

14
lizar esse tipo de serviço. A Azure Functions possui forte integração com outros serviços
da Microsoft, sendo um de seus principais diferencias. As integrações vão desde linguagem
de programação, possibilitando fácil importação de funções em linguagens da Microsoft
como C# e F#.
Além disso, também é possível perceber uma grande facilidade em integrar com um dos
principais serviços da Microsoft, o pacote Office. Essa integração possibilita atualizações
automáticas nos documentos e planilhas, possibilitando ao usuário em potencializar o
uso dessas ferramentas. Além das linguagens próprias da Microsoft, o Azure Functions
possui suporte para outras linguagens de programação como PowerShell, Python, Java
nas versões 8 e 11, JavaScript (pacotes de Node) e TypeScript.

2.5.3 Cloud Functions

A Google foi a última empresa, entre os grandes provedores, a disponibilizar um serviço
serverless. O Cloud Functions possui suporte para as linguagens de programação Go,
Java, .NET C#, F#, Node.JS, Python e Visual Basic. Assim como no Azure Functions,
o Cloud Functions possui gatilhos (triggers) de forma nativa, facilitando a configuração
e a utilização das funções. A Cloud Functions possui o diferencial da possibilidade de
integração com o Firebase [61], que consiste em uma plataforma de criação de aplicativos
web e mobile.
A Google disponibilizou dois tipos diferentes de Cloud Functions, que são as HTTP
Functions e Background Functions. A diferença entre elas é justamente o trigger utili-
zado. As Background Functions são acionados por outros cloud events, ou seja, outro
servico da GCP aciona o serviço da Cloud Function, já as HTTP Functions são acionadas
normalmente por métodos HTTPs.

2.6 Custo Monetário do FaaS e IaaS

Os serviços de FaaS e IaaS são cobrados sob demanda. O IaaS tem uma cobrança mais
simples que leva em consideração o tempo em que a máquina virtual está alocada, apli-
cando sua cobrança por hora utilizada. A variação na cobrança de máquinas virtuais
acontece em máquinas que possuem recursos em modelos preemptivos, como é o caso da
GCP. Essa opção permite um compartilhamento de recursos e quando o provedor neces-
sita desse recurso, ele o torna indisponível para uso. A vantagem do modelo preemptivo
é o menor custo para um maior poder computacional, porém não existe garantia de am-
pla disponibilidade. Por isso, esse modelo não foi usado neste trabalho. A cobrança do
FaaS, por sua vez, apresenta maior complexidade, podendo ter em sua forma de cobrança

15
o tempo de utilização, a quantidade de requisições e a utilização de rede para envio de
dados.

2.6.1 Custo dos Serviços no Provedor AWS

IaaS

O EC2 da AWS, atualmente, dispõe de 557 diferentes tipos de máquinas virtuais com
diferentes capacidades de memória e processamento. O custo das máquinas virtuais são
calculados por demanda, sendo cobrado a hora que o recurso ficou alocado [62]. A AWS
disponibiliza um free tier que permite aos usuários utilizarem máquinas menos robustas
como a t1.micro de forma gratuita por um tempo determinado, a fim de testar o serviço
antes de uma contratação envolvendo custos monetários. As Tabelas 2.1 e 2.2 apresentam
algumas instâncias do serviço EC2 da AWS, assim como o seu custo por hora e por mês.

Tabela 2.1: Preço por hora do EC2.

Tipo de máquina CPUs virtuais Memória Preço (USD) / hora
t2.medium 2 4GB 0.0464 USD
t3.xlarge 4 16GB 0.1664 USD
t3.2xlarge 8 32GB 0.3328 USD
m4.4xlarge 16 64GB 0.8 USD

Tabela 2.2: Preço por mês do EC2.

Tipo de máquina CPUs virtuais Memória Preço (USD) / mês
t2.medium 2 4GB 33.872 USD
t3.xlarge 4 16GB 121.472 USD
t3.2xlarge 8 32GB 242.944 USD
m4.4xlarge 16 64GB 584 USD

FaaS

O AWS Lambda possui uma complexa definição de preço, levando em consideração o

intervalo da quantidade de recursos por segundo utilizado, a arquitetura, a quantidade
de solicitações, a simultaneidade provisionada, a transferência de dados na rede e outros
[5]. A AWS possui formas complexas de cálculo de diversos serviços e, por isso, tem uma
ferramenta própria para auxiliar no cálculo dos custos dos serviços disponibilizados [63].
A Figura 2.6 descreve o atual modelo de cobrança do AWS Lambda, que possui diferentes
valores para a arquitetura ARM e x86, além de ter cobranças específicas para duração

16
da execução e para a quantidade de requisições feitas. Na Tabela 2.3 é possível perceber
a evolução dos valores para as duas arquiteturas a medida que mais memória RAM é
requisitada.

Figura 2.6: Definição de preço do AWS Lambda [5].

17
 Tabela 2.3: Preço por milissegundo até 6 bilhões de GB-segundos/mês.
Memória (MB) Preço por 1 ms do x86 Preço por 1 ms do ARM
128 0,0000000021 USD 0,0000000017 USD
512 0,0000000083 USD 0,0000000067 USD
1.024 0,0000000167 USD 0,0000000133 USD
1536 0,0000000250 USD 0,0000000200 USD
2048 0,0000000333 USD 0,0000000267 USD
3072 0,0000000500 USD 0,0000000400 USD
4096 0,0000000667 USD 0,0000000533 USD
5120 0,0000000833 USD 0,0000000667 USD
6144 0,0000001000 USD 0,0000000800 USD
7168 0,0000001167 USD 0,0000000933 USD
8192 0,0000001333 USD 0,0000001067 USD
9216 0,0000001500 USD 0,0000001200 USD
10.240 0,0000001667 USD 0,0000001333 USD

2.6.2 Custo dos Serviços na GCP

IaaS

O Compute Engine possui uma forma de cobrança mais simplificada. O custo do serviço é
baseado no tempo de utilização, sendo que a cobrança é feita por hora utilizada. A GCP
possui um tipo diferente que é o preço preemptivo, que significa uma forma mais barata
de cobrança para utilização preemptiva de GPUs, ou seja, quando a GCP necessitar do
recurso, ela o tornará indisponível sem necessidade de aviso prévio e, por isso, possui um
valor menor [64]. As Tabelas 2.4 e 2.5 apresentam quatro tipos diferentes de instâncias
do serviço Compute Engine padrão E2, tendo seus valores detalhados por hora e por mês.

Tabela 2.4: Preço por hora das máquinas virtuais padrão E2.
Tipo de máquina CPUs virtuais Memória Preço (USD) Preço preemptivo (USD)
e2-standard-2 2 8GB $0.06701 $0.02010
e2-standard-4 4 16GB $0.13402 $0.04021
e2-standard-8 8 32GB $0.26805 $0.08041
e2-standard-16 16 64GB $0.53609 $0.16083

18
 Tabela 2.5: Preço por mês das máquinas virtuais padrão E2.
Tipo de máquina CPUs virtuais Memória Preço (USD) Preço preemptivo (USD)
e2-standard-2 2 8GB $48.92 $14.67
e2-standard-4 4 16GB $97.83 $29.35
e2-standard-8 8 32GB $195.68 $58.7
e2-standard-16 16 64GB $391.35 $117.41

FaaS

O Cloud Functions da GCP possui uma complexa forma de precificação de seu serviço,
o valor pode variar de acordo com o tempo de exeucação, quantidade de rede deman-
dada para transação de dados e quantidade de requisições realizadas [65]. Na Tabela 2.6
apresenta-se a evolução dos valores com o aumento da quantidade de memória disponibi-
lizada, enquanto na Tabela 2.7 apresenta o custo por milhão de requisições e, por fim, a
Tabela 2.8 descreve o custo pela utilização da rede para envio de dados. Nas Tabelas 2.9
e 2.10 tem-se um detalhamento de casos de uso com menor e maior demanda, tornando
mais factível o entendimento de qual seria um custo real ao final do mês.

Tabela 2.6: Preço por tempo de execução.

Memória vCPU Preço/100 ms (nível 1) Preço/100 ms (nível 2)
128 MB .083 vCPU US$ 0,000000231 US$ 0,000000324
256 MB .167 vCPU US$ 0,000000463 US$ 0,000000648
512 MB .333 vCPU US$ 0,000000925 US$ 0,000001295
1.024 MB .583 vCPU US$ 0,000001650 US$ 0,000002310
2.048 MB 1 vCPU US$ 0,000002900 US$ 0,000004060
4.096 MB 2 vCPU US$ 0,000005800 US$ 0,000008120

Tabela 2.7: Preço por quantidade de requisições.

Quantidade de invocações por mês Preço/milhão
Primeiros 2 milhões Gratuito
Após os 2 milhões US$ 0,40

19
 Tabela 2.8: Preço por uso de rede.
Tipo Preço/GB
Dados de saída US$ 0,12
Dados de saída por mês 5 GB gratuitos
Dados de entrada Gratuito
Dados de saída para APIs do Google na mesma região Gratuito

Tabela 2.9: Exemplo de custo de um caso de uso simples.

Métrica Valor bruto Nível gratuito Valor líquido Preço unitário Preço total
Invocações 10.000.000 2.000.000 8.000.000 US$ 0,0000004 US$ 3,20
GB-segundos 375.000 400.000 <0 US$ 0,0000025 US$ 0,00
GHz-segundos 600.000 200.000 400.000 US$ 0,0000100 US$ 4,00
Rede 0 5 0 US$ 0,12 US$ 0,00
Total/mês US$ 7,20

Tabela 2.10: Exemplo de custo de um caso de uso robusto.

Métrica Valor bruto Nível gratuito Valor líquido Preço unitário Preço total
Invocações 50.000.000 2.000.000 48.000.000 US$ 0,0000004 US$ 19,20
GB-segundos 6.250.000 400.000 5.850.000 US$ 0,0000025 US$ 14,63
GHz-segundos 10.000.000 200.000 9.800.000 US$ 0,0000100 US$ 98,00
Rede 238,42 5 233,42 US$ 0,12 US$ 28,01
Total/mês US$ 159,84

2.6.3 Custo dos Serviços na Azure

IaaS

O serviço Virtual Machines da Azure também apresenta uma forma de cobrança simples,
baseada on-demand, ou seja, a cobrança é feita por hora utilizada [66]. É possível encon-
trar centenas de tipos diferentes de máquinas virtuais, com valores desde $3.80 ao mês,
até máquinas virtuais com valores superiores a $3,000.00. A Tabela 2.11 detalha quatro
instâncias de máquinas virtuais com diferentes graus de poder computacional, mostrando
a evolução dos valores do serviço.

20
 Tabela 2.11: Preço por mês das máquinas virtuais padrão B.
Tipo de máquina CPUs virtuais Memória Preço (USD) / mês
B2s 2 4GB $30.36
B4ms 4 16GB $60.73
B8ms 8 32GB $121.18
B16ms 16 64GB $486.18

FaaS

A Azure Functions possui dois planos básicos de utilização, o plano premium e plano de
consumo. O plano de consumo é baseado no consumo de recursos e tempo de execução,
possuindo um plano de 400.000 GB/s no plano grátis. O plano premium, por sua vez,
tem sua cobrança baseada na duração da utilização dos recursos de memória e processa-
mento [67]. As Tabelas 2.12 e 2.13 detalham a forma de cobrança entre os dois planos
disponibilizados para contratação da Azure Functions.

Tabela 2.12: Plano Consumo.

Medidor Preço Concessão Gratuita (por mês)
Tempo de Execução* $0,000016/GB/s 400.000 GB/s
Total de Execuções* $0,20 por milhões de execuções 1 milhões de execuções

Tabela 2.13: Plano Premium.

Medidor Preço
Duração da vCPU vCPU: $0,173 vCPU/hora
Duração da memória Memória: $0,0123 GB/hora

Para um exemplo de cobrança na Azure Functions, imagine uma função com um

consumo de memória observado igual a 512 MB que foi executada 3.000.000 vezes durante
o mês, e teve uma duração de execução média de um segundo. A cobrança mensal do
consumo de recursos é calculada por meio dos itens apresentados na tabela 2.14 [67].
Por fim, na Tabela 2.15 detalha-se a cobrança baseada na quantidade de requisições e a
cobrança total é consolidada na Tabela 2.16, dando uma ideia de geral de qual seria o
valor mensal do caso demonstrado.

21
 Tabela 2.14: Cálculo de cobrança de consumo de recursos.
Consumo de recurso (segundos)
Execuções 3 milhões de execuções
Duração da execução (segundos) x 1 segundo
Total de consumo de recurso 3 milhões de segundos
Consumo de recurso (GB/s)
Consumo de recurso convertido em GBs 512 MB / 1.024 MB
Tempo de execução (segundos) x 3 milhões de segundos
Total de GB/s 1,5 milhões de GB/s
Consumo de recurso cobrável
Consumo de recurso 1,5 milhões de GB/s
Concessão gratuita mensal - 400.000 GB/s
Consumo cobrável total 1,1 milhões de GB/s
Custo mensal de consumo de recurso
Consumo de recurso cobrável 1,1 milhões de GB/s
Preço do consumo de recurso x $0,000016/GB/s
Custo total $17,60

Tabela 2.15: Cálculo de cobrança de execuções.

Execuções cobráveis
Total mensal de execuções
Execuções gratuitas mensais
Execuções cobráveis mensais
Custo de execuções mensal
Execuções cobráveis mensais
Preço por milhão de execuções
Custo de execução mensal
3 milhões de execuções
- 1 milhões de execuções
2 milhões de execuções
2 milhões de execuções
x $0,20
$0,40

Tabela 2.16: Cálculo de cobrança de consumo total.

Custo mensal total
Custo mensal de consumo de recurso $17,60
Custo de execuções mensal $0,40
Custo mensal total $18

22
2.7 Considerações Finais
Neste capítulo foram abordados os conceitos de computação em nuvem, assim como os
principais serviços e provedores de nuvem pública. Isso foi necessário para que haja um
amplo entendimento do objeto deste trabalho.
Assim sendo, no próximo capítulo serão apresentadas as funções escolhidas, por meio
do benchmark Faasdom [11], para realização dos testes que serão base para análise do
custo-benefício dos serviços de FaaS abordados neste trabalho.

23
Capítulo 3

Benchmark

Para atender ao objetivo deste trabalho em avaliar a relação custo-benefício entre os

serviços IaaS e FaaS oferecidos pelos grandes provedores de nuvem, adotou-se o uso do
benchmark FaaSdom [11]. Assim, a parte experimental consiste em proporcionar condições
semelhantes de teste com o objetivo de garantir máxima precisão nas análises e conclusões
obtidas sobre a relação custo-benefício do uso do FaaS versus IaaS.
Para estressar as funções e comparar como ambos os serviços performam em deter-
minadas condições de uso, foram escolhidas funções utilizadas pelo artigo "FaaSdom: A
Benchmark Suite for Serverless Computing"[11]. O artigo citado utiliza um benchmark,
testa as funções e disponibiliza os resultados em relação ao FaaS. Dessa forma, os testes
podem ser realizados em ambiente de nuvem nos três principais provedores [58], como
será apresentado neste capítulo.

3.1 FaaSdom
O FaaSdom [11] é uma arquitetura modular focada em aplicações serverless e foi imple-
mentado como uma prova de conceito de benchmark. O FaaSdom dá suporte aos pro-
vedores: AWS, Azure, GCP e IBM, possibilitando implementação de funções do tipo de
serviço FaaS de forma automática. A interface visual apresentada na Figura 3.1 permite
a implementação automática das funções e a execução automática de testes próprios do
FaaSdom, que proporcionam diversos insights através de uma dashboard no Grafana [68].
Os testes pré-implementados do FaaSdom são: Comparison Tests, Benchmark, Theorical
Pricing e Pricing regarding to tests. Para o teste de carga realizado neste trabalho, com
o intuito de estressar os ambientes de forma mais autônoma, foi utilizada a ferramenta
Apache Jmeter [69] que será melhor descrita na próxima seção.
No artigo FaaSdom [11], os autores utilizam as funções matrix, latency, filesystem e
factors para estressá-las em uma estrutura de FaaS. O objetivo foi obter mais dados sobre

24
o potêncial de performance de ambientes serverless. Para isso, as funções são implemen-
tadas em três diferentes linguagens de programação: Python, Node e Golang e além das
funções implementadas, o FaaSdom dá suporte para criação de funções customizadas para
ampliação dos casos de teste.

Figura 3.1: Interface Web do FaaSdom.

3.1.1 Função Latency

A função Latency é a mais simples de todas funções testadas. Ela apenas retorna um status
200, pois basicamente avalia tempo de resposta. Assim, essa função não tem nenhuma
operação de leitura ou escrita. O Código 1 apresenta a implementação da função Latency
na linguagem Golang, no qual é possível perceber que sua única ação é informar em caso
de erro, ou retornar a mensagem de sucesso.

25
func Go_latency(w http.ResponseWriter, r *http.Request) {
msg := &Message{
Success: true,
Payload: Payload{
Test: "latency test",
},
}
b, err := json.Marshal(msg)
if err != nil {
log.Fatal(err)
}
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(200)
fmt.Fprint(w, string(b))
}

Código 1: Função Latency implementada em Go [6].

3.1.2 Função Factors

A função Factors possibilita estressar o uso de CPU, visto que consiste em operações
matemáticas de raíz quadrada e divisão em um extenso array. O Código 2 apresenta a
implementação da função Factors na linguagem Node. Assim sendo, é possível perceber
uma alta demanda por CPU advinda de iterações com operações de raíz quadrada, append
no array, comparações através da estrutura condicional e divisões.

26
function factors(num) {
let n_factors = [];
for (let i = 1; i <= Math.floor(Math.sqrt(num)); i += 1)
if (num % i === 0) {
n_factors.push(i);
if (num / i !== i) {
n_factors.push(num / i);
}
}
n_factors.sort(function(a, b){return a - b;});
return n_factors;
}

Código 2: Função Factors implementada em Node [7].

3.1.3 Função Matrix

A função Matrix também estressa a utilização de CPU através da multiplicação de matri-
zes. Inicialmente, cria-se matrizes com valores aleatórios e faz-se uma extensa multiplica-
ção das duas matrizes geradas. O Código 3 apresenta a implementação da função Matrix
na linguagem Python, na qual é possível perceber uma função auxiliar que retorna uma
matriz quadrada (mesmo número de linhas e colunas) com valores numéricos aleatórios.
Com a utilização dessa função auxiliar chamada randomTable, duas matrizes são criadas
e a multiplicação dessas matrizes é feita, demandando processamento devido às interações
realizadas e as operações de multiplicação. A função Matrix retorna ainda uma terceira
matriz, que é a resultante da multiplicação das duas primeiras.

27
def randomTable(n):
return [[math.floor(random.random()*100) for i in range(n)] for j in range(n)]

def matrix(n):
matrixA = randomTable(n)
matrixB = randomTable(n)
matrixMult = [[0 for i in range(n)] for j in range(n)]

for i in range(0,len(matrixA)):
for j in range(0,len(matrixB)):
sum = 0
for k in range(0,len(matrixA)):
sum += matrixA[i][k] * matrixB[k][j]
matrixMult[i][j] = sum

return matrixMult

Código 3: Função Matrix implementada em Python [8].

3.1.4 Função Filesystem

A função Filesystem consiste na leitura e na escrita de arquivos (operações I/O). Assim
sendo, ela demanda muita memória RAM, possibilitando visualizar o estresse desse re-
curso. O Código 4 apresenta a implementação da função Filesystem na linguagem Node.
Neste trabalho, contudo, foi necessário utilizar uma versão com trechos omitidos no código
como algumas partes de declarações de variáveis e trechos de código menos importante,
a fim de que o código coubesse por inteiro em uma única página. Essas informações fo-
ram retiradas para que a função coubesse em uma única página devido a sua extensão.
É possível perceber que a função executa n operações de escrita e, posteriormente, de
leitura (I/O). Todas essas operações têm como objetivo estressar a utilização de memória
RAM. A função Filesystem, em caso de sucesso, retorna as métricas obtidas durante a
execução como: tempo de escrita, tempo de leitura, tempo total, além de retornar tam-
bém as informações referentes aos rescursos disponíveis como CPU e memória RAM. Os
arquivos acessados pela função filesystem são arquivos "nativos"do sistema, como os ar-
quivos /proc/cpuinfo, /proc/meminfo e /proc/uptime. O conteúdo desses arquivos são
utilizados para retornar informações referentes à configuração da máquina como memória
e processamento, por exemplo.

28
exports.node_filesystem = (req, res) => {
var instanceId = fs.readFileSync( /proc/self/cgroup , utf-8 );
var cpuinfo = fs.readFileSync( /proc/cpuinfo , utf8 );
var meminfo = fs.readFileSync( /proc/meminfo , utf8 );
var uptime = fs.readFileSync( /proc/uptime , utf-8 );
...
fs.mkdirSync( /tmp/test );
fs.mkdirSync( /tmp/test/ +rnd);
for(let i = 0; i<n; i++) {
fs.writeFileSync( /tmp/test/ +rnd+ / +i+ .txt , text, utf-8 );
}
for(let i = 0; i<n; i++) {
var test = fs.readFileSync( /tmp/test/ +rnd+ / +i+ .txt , utf-8 );
}
let files = fs.readdirSync( /tmp/test/ +rnd);
rimraf.sync( /tmp/test/ +rnd);
res.send(JSON.stringify({
success: files.length == n,
payload: {
"test": "filesystem test",
"n": files.length,
"size": Number(size),
"timewrite": (endWrite-startWrite).toFixed(3),
"timeread": (endRead-startRead).toFixed(3),
"time": ((endWrite-startWrite)+(endRead-startRead)).toFixed(3)
},
metrics: {
machineid: ,
instanceid: instanceId,
cpu: cpuinfo,
mem: meminfo,
uptime: uptime
}
}));
};

Código 4: Versão com trechos omitidos da Função Filesystem implementada em Node [9].

29
3.2 Ferramenta de Teste
O Apache Jmeter [69], ferramenta escolhida para realização dos testes neste trabalho,
consiste em um facilitador de testes de carga. O Jmeter é útil para estressar aplicações
e avaliar sua performance [70]. No contexto da avaliação do custo-benefício de Infras-
tructure as a Service versus Function as a Service, o Jmeter desempenhou a função de
um lançador de requisições, retornando informações relevantes como tempo de execução,
latência, percentual de casos bem sucedidos e outros.
O Jmeter foi escolhido para viabilizar o benchmark do presente trabalho por ser uma
ferramente de testes open source e validada no mercado por meio, também, de referências
em outros trabalhos acadêmicos. Assim sendo, através do Jmeter é possível simular o
comportamendo de uma pessoa interagindo com um sistema, deixando o cenário de teste
mais próximo de uma situação real. A ferramenta possibilita a exportação de arquivos no
formato CSV com todos os dados obtidos, assim como gráficos.
Para avaliar a performance dos ambientes se fez necessário um teste de carga, no qual
foi escolhido o disparo de requisições em Base 2. Assim, foram efetuados diferentes casos
de testes com variadas quantidades de requisições, as quais foram desde 1 requisição até
512 requisições. Dessa forma, foi possível realizar testes de menor carga até testes que, de
fato, estressaram a aplicação. O intervalo experimentado para disparo dessas requisições
foi um ramp-up de 30 segundos, visto que um tempo inferior a esse gera uma sobrecarga
que inviabiliza que as máquinas virtuais escolhidas suportem alguns casos de testes.

3.3 Ambiente de Testes

Conforme ilustrado na Figura 3.2, para testar os serviços de FaaS e IaaS, com o intuito
de analisar o custo-benefício, fez-se necessário proporcionar condições iniciais de teste
mais semelhantes quanto possível para que fosse feita uma comparação justa. O FaaS-
dom proporciona uma interface facilitada de deploy das funções escolhidas para fazer o
teste, sendo necessário apenas configurar o teste de carga no Jmeter com os endpoints
proporcionados pelas funções.
O ambiente de IaaS, por sua vez, não possui nenhuma facilidade adicional nativa, sendo
necessário toda configuração manual e criação das APIs utilizadas. Para criar uma confi-
guração automatizada seria necessário utilizar serviços auxiliares como o CloudFormation
[71] ou Terraform [72], que podem ser utilizados para facilitar o processo de configuração
e provisionamento de máquinas virtuais, as ferramentas citadas não foram utilizadas mas
seriam uma boa adição ao processo. Com intuito de reduzir o impacto da variável distan-
cia geográfica (consequentemente, a latência) no testes, eles foram inteiramente na mesma

30
zona geográfica em cada provedor testado. Dessa maneira, os testes foram disparados e
recebidos o mais próximo possível, geograficamente.

Figura 3.2: Diagrama do fluxo de testes.

3.3.1 Serviço FaaS

A Figura 3.3 apresenta a facilidade proporcionada pelo FaaSdom ao implantar funções nos
provedores testados. Assim sendo, como pode ser observado na Figura 3.3 é necessário
apenas escolher a função, a linguagem de programação desejada, a memória inicial da
função, o provedor e a zona de disponibilidade.
A memória inicial escolhida foi de 2048MB para que também fossem escolhidas má-
quinas virtuais de 2GB de memória, tendo um recurso mínimo suficiente para suportar
a maior parte dos casos de teste. A versão final das funções nos provedores AWS, Azure
e GCP ficaram conforme as Figuras 3.3, 3.4 e 3.5. Por não possuir um suporte nativo
para a linguagem Golang no Azure Functions, não foi possível testar essa linguagem no
provedor Azure.

31
Figura 3.3: Deploy da função filesystem no FaaSdom.

Figura 3.4: Versão final das funções na AWS.

32
 Figura 3.5: Versão final das funções na GCP.

Figura 3.6: Versão final das funções na Azure.

3.3.2 Serviço IaaS

Para proporcionar o mesmo poder computacional inicial configurado no tipo de serviço
FaaS, foi necessário a criação de instâncias de máquinas virtuais que serviram para hospe-
dar uma API REST [73], que é uma interface da aplicação fornecida através do protocolo
HTTP. Dessa forma, fez-se necessário o desenvolvimento de uma API para cada linguagem
de programação utilizada [74]. Para a linguagem de programação Node.js foi utilizado o
framework Express [75], para a linguagem de programação Golang foi utilizado o package
HTTP [76], e para a linguagem de programação Python foi utilizado o framework Flask
[77]. O sistema operacional escolhido para as máquinas virtuais foi o Ubuntu Server 20.04
LTS
O sistema operacional escolhido foi o Ubuntu Server 20.04 LTS e as máquinas virtuais
instanciadas foram escolhidas de forma que a máquina que fosse disparar os testes não
encontrasse gargalos de memória e processamento. Portanto, foram escolhidas máquinas
com 16GB de memória e 4 vCPUs. Para as máquinas que hospedaram as APIs, optou-se
por utilizar 2GB de memória (a mesma quantidade inicial das funções do FaaS) e 1 vCPU.
No provedor Azure não foi possível encontrar uma máquina com essas especificações,

33
portanto foi necessário utilizar uma máquina com 0,5vCPU, o que já a coloca em uma
situação inicial de desvantagem. As máquinas escolhidas em cada provedor foram as
especificadas na Tabela 3.1.

Tabela 3.1: Máquinas virtuais utilizadas nos testes.

Provedor Função da VM Nome Memória (GiB) vCPUs
AWS Enviar requisições t2.xlarge 16 4
AWS API t2.small 2 1
Azure Enviar requisições e2-standard-4 16 4
Azure API e2-small 2 0.5
GCP Enviar requisições Standard D4s v3 16 4
GCP API Standard B1ms 2 1

Diferentemente do deploy das funções do tipo de serviço FaaS que foram facilmente
implementadas pelo FaaSdom, para cada provedor foi necessária a alocação manual das
máquinas virtuais utilizadas nos testes. Após instanciar a máquina de disparo dos testes
foi necessário preparar todo ambiente com a instalação da linguagem Java, para suportar
a utilização do Apache Jmeter, assim como também fazer a instalação do Jmeter. Para
a máquina que hospeda as APIs, foram necessárias as intalações do Docker [78] e do
Docker Compose [79]. Essas ferramentas facilitaram a disponibilização das APIs através
de containers que permitiam deixar as portas expostas dentro da própria máquina virtual,
facilitando dessa forma as chamadas via protocolo HTTP para as portas expostas no
container por meio das APIs.

3.4 Considerações Finais

Neste capítulo foi abordado o benchmark FaaSdom [11], o qual foi usado para avaliar as
funções específicas para a obtenção de dados que serão utilizados para análise do custo-
benefício de FaaS versus IaaS. Além disso, também foi abordado o ambiente criado para
os testes, mostrando quais ações foram tomadas para aproximar o máximo possível as
condições de teste. No próximo capítulo serão abordados os resultados obtidos por meio
dos testes aplicados, bem como uma análise sobre esses resultados.

34
Capítulo 4

Resultados

Como apresentado no Capítulo 3 foram preparados ambientes semelhantes de testes le-

vando em consideração a particularidade de cada serviço avaliado. O objetivo era garantir
um ambiente de teste o mais semelhante possível, a fim de obter resultados justos. Os
testes de carga foram disparados através da ferramenta Jmeter a qual retorna os resulta-
dos em arquivos csv prontos para serem utilizados na geração das estatísticas e gráficos,
como os na Figura 4.1. O Jmeter possui uma boa interface visual para interação, po-
rém os testes foram realizados em sua totalidade através de Command-line interface (do
português, interface de linha de comandos).
Para disparar os testes através desse tipo de interface, o Jmeter oferece facilidades
como a possibilidade de criar variáveis e também de gerar gráficos e tabelas a partir do
arquivo csv gerado pelo próprio software (Código 5). O Código 6 é um exemplo de código
que executa o Jmeter através da CLI, nele é possível perceber variáveis que definem qual
a URL que será chamada, o nome do arquivo no qual serão salvas as informações geradas,
a porta em que a aplicação está exposta, a rota da aplicação para executar a função
de teste, a concorrência de requisições, o timeout e o ramp-up. O Código 7 permitiu
o download remoto a partir da máquina virtual de disparos, ou seja, os resultados que
estavam armazenados na máquina virtual de determinado provedor puderam ser enviadas
remotamente para uma máquina local.

./jmeter -g ./path/output.csv -o ./path/html

Código 5: Exemplo de execução do Jmeter através de CLI para gerar tabelas e gráficos a
partir dos resultados.

35
./apache-jmeter-5.4.1/bin/jmeter -n -t input.jmx -Jurl= 20.124.129.42
-Jfilename= filesystem -Jport= 2000 -Jpath= /filesystem -Jreq= 1
-Jname= Azure - filesystem - -Jhttp= http -Jsec= 30 -Jtimeout="33000"

Código 6: Exemplo de execução do Jmeter através de CLI.

scp -i ~/Downloads/sendgcp
sendgcp@34.86.60.101:~/reports/*.csv
./GCP/Go/FaaS/latency/

Código 7: Exemplo de comando CLI para fazer cópia de arquivos remotamente.

Figura 4.1: Exemplo de tabela gerada no HTML por meio do Jmeter.

4.1 Análise do Desempenho

Por meio dos resultados obtidos na Figura 4.2, notou-se que para níveis de menor con-
corrência, o resultado obtido para funções menos complexas computacionalmente como a
latency e matrix se mostraram mais vantajosas no IaaS em comparação ao FaaS. Porém,
a medida que os níveis de concorrência foram aumentando, somente a função latency teve
um desempenho melhor no IaaS. A partir do resultado obtido também fez-se necessário
analisar melhor a curva do FaaS para avaliar se o overhead apresentado nos casos de

36
níveis mais baixos de concorrência aconteceriam em outros cenários também, a fim de
comparação observou-se também curvas de testes com intuitos semelhantes apresentadas
no artigo [80]. O recorte mais detalhado das curvas será estudado adiante neste capítulo.

Figura 4.2: Resultado de desempenho agrupado por função.

A partir dos resultados obtidos, optou-se por agrupar os resultados por provedor,
visando avaliar quanto o desempenho pode ser afetado entre os diferentes provedores
testados. Assim sendo, na Figura 4.3 foi possível perceber um padrão semelhante à
Figura 4.2 que mostra o FaaS performando melhor do que o IaaS em tempo de resposta,
quando comparado o resultado agrupado por provedor, ou seja, ao somar o resultado
de todas as funções de cada tipo de serviço. Os resultados apontaram para a Azure
como sendo o melhor provedor para IaaS, enquanto a AWS foi identificada como o melhor
provedor de FaaS. Porém, o resultado apresentado não levou em consideração que a Azure
não conseguiu executar os testes de maior tempo de resposta, tornando o resultado injusto
para os provedores que conseguiram executar essas funções, esse dado foi considerado na
análise de taxa de erros na Seção 4.2.

37
 Figura 4.3: Resultado de desempenho agrupado por provedor.

Outro recorte feito foi o agrupamento dos resultados por linguagem de programação
na Figura 4.4. Nessa figura é possível perceber que IaaS na linguagem golang obteve um
resultado expressivamente melhor do que todos os outros, enquanto IaaS em Python teve
um resultado oposto, obtendo o pior desempenho experimentado. O serviço de FaaS em
todas as linguagens obteve um tempo médio de resposta melhor do que os de IaaS para
512 requisições, perdendo somente para IaaS em go. Os gráficos mostram que em todos os
casos anteriores o FaaS começa com certa desvantagem, isso acontece pelo característica
do tipo de serviço que apresenta um maior cold start (tempo de inicialização), agregando
um overhead considerável para os casos iniciais. Todavia, para casos mais robustos,
percebe-se que a escala do serviço supora esse custo computacional inicial.

38
 Figura 4.4: Resultado de desempenho agrupado por linguagem de programação.

4.1.1 Análise de Casos Específicos de Tempo Médio de Resposta

Com o intuito de entender melhor as curvas obtidas nos ambientes de FaaS e IaaS, os
resultados foram agrupados em casos que não ocorreram nenhum erro. Assim sendo, os
resultados foram separados por funções mais complexas computacionalmente (factors e
filesystem), e funções que demandam menos recursos (latency e matrix). Nas Figuras 4.5
e 4.6 é possível perceber um comportamento próximo ao esperado, isto é conforme a de-
manda vai aumentando, o FaaS automaticamente escala para suprir toda a demanda. Em
contrapartida, o IaaS tem seu recurso definido e limitado pela máquina virtual escolhida,
de forma que ao aumentar a concorrência, o desempenho fica cada vez pior. Nos gráfi-
cos apresentados é importante perceber que na função factors houve um pico inesperado
para as 256 requisições, que é um comportamento fora do esperado e pode ter ocorrido
por algum comportamento determinado pelo provedor, ou por alguma falha no momento
testado.

39
 Figura 4.5: Função filesystem. Figura 4.6: Função factors.

Nas Figuras 4.7 e 4.8 o overhead inicial se mostrou novamente muito expressivo, fa-
zendo com que a curva do FaaS ficasse bem diferente do caso anterior. Outro ponto que
chamou a atenção foi o IaaS performando muito melhor nos dois casos de teste de me-
nor complexidade. Como citado anteriormente, os testes foram executados utilizando um
ramp-up de 30 segundos, ou seja, o disparo das requisições não são enviados instantâne-
amente e sim em um intervalo de 30 segundos. O resultado, por ser muito diferente do
esperado, tornou necessário que o teste para o caso de menor demanda computacional
fosse refeito sem o ramp-up para que fosse possível comparar os casos e verificar se o
padrão se mantém.

Figura 4.7: Função latency. Figura 4.8: Função matrix.

Para fins comparativos da questão citada anteriormente envolvendo a utilização do

ramp-up de 30 segundos, o gráfico da Figura 4.9 foi gerado através da média dos resultados
da função filesystem nas linguagens de programação Node, Python e Golang. Nesse caso,
foi possível perceber que para o caso em que o ramp-up foi utilizado o overhead inicial
realmente foi relevante, fazendo com que a curva fique acima do caso em que o ramp-up

40
não foi utilizado até o caso de 128 concorrências. Entretanto, para os casos mais extremos
a não utilização do ramp-up se demonstrou mais custosa em tempo médio de resposta e,
para isso, acredita-se que a função escalou de forma mais lenta. Para o caso em que o
ramp-up foi utilizado, a função por ter um tempo de envio das requisições mais espaçado,
notou-se que o FaaS foi capaz de se preparar melhor para os casos de maior carga de
trabalho e demanda computacional.

Figura 4.9: Resultado comparativo do uso de ramp-up para a função latency.

Ainda explorando o caso de testes da função latency, sem a utilização de ramp-up,

o teste foi expandido para o provedor GCP, além da AWS, e a função matrix também
foi incluída. Na Figura 4.10 é possível perceber um resultado de utilização de FaaS
mais próximo da curva esperada de acordo com o artigo [80]. Apesar da escalabilidade
proporcionada pelo FaaS, a medida que a concorrência aumenta de forma abrupta, é
esperado que o serviço tenha um maior tempo de resposta. Apesar do resultado ter
ficado mais próximo do artigo referência, o tempo de resposta aumentou de forma muito
expressiva do caso de 128 requisições simultâneas em diante, o que causa certa estranheza
no resultado obtido.

41
 Figura 4.10: Resultado comparativo do uso de ramp-up para a função latency.

4.2 Análise da Taxa de Erros

Na Figura 4.11 é possível perceber que o tipo de serviço IaaS performou de forma menos
satisfatória do que o tipo de serviço FaaS. Esse resultado se deve ao fato de que para a
maior parte dos casos que demandaram mais poder computacional, as funções filesystem
e factors, o serviço não conseguiu entregar algum tipo de resultado. Dessa forma, para
uma maior confiabilidade na utilização do serviço, faz-se necessário a utilização de má-
quinas mais robustas, tendo que conhecer bem o ambiente em que será aplicado o serviço.
Um outro ponto importante é utilizar alguma ferramenta que permita a escalabilidade
e a elasticidade do IaaS, permitindo que o ambiente fique mais próximo ao que o FaaS
proporciona. Exemplos de ferramentas que permitem esse tipo de comportamento são o
Docker [78] com a utilização de Continuous Delivery (CD), Kubernetes [81] ou os autos-
cales proporcionados em conjunto com a configuração do tipo de serviço IaaS dos próprios
provedores, como o Amazon EC2 Auto Scaling [?].

42
 Figura 4.11: Taxa de erro agrupado por função.

Ao agrupar os erros por provedor, percebe-se novamente que todos os provedores

apresentam uma taxa de erro maior para o tipo de serviço IaaS. O resultado ocorre
pela capacidade das máquinas virtuais escolhidas que, para simular a capacidade inicial
das funções de FaaS, são insuficientes para executar as funções escolhidas no benchmark
FaaSdom [11]. Dentro desse cenário, destaca-se o provedor Azure que apresenta um
desempenho pior do que todos os outros. Além disso, durante a realização dos testes
também foi possível perceber um menor tempo de conexão via CLI. O provedor AWS
foi o que apresentou melhor desempenho, tendo apresentado, na maior parte dos casos,
menor tempo médio de resposta e também uma menor taxa de erros.

43
 Figura 4.12: Taxa de erro agrupado por provedor.

Avaliando a taxa de erros por linguagem de programação apresentado na Figura 4.13,

percebe-se que em ambos os cenários a linguagem Python apresentou pior desempenho.
Contudo, entre as linguagens Golang e Node não houve uma que performou melhor do
que a outra em ambos cenários, tendo a Node performado melhor no IaaS, e a Golang
performado melhor em FaaS.

44
 Figura 4.13: Taxa de erro agrupado por linguagem de programação.

4.2.1 Casos Específicos com Alto Indíce de Erro

Para aumentar a transparência dos dados levados em consideração nos resultados desta
seção, fez-se necessário ressaltar que na Azure não foram executados testes em Golang
por limitações do serviço de FaaS do provedor. Além disso, é importante ressaltar que
algumas funções não foram possíveis de serem executadas em determinado ambiente. Com
objetivo de realizar uma análise justa, todos os casos que puderam afetar os resultados
foram listados abaixo em formato de tabela para melhor visualização. Esses resultados
também foram levados em consideração em todo o Capítulo 4.

45
 Tabela 4.1: Taxas de erro acima de 50% na AWS.
Python Golang Node
Latency - IaaS 0,00% 0,00% 0,00%
Latency - FaaS 0,04% 0,00% 0,00%
Filesystem - IaaS 0,00% 100% 0,00%
Filesystem - FaaS 0,01% 0,00% 0,00%
Factors - IaaS 100% 0,00% 0,00%
Factors - FaaS 96,83% 0,00% 0,00%
Matrix - IaaS 0,00% 0,00% 0,00%
Matrix - FaaS 0,00% 0,00% 0,00%

Tabela 4.2: Taxas de erro acima de 50% na Azure.

Python Golang Node
Latency - IaaS 0,00% Não executado 0,00%
Latency - FaaS 0,00% Não executado 0,00%
Filesystem - IaaS 96,77% Não executado 100%
Filesystem - FaaS 90,74% Não executado 0,00%
Factors - IaaS 100% Não executado 1,89%
Factors - FaaS 85,38% Não executado 0,00%
Matrix - IaaS 0,00% Não executado 0,00%
Matrix - FaaS 1,24% Não executado 0,00%

Tabela 4.3: Taxas de erro acima de 50% na GCP.

Python Golang Node
Latency - IaaS 0,00% 0,00% 0,00%
Latency - FaaS 0,00% 0,00% 0,00%
Filesystem - IaaS 98,51% 100% 0,00%
Filesystem - FaaS 0,00% 0,00% 0,00%
Factors - IaaS 100% 0,00% 100%
Factors - FaaS 0,00% 0,00% 0,00%
Matrix - IaaS 21,88% 0,00% 0,00%
Matrix - FaaS 0,00% 0,00% 0,00%

46
4.3 Considerações Finais
Neste capítulo foram apresentados os experimentos realizados para avaliar o custo-benefício
da utilização de FaaS e IaaS. Por meio dos resultados obtidos, fez-se uma análise do tempo
médio de resposta e também das taxas de erros. Concluiu-se que para os casos que de-
mandam recursos computacionais que o tipo de serviço IaaS consegue proporcionar, tais
como a função latency, ele garante maior performance considerando os cenários testados.
Entretanto, para funções com maior demanda por recursos computacionais, o IaaS não
conseguiu um desempenho mínimo satisfatório, perdendo para o FaaS nesses casos. O
próximo capítulo tratará das conclusões alcançadas neste trabalho e os passos futuros, de
modo a alcançar resultados mais específicos para os tipos de serviço testados.

47
Capítulo 5

Conclusão

Neste trabalho foram apresentados os conceitos de computação em nuvem, assim como

a forma que esse paradigma é classificado de acordo com o NIST, sendo separado em
três principais categorias que são IaaS, PaaS e SaaS. Contudo, a definição do NIST,
atualmente, não engloba todos os serviços proporcionados pela computação em nuvem,
como é o caso, por exemplo, do FaaS [82].
O FaaS é um tipo de serviço que possibilita a implementação de partes específicas de
um sistema, as funções, e se mostram com alta capacidade de elasticidade e escalabilidade.
Além disso, foram apresentados os principais provedores de nuvem pública e a ferramenta
Jmeter, que foi utilizada para realização de testes de carga nas funções apresentadas pelo
benchmark FaaSdom [11].
A partir dos resultados obtidos, concluiu-se que para aplicações que demandam pouco
recurso computacional, faz sentido utilizar o tipo de serviço IaaS, pois caso ele consiga en-
tregar todo o recurso computacional solicitado, apresenta um bom desempenho. Contudo,
para casos que o IaaS não consiga conceder todo recurso solicitado, ele não funcionará.
Uma solução para esse caso é a implementação de um sistema de escalabilidade automá-
tica, que pode ser feito através, por exemplo, do Docker [78], Kubernetes [81] ou serviço
equivalente de auto scaling proporcionado pelo respectivo provedor. Os cenários de testes
aplicados retornaram uma quantidade extensa de erros, principalmente, para o tipo de
serviço IaaS nas funções factors e filesystem, tornando inviável uma avaliação monetária
somente com os dados obtidos.
A fim de obter a análise desejada, foram avaliados também os casos de erros retornados
pelos testes, assim como o custo individual de cada tipo de serviço nos três provedores
avaliados em um cenário mais genérico (o custo bruto dos serviços). Assim sendo, pode-se
concluir que o FaaS é uma ferramenta muito poderosa e que entrega muito poder com-
putacional. Logo, para se obter o desempenho equivalente no tipo de serviço IaaS, faz-se
necessário uma configuração e conhecimento técnico altamente específico. Portanto, para

48
funções mais simples, vale a pena escolher máquinas virtuais que atendam a demanda,
porém, caso seja necessário escalar a aplicação, haverá algum trabalho envolvido. No
FaaS, tem-se o trade-off que não será necessário nenhum trabalho para que essa escala
aconteça, porém envolve um maior custo monetário nesse conforto proporcionado.
É importante ressaltar também algumas limitações enfrentadas durante a fase de tes-
tes que pode ter influenciado os dados obtidos de alguma forma. Entre as limitações
observadas destaca-se a pequena amostra de máquinas virtuais utilizadas na experimen-
tação do tipo de serviço IaaS, esse tipo de serviço possui diversos conjuntos de máquinas
virtuais, possibilitando escolher uma ampla combinação de recursos computacionais pré
disponibilizados e permitindo personalização das configurações da VM caso as configu-
rações existentes não satisfaçam a demanda. Os testes foram realizados ao decorrer da
semana em diferentes dias e horários, dessa forma, torna-se mais provável que alguns
testes tenham sido realizados em horário de maior congestionamento, enquanto outros
testes foram feitos em horários com menor demanda da nuvem utilizada. Entre as limi-
tações observadas no presente trabalho também destaca-se a comparação feita entre os
resultados obtidos, toda comparação foi feita com base em valores médios utilizando um
conjunto de dez medições, a quantidade de amostras utilizadas para cada valor médio é
baixa, tornando suscetível que em algum caso tenha valores discrepantes que atrapalhem
a análise dos resultados. Dessa forma, uma sugestão para trabalhos futuros é que outras
avaliações sejam utilizadas para aumentar a robustez da análise, como por exemplo, o uso
de percentil.
Em trabalhos futuros será avaliado de forma mais específica o impacto do ramp-up
na utilização do FaaS e IaaS, pois o ramp-up simula uma situação em que usuários estão
acessando o serviço de forma mais espaçada, enquando o não uso dele representa um ce-
nário de acesso simultâneo. Além disso, é importante simular um ambiente de IaaS ainda
mais próximo que o de FaaS para tornar a comparação justa, isso pode ser feito por meio
da implementação de um ambiente que em que o IaaS proporcione escalabilidade e elas-
ticidade, assim como o FaaS, tornando possível uma comparação e conclusão próxima de
cenários reais de uso de ambos os tipos de serviço. Sugere-se também que sejam avaliados
cenários mais próximos aos dos ambientes de produção em relação ao armazenamento de
arquivos ao testar o desempenho de filesystem utilizando banco de dados serverless, como
por exemplo o DynamoDB [29], object storage e serviços de fila como o SQS [83].

49
 Referências

[1] Bala, Raj, Bob Gill, Dennis Smith, Kevin Ji e David Wright: Quadrante Mágico
para infraestrutura em nuvem e serviços de plataforma. Relatório Técnico, Gart-
ner. https://www.gartner.com/technology/media-products/reprints/AWS/
1-271W1OT3-PTB.html, acesso em 2022-02-08. ix, 5

[2] Mapa da infraestrutura global da AWS. https://aws.amazon.com/pt/about-aws/

global-infrastructure/?nc1=h_ls, acesso em 2022-07-08. ix, 6, 7

[3] GCP: Cloud locations. https://cloud.google.com/about/locations#regions,

acesso em 2022-07-08. ix, 8

[4] Azure: Rede global da Microsoft. https://docs.microsoft.com/pt-br/azure/

networking/microsoft-global-network, 07/08/2022. ix, 9

[5] AWS Lambda: Pricing. https://aws.amazon.com/pt/lambda/pricing/, acesso em

2022-12-09. ix, 16, 17

[6] Github: Função Latency em Go. https://github.com/Bschitter/

benchmark-suite-serverless-computing/blob/master/google/src/go/
latency/latency.go, acesso em 2022-08-16. x, 26

[7] Github: Função Factors em Node. https://github.com/Bschitter/

benchmark-suite-serverless-computing/blob/master/google/src/node/
factors/index.js, acesso em 2022-08-16. x, 27

[8] Github: Função Matrix em Python. https://github.com/Bschitter/

benchmark-suite-serverless-computing/blob/master/google/src/python/
matrix/main.py, acesso em 2022-08-16. x, 28

[9] Github: Função Filesystem em Node. https://github.com/Bschitter/

benchmark-suite-serverless-computing/blob/master/google/src/node/
filesystem/index.js, acesso em 2022-08-16. x, 29

[10] Mell, Peter e Timothy Grance: The NIST Definition of Cloud Computing. página 7.
1, 4, 9, 12

[11] Maissen, Pascal, Pascal Felber, Peter Kropf e Valerio Schiavoni: FaaSdom: A
Benchmark Suite for Serverless Computing. Em Proceedings of the 14th ACM In-
ternational Conference on Distributed and Event-Based Systems, DEBS ’20, pá-
ginas 73–84, New York, NY, USA, 2020. Association for Computing Machin-

50
 ery, ISBN 978-1-4503-8028-7. https://doi.org/10.1145/3401025.3401738, event-
place: Montreal, Quebec, Canada. 2, 23, 24, 34, 43, 48

[12] Surbiryala, Jayachander e Chunming Rong: Cloud Computing: History and Overview.
Em 2019 IEEE Cloud Summit, páginas 1–7, 2019. 3

[13] Rajaraman, V: Cloud computing. Resonance, 19(3):242–258, 2014. Publisher:

Springer. 3

[14] Puthal, Deepak, Bibhudutta PS Sahoo, Sambit Mishra e Satyabrata Swain: Cloud
computing features, issues, and challenges: a big picture. Em 2015 International
Conference on Computational Intelligence and Networks, páginas 116–123. IEEE,
2015. 3

[15] Jin, Hai, Shadi Ibrahim, Tim Bell, Wei Gao, Dachuan Huang e Song Wu: Cloud types
and services. Em Handbook of cloud computing, páginas 335–355. Springer, 2010. 4

[16] Amazon Web Service: Homepage. https://aws.amazon.com/pt/, acesso em 2022-

02-08. 5

[17] Azure Microsoft: Homepage. https://azure.microsoft.com/pt-br/, acesso em

2022-02-08. 5

[18] Google Cloud Platform: Homepage. https://console.cloud.google.com, acesso

em 2022-02-08. 5, 7

[19] Tencent Cloud: Homepage. https://intl.cloud.tencent.com/pt/, acesso em

2022-02-08. 5

[20] IBM: Homepage. https://www.ibm.com/br-pt/cloud, acesso em 2022-02-08. 5

[21] Oracle: Homepage. https://www.oracle.com/br/cloud/, acesso em 2022-02-08. 5

[22] Alibaba Cloud: Homepage. https://us.alibabacloud.com, acesso em 2022-02-08.

5

[23] AWS: Regiões e zonas de disponibilidade. https://aws.amazon.com/pt/about-aws/

global-infrastructure/regions_az/, acesso em 2022-07-08. 5

[24] Varia, Jinesh, Sajee Mathew e others: Overview of amazon web services. Amazon
Web Services, 105, 2014. 6

[25] Produtos da nuvem AWS. https://aws.amazon.com/pt/products/, acesso em

2022-03-08. 6

[26] Amazon EC2. https://aws.amazon.com/pt/ec2/?nc1=h_ls, acesso em 2022-03-08.

6, 11

[27] AWS Lambda. https://aws.amazon.com/pt/lambda/?nc1=h_ls, acesso em 2022-

03-08. 6, 13

51
[28] Amazon S3. https://aws.amazon.com/pt/s3/?nc1=h_ls, acesso em 2022-03-08. 6,
14

[29] Amazon DynamoDB. https://aws.amazon.com/pt/dynamodb/?nc1=h_ls, acesso

em 2022-03-08. 6, 49

[30] Amazon API Gateway. https://aws.amazon.com/pt/api-gateway/?nc1=h_ls,

acesso em 2022-03-08. 6, 14

[31] Stanford University. https://www.stanford.edu/, acesso em 2022-07-08. 7

[32] Redding, Anna Crowley: Google it: A history of Google. Feiwel & Friends, 2018. 7

[33] GCP: Cloud Functions. https://console.cloud.google.com/marketplace/

product/google-cloud-platform/container-engine, acesso em 2022-07-08. 7,
13

[34] GCP: Compute Engine. https://console.cloud.google.com/marketplace/

product/google-cloud-platform/compute-engine, acesso em 2022-07-08. 7, 10,
11

[35] GCP: Kubernetes Engine. https://console.cloud.google.com/marketplace/

product/google-cloud-platform/container-engine, acesso em 2022-07-08. 7,
12

[36] GCP: BigQuery. https://console.cloud.google.com/marketplace/product/

google-cloud-platform/bigquery, acesso em 2022-07-08. 7

[37] GCP: Cloud Storage. https://console.cloud.google.com/marketplace/

product/google-cloud-platform/cloud-storage, acesso em 2022-07-08. 7

[38] GCP: Regiões e zonas. https://cloud.google.com/compute/docs/

regions-zones?hl=pt-br, acesso em 2022-07-08. 7

[39] Stross, Randall E: The Microsoft way: The real story of how the company outsmarts
its competition. Addison Wesley Longman Publishing Co., Inc., 1996. 8

[40] Azure Products. https://azure.microsoft.com/en-us/products/, acesso em

2022-07-08. 8

[41] Azure Functions. https://azure.microsoft.com/en-us/services/functions/,

acesso em 2022-07-08. 8, 13

[42] Azure: Virtual Machines. https://azure.microsoft.com/en-us/services/

virtual-machines/, acesso em 2022-07-08. 8, 11

[43] Azure: Face APIs. https://azure.microsoft.com/en-us/services/

cognitive-services/face/, acesso em 2022-07-08. 8

[44] Azure: Queue Storage. https://azure.microsoft.com/en-us/services/

storage/queues/, acesso em 2022-07-08. 9

52
[45] Azure Backup. https://azure.microsoft.com/en-us/services/backup/,
07/08/2022. 9

[46] Tandon, Aditya e Anand Nayyar: A comprehensive survey on ransomware attack:

A growing havoc cyberthreat. Data Management, Analytics and Innovation, páginas
403–420, 2019. Publisher: Springer. 9

[47] Heroku: Cloud Application Platform. https://www.heroku.com, acesso em 2022-08-

15. 10

[48] Dropbox. https://www.dropbox.com/pt_BR/, acesso em 2022-08-15. 10

[49] Mahoney, Michael S.: The History of Computing in the History of Technology. Annals
of the History of Computing, 10(2):113–125, 1988. 11

[50] Islam, Mohammad A., Hasan Mahmud, Shaolei Ren e Xiaorui Wang: Paying to save:
Reducing cost of colocation data center via rewards. Em 2015 IEEE 21st International
Symposium on High Performance Computer Architecture (HPCA), páginas 235–245,
2015. 11

[51] Bhardwaj, Sushil, Leena Jain e Sandeep Jain: Cloud computing: A study of infras-
tructure as a service (IAAS). International Journal of engineering and information
Technology, 2(1):60–63, 2010. 11

[52] Ebert, Nico, Kristin Weber e Stefan Koruna: Integration platform as a service. Busi-
ness & Information Systems Engineering, 59(5):375–379, 2017. Publisher: Springer.
11

[53] AWS Elastic Beanstalk. https://aws.amazon.com/pt/elasticbeanstalk/, acesso

em 2022-07-08. 12

[54] Serviços de nuvem do Azure. https://azure.microsoft.com/pt-br/services/

cloud-services/, acesso em 2022-07-08. 12

[55] Ma, Dan: The business model of" software-as-a-service". Em Ieee international con-
ference on services computing (scc 2007), páginas 701–702. IEEE, 2007. 12

[56] Duan, Yucong, Guohua Fu, Nianjun Zhou, Xiaobing Sun, Nanjangud C Narendra
e Bo Hu: Everything as a service (XaaS) on the cloud: origins, current and future
trends. Em 2015 IEEE 8th International Conference on Cloud Computing, páginas
621–628. IEEE, 2015. 12

[57] Shahrad, Mohammad, Jonathan Balkind e David Wentzlaff: Architectural Impli-

cations of Function-as-a-Service Computing. Em Proceedings of the 52nd An-
nual IEEE/ACM International Symposium on Microarchitecture, MICRO ’52, pá-
ginas 1063–1075, New York, NY, USA, 2019. Association for Computing Machin-
ery, ISBN 978-1-4503-6938-1. https://doi.org/10.1145/3352460.3358296, event-
place: Columbus, OH, USA. 13

53
[58] Bandeira, Waliff, Leonardo Carvalho e Aleteia Araujo: Análise do Custo-benefício de
Funções como Serviço e Infraestrutura como Serviço. Em Anais da IV Escola Regional
de Alto Desempenho do Centro-Oeste, páginas 38–40, Porto Alegre, RS, Brasil, 2021.
SBC. https://sol.sbc.org.br/index.php/eradco/article/view/18423, ISSN:
0000-0000 event-place: Evento Online. 13, 24

[59] Jonas, Eric, Johann Schleier-Smith, Vikram Sreekanti, Chia che Tsai, Anurag Khan-
delwal, Qifan Pu, Vaishaal Shankar, João Carreira, Karl Krauth, Neeraja Jayant
Yadwadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica e David A. Patterson:
Cloud Programming Simplified: A Berkeley View on Serverless Computing. CoRR,
abs/1902.03383, 2019. http://arxiv.org/abs/1902.03383, arXiv: 1902.03383. 14

[60] AWS: Cotas Lambda. https://docs.aws.amazon.com/pt_br/lambda/latest/dg/

gettingstarted-limits.html, acesso em 2022-08-16. 14

[61] Firebase - Google. https://firebase.google.com/?hl=pt, acesso em 2022-08-16.

15

[62] AWS EC2: Pricing. https://aws.amazon.com/pt/ec2/pricing/, acesso em 2022-

12-09. 16

[63] AWS: Calculadora de Preços. https://calculator.aws/#/, acesso em 2022-12-09.

16

[64] Compute Engine: Pricing. https://cloud.google.com/compute/all-pricing?

hl=pt-br, acesso em 2022-12-09. 18

[65] Cloud Functions: Pricing. https://cloud.google.com/functions/pricing,

acesso em 2022-12-09. 19

[66] Azure Virtual Machines: Pricing. https://azure.microsoft.com/en-us/

pricing/details/virtual-machines/linux/, acesso em 2022-12-09. 20

[67] Azure Functions: Pricing. https://azure.microsoft.com/pt-br/pricing/

details/functions/, acesso em 2022-12-09. 21

[68] Grafana: The open observability platform | Grafana Labs. https://grafana.com/,

acesso em 2022-08-30. 24

[69] Apache Jmeter. https://jmeter.apache.org/, acesso em 2022-08-30. 24, 30

[70] Erinle, Bayo: Performance Testing with JMeter 3. Packt Publishing Ltd, 2017. 30

[71] AWS: CloudFormation. https://aws.amazon.com/pt/cloudformation/, acesso em

2022-09-30. 30

[72] Terraform. https://www.terraform.io/, acesso em 2022-09-30. 30

[73] Soni, Anshu e Virender Ranga: API features individualizing of web services: REST
and SOAP. International Journal of Innovative Technology and Exploring Engineer-
ing, 8(9):664–671, 2019. 33

54
[74] Github: waliffcordeiro/APIs-Faasdoom. https://github.com/waliffcordeiro/
APIs-Faasdoom, acesso em 2022-04-09. 33

[75] Framework Express. https://expressjs.com/pt-br/, acesso em 2022-04-09. 33

[76] Go package net/http. https://pkg.go.dev/net/http, acesso em 2022-04-09. 33

[77] Framework Flask. https://flask.palletsprojects.com/en/2.2.x/, acesso em

2022-04-09. 33

[78] Install Docker. https://docs.docker.com/engine/install/ubuntu/, acesso em

2022-04-09. 34, 42, 48

[79] Install Docker Compose. https://docs.docker.com/compose/install/, acesso em

2022-04-09. 34

[80] Motta, Marcelo, Leonardo Reboucas De Carvalho, Michel Rosa e Aleteia Favacho De
Araujo: Comparison of FaaS Platform Performance in Private Clouds. Em Proceed-
ings of the 12th International Conference on Cloud Computing and Services Science
- CLOSER,, páginas 109–120. SciTePress, 2022, ISBN 978-989-758-570-8. Backup
Publisher: INSTICC ISSN: 2184-5042. 37, 41

[81] Kubernetes. https://kubernetes.io/pt-br/, acesso em 2022-12-09. 42, 48

[82] Carvalho, Leonardo de e Aletéia Araújo: Function-as-a-Service: Desenvolvendo Apli-

cações na Próxima Geração da Computação em Nuvem. Em Araújo, Aletéia, Bianca
Dantas, Liana Duenha e Wellington Martins (editores): Minicursos da IV Es-
cola Regional de Alto Desempenho do Centro Oeste, páginas 2–22. SBC, 1a edição,
novembro 2021, ISBN 9786587003801. https://sol.sbc.org.br/livros/index.
php/sbc/catalog/view/80/345/604-1, acesso em 2022-09-12. 48

[83] Amazon SQS. https://aws.amazon.com/sqs/, acesso em 2022-01-10. 49

55