Valter Canhizares Filho Desvendando As Nuvens: Uma Análise Comparativa De Desempenho De Aplicações Serverless E Containers Em Provedores De Computação Em Nuvem São José do Rio Preto 2024 Campus de São José do Rio Preto Valter Canhizares Filho Desvendando As Nuvens: Uma Análise Comparativa De Desempenho De Aplicações Serverless E Containers Em Provedores De Computação Em Nuvem Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Ciência da Computação, junto ao Programa de Pós-Graduação em Ciência da Computação (PPGCC), do Instituto de Biociências, Letras e Ciências Exatas da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de São José do Rio Preto. Orientadora: Prof.ª. Dr.ª. Renata Spolon Lobato São José do Rio Preto 2024 Sistema de geração automática de fichas catalográficas da Unesp. Biblioteca da Universidade Estadual Paulista (UNESP), Instituto de Biociências Letras e Ciências Exatas, São José do Rio Preto. Dados fornecidos pelo autor(a). Essa ficha não pode ser modificada. C222d Canhizares Filho, Valter Desvendando As Nuvens: Uma Análise Comparativa De Desempenho De Aplicações Serverless E Containers Em Provedores De Computação Em Nuvem / Valter Canhizares Filho. -- São José do Rio Preto, 2024 100 p. Dissertação (mestrado) - Universidade Estadual Paulista (UNESP), Instituto de Biociências Letras e Ciências Exatas, São José do Rio Preto 1. Computação em Nuvem. 2. Computação sem Servidor. 3. Containers. I. Título. Valter Canhizares Filho Desvendando As Nuvens: Uma Análise Comparativa De Desempenho De Aplicações Serverless E Containers Em Provedores De Computação Em Nuvem Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Ciência da Computação, junto ao Programa de Pós-Graduação em Ciência da Computação (PPGCC), do Instituto de Biociências, Letras e Ciências Exatas da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Campus de São José do Rio Preto. Orientadora: Prof.ª. Dr.ª. Renata Spolon Lobato Banca Examinadora Prof.ª. Dr.ª. Renata Spolon Lobato UNESP – Câmpus de São José do Rio Preto Orientadora Prof. Dr. Rodrigo Capobianco Guido UNESP – Câmpus de São José do Rio Preto Prof. Dr. Márcio Andrey Teixeira IFSP – Câmpus de Catanduva São José do Rio Preto 28 de junho de 2024 AGRADECIMENTOS O Mestrado não é só uma realização acadêmica para mim, é também a realização de um sonho. Sempre tive o grande sonho de poder estudar em uma das mais renomadas instituições de ensino deste país, hoje posso dizer que subi um degrau da escada. Só quem vive essa experiência consegue dimensionar a dificuldade que é subir esse degrau, a dificuldade que é furar a bolha do conhecimento e continuar. Em primeiro lugar, agradeço aos meus pais Valter e Rejane por me proporcionarem o privilégio da boa educação. O suor, o sacrifício e tudo que deixaram de fazer por vocês para fazer por mim, para que eu pudesse ter esse privilégio. Devo tudo isso a vocês. A minha namorada, Maria Rita, que nunca mediu esforços para me ajudar e me motivar, me ouvir desabafar e não deixar que eu desanimasse. Uma das minhas maiores fontes de motivação para que o nosso futuro seja ainda mais brilhante. À orientadora, Professora e Mentora, Renata, que foi fundamental para o bom caminho seguido por este trabalho. Pelas inúmeras reuniões e pela infinita paciência comigo. Tive um caminho conturbado durante esse processo e, mesmo assim não desistiu de mim. Obrigado pelos puxões de orelha e por toda motivação. Aos meus grandes amigos de trabalho, Rafael Elói, Camila Brandão e Camila Okado, que acompanharam de perto toda essa jornada e me motivaram a completar meu objetivo. Estendo este agradecimento a todos os amigos que, direta ou indiretamente, me ajudaram a obter sucesso nesta etapa, que muitas vezes mostraram que a minha vitória também seria a deles. A todo o corpo docente e demais funcionários da Universidade Estadual Paulista, pelo trabalho primoroso e cordial que todos prestam à sociedade. Por último, mas não menos importante, uma pessoa que considero como uma segunda mãe, Teresa Cristina Castilho Gorayeb, que foi a primeira pessoa a me incentivar a começar a carreira de professor e de pesquisador. RESUMO Nos últimos anos houve um aumento considerável no interesse comercial e acadêmico na computação em nuvem, alavancando também um novo paradigma da computação distribuída, a computação sem servidor. Essa abstração oferece a desenvolvedores uma maior agilidade para criação de uma aplicação, além de proporcionar redução de custos, escalabilidade e significante diminuição de tempo para um produto atingir seus clientes. O desenvolvedor de uma aplicação sem servidor cria e executa suas aplicações sem embargo de qualquer configuração e manutenção em servidores, máquinas virtuais e sistemas operacionais. A computação sem servidor oferece computação distribuída com custo granular inerente ao uso e oferece aplicações em diferentes escopos como desenvolvimento web, APIs, chatbots, processamento de dados, Internet das Coisas, redes de computadores, entre outros. Entretanto oferece desafios de desempenho, arranque a frio de funções, segurança, precificação e travamentos de provedor em nuvem. O desenvolvimento do trabalho ocorreu pela apresentação do estado da arte da computação sem servidor, comparação entre provedores de computação em nuvem que oferecem a computação sem servidor, e aplicação em caso prático em backend de uma aplicação web. Para a mesma aplicação, resultados indicam que o tempo de execução pode diferir de duas a quatro vezes dependendo do provedor. Em relação ao custo monetário das execuções, foi demonstrado uma diferença de até 25% entre arquiteturas ARM e x86, diferença de até 68% entre regiões diferentes e, mais de 48% entre os modelos de Functions-As-a-Service e Containers-As-a-Service. Palavras–chave: Computação sem Servidor. Computação em Nuvem. Desafios sem Servidor. Benefícios sem Servidor. ABSTRACT In recent years, there has been a considerable increase in commercial and academic interest in cloud computing, which has also boosted a new paradigm of distributed computing: the serverless computing. This abstraction provides developers with greater agility in creating applications, along with cost reduction, scalability, and significant time reduction for a product to reach its customers. A serverless application developer can create and run applications without any configuration and maintenance of servers, virtual machines, or operating systems. Serverless computing offers distributed computing with granular cost inherent to usage and supports applications in various scopes such as web development, APIs, chatbots, data processing, Internet of Things, computer networks, among others. However, it presents challenges in performance, cold start of functions, security, pricing, and cloud provider lock-in. The work developed involves presenting the state of the art in serverless computing, comparing cloud providers that offer serverless computing, and applying it in a practical case in the backend of a web application. For the same application, results indicate that the execution time can differ by two to four times depending on the provider. Regarding the monetary cost of executions, a difference of up to 25% was demonstrated between ARM and x86 architectures, a difference of up to 68% between different regions, and more than 48% between Functions-As-a-Service and Containers- As-a-Service. Keywords: Serverless computing. Cloud computing. Serverless benefits. Serverless challenges. LISTA DE ILUSTRAÇÕES Gráfico 1 – Gráfico do número de artigos obtidos baseado na palavra-chave “serverless”. 16 Figura 1 – Modelos de Computação em Nuvem e alguns exemplos 22 Figura 2 – Modelo de processamento FaaS 26 Figura 3 – Arquitetura da computação sem servidor 27 Figura 4 – Exemplo de funcionamento do AWS Lambda em processamento de arquivos 28 Figura 5 – Exemplo de funcionamento do AWS Lambda em IoT 28 Figura 6 – Exemplo de funcionamento do Google Functions em IA 29 Figura 7 – Computação tradicional versus Computação em Nuvem versus Computação sem Servidor 31 Figura 8 – O cold start atrasa a execução do código 33 Figura 9 – Relação entre a taxa de transferência por segundo e o número de execuções concorrentes Figura 10 - Sobrecarga para a simultaneidade da CPU Figura 11 – Exemplo de computação em monólitos Figura 12 – Exemplo de computação em Microsserviços Figura 13 – Exemplo de computação serverless 38 39 48 49 50 Figura 14 – Desenvolvimento de Microsserviços e Funções Figura 15 – Arquitetura de um serviço web usando Node.JS 53 55 Figura 16 - Definição do handler 59 Figura 17 – Encontrando o melhor setup para execução serverless 60 Figura 18 – Report do CloudWatch em função na região us-east-1 61 Figura 19 – Report do CloudWatch em função na região sa-east-1 62 Figura 20 – Diagrama da estrutura da aplicação na plataforma AWS Lambda 63 Figura 21 – Custo em dólares de 10 milhões de requisições serverless (FaaS) e containers (CaaS) no provedor AWS Lambda 64 Figura 22 - Período de reciclagem de instância e tempos de execução em segundos da plataforma AWS Lambda 66 Figura 23 – Arquitetura da aplicação em Azure Functions 71 Figura 24 – Precificação e comparação CaaS e FaaS no Azure 73 Figura 25 - Período de reciclagem de instância e tempos de execução em segundos da plataforma Azure Functions 75 Figura 26 - Exemplo da implantação da função na 2ª versão do Google Functions 76 Figura 27 - Arquitetura da aplicação na plataforma Google Functions 78 Figura 28 – Precificação e comparação CaaS e FaaS no Google Functions 79 Figura 29 – Período de reciclagem de instância e tempos de execução em segundos da plataforma Google Functions 80 Figura 30 – Custo de 10 milhões de execuções em três provedores de computação em nuvem 83 Figura 31 – Custo de provedores FaaS comparados por região 84 Figura 32 – Custo de provedores CaaS comparados por região 85 Figura 33 – Custo FaaS contra CaaS em três provedoras 86 Figura 34 – Relação entre custo $ na região us-east-1 86 Figura 35 – Relação entre custo $ na região sa-east-1 87 Figura 36 – Comparativo entre o tempo de execução da função serverless nos três provedores 88 LISTA DE TABELAS Tabela 1 – Número de artigos baseado na palavra “serverless” 16 Tabela 2 – Número de artigos baseados nas palavras-chaves “cloud computing” e “Function-As-a-Service” 17 Tabela 3 – Comparação entre serverless e computação tradicional 35 Tabela 4 – Lista dos três principais provedores de computação sem servidor – FaaS 36 Tabela 5 – Comparação entre custo das plataformas FaaS 37 Tabela 6 – Lista de plataformas opensource 40 Tabela 7 – Comparação entre plataformas serverless 43 Tabela 8 – Comparação entre desenvolvimento de software on-premises, em nuvem e serverless 44 Tabela 9 – Runtimes do Node.JS no AWS Lambda 58 Tabela 10 - Suporte a Sistema Operacional Azure Functions 68 Tabela 11 - Planos e a duração do tempo limite de funções 69 Tabela 12 – Comportamento do cold start em relação ao Plano 69 Tabela 13 – Runtimes do Node.JS no Azure Functions 70 Tabela 14 – Tabela de comparação de versões do Google Functions 76 Tabela 15 – Runtimes do Node.JS no Google Functions 77 Tabela 16 – Custo de 10 milhões de requisições para cada serviço, do mais barato para o mais caro 81 LISTA DE ABREVIATURAS E SIGLAS AWS Amazon Web Services IBM International Business Machines GCP Google Cloud Platform IEEE Institute of Electrical and Electronics Engineers CAPEX Capital Expenditure OPEX Operational Expenditure SaaS Software as a Service PaaS Platform as a Service IaaS Infrastructure as a Service FaaS Function as a Service BaaS Back-end as a Service REST Representational State Transfer API Application Programming Interfaces SDK Software Development Kit S3 Amazon Simple Storage Service IoT Internet of Things FTTM Fast Time do Market QPS Queries Per Second CPU Central Processing Unit HTTP Hypertext Transfer Protocol IDE Integrated Development Environment CLI Command-Line Interface GUI Graphical User Interface MQTT Message Queuing Telemetry Transport RPC Remote Procedure Call REST Representational State Transfer SOAP Simple Object Access Protocol MB Megabyte RAM Random-Access Memory ID Identification HTML Hypertext Markup Language CSS Cascading Style Sheets JS JavaScript HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure PNG Portable Network Graphic JPG Joint Photographic Group SDK Software Development Kit I/O Input/Output DEVOPS Development and Operations IAM Identity and Access Management ARM Advanced RISC Machine RISC Reduced Instruction Set Computer ASE App Service Environment SKU Stock Keeping Unit ACU Azure Compute Unit SSL Secure Sockets Layer vCPU Virtual Central Processing Unit SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO ...............................................................13 1.1 Motivação E Objetivos ...................................................................14 1.2 Revisão Da Literatura ....................................................................15 1.3 Organização Do Texto ...................................................................17 CAPÍTULO 2 – COMPUTAÇÃO EM NUVEM E SERVERLESS ...........18 2.1 Definições Da Computação Em Nuvem .........................................18 2.2 Modelos De Serviços De Computação Em Nuvem ........................20 2.3 Computação Sem Servidor .............................................................23 2.4 Exemplos Do Uso Da Computação Sem Servidor .........................27 2.5 Vantagens E Desvantagens ...........................................................29 CAPÍTULO 3 – PLATAFORMAS SERVERLESS ..................................36 3.1 Plataformas Comerciais ....................................................................36 3.2 Plataformas FaaS Opensource ........................................................39 3.3 Comparação Entre Plataformas Disponíveis e o Desenvolvimento Tradicional De Software .........................................................................42 3.4 Microsserviços E Suas Características ............................................46 3.5 Monólitos, Microsserviços, Containers E Serverless ........................47 CAPÍTULO 4 – DESENVOLVIMENTO ..................................................54 4.1 Arquitetura Da Aplicação Web ..........................................................54 4.2 Testes De Desempenho ...................................................................57 4.2.1 AWS Lambda .................................................................................57 4.2.2 Azure Functions .............................................................................67 4.2.3 Google Cloud Functions ................................................................75 4.3 Resultados Dos Testes E Comparativos ..........................................81 CAPÍTULO 5 - CONCLUSÃO ................................................................89 REFERÊNCIAS ......................................................................................92 13 CAPÍTULO 1 - INTRODUÇÃO Na última década os avanços da computação em nuvem são notáveis. Tais avanços podem ser notados pelo crescente investimento em soluções em nuvem por parte da indústria e estudos realizados pela academia. Segundo (UDUNWA, et al. 2019), o mercado da computação em nuvem chegará em 2025 a um volume de revenda de quase 700 bilhões de dólares, impulsionado por soluções relacionadas a infraestrutura em nuvem como serviço, inteligência artificial e computação sem servidor. Aplicações em nuvem são oferecidas hoje por múltiplos provedores. São exemplos Amazon (AWS), Microsoft (Azure), Google (GCP), IBM (IBM Cloud) entre outros que distribuem seu poder computacional para consumidores dispostos a pagar pelo consumo. (VARGHESE; BUYYA, 2018) destacam em seu trabalho que novas tendências e direções exponenciam a necessidade e popularidade da computação em nuvem. Direções como arquiteturas emergentes, tal qual computação definida por software, computação sem servidor serão tendências para as próximas gerações de computação em nuvem. Junto a isso, vale destacar tendências sobre infraestruturas em nuvens heterogêneas. A computação em nuvem vem cada vez mais sendo adotada pelas empresas para otimizar seus processos, sejam eles disponíveis em infraestrutura como serviço, plataforma como serviço ou até mesmo software como serviço. Características como alta disponibilidade, elasticidade e medicação do consumo trazem os holofotes da computação atual para a computação em nuvem. Os autores (RISTOV, et al. 2021); (BALLA, et al. 2020); (JINDAL, et al. 2021), PFANDZELTER; BERMBACH, 2020) exploram, com sucesso, o emprego da linguagem Node.JS na computação sem servidor, bem como o desempenho de aplicações na migração computação monolítica para a computação serverless, Embasando ainda no contexto da pesquisa, (CASSEL et al, 2022) traz em sua taxonomia que uma das linguagens mais utilizadas no contexto serverless é JavaScript e containers como componente mais utilizado para o desenvolvimento. Além disso, a maioria das aplicações serverless trabalham na camada de aplicação, utilizando o protocolo HTTP. Todas essas três tecnologias estão sendo usadas no trabalho atual. 14 1.1 Motivação e Objetivos Novos paradigmas da computação vêm emergindo com o passar dos anos e a computação em nuvem surgiu como um marco para a computação moderna. Novas propostas surgem com a finalidade de tornar mais dinâmico e ágil o grande fluxo de informações que trafegam diariamente entre usuários e servidores em rede. A Internet amplamente distribuída necessita de práticas e modelos escalonáveis, confiáveis e altamente disponíveis, premissas que condizem com a exploração de soluções na nuvem. Diversos autores destacam esse crescimento e necessidade de processar tamanha conjuntura de dados e demandas de aplicações em nuvem crescem ao passar dos últimos anos. Cada vez mais as soluções convergem para a nuvem, e é necessário que progressos sejam feitos para atender a essa crescente demanda. Como objetivo principal deste trabalho, uma aplicação web monolítica em Node.JS que atualmente está em um ambiente on premises é migrada para um ambiente em nuvem, mais especificamente em um ambiente serverless como FaaS – Function-as-a-Service e um ambiente de container como PaaS – Platform-as-a- Service. Com as revisões bibliográficas foi possível implementar a aplicação web e medir seu desempenho e seu custo. O desempenho foi medido com testes de carga incremental e picos de carga por meio da aplicação Apache JMeter e o custo foi medido em três provedores de computação sem servidor: Amazon, Google e Microsoft. A mesma aplicação serverless foi implementada nos provedores e executadas milhões de vezes, custeadas por créditos cedidos pelas empresas para conta educacional do autor do trabalho. Como resultado, é possível analisar se a computação sem servidor traz benefícios ao desempenho e custo da aplicação em comparação a mesma aplicação implementada em forma de containers, levando em conta os desafios encontrados pela computação sem servidor. Ao final do trabalho, considerando os resultados obtidos, é elencado o melhor provedor de computação em nuvem para a execução da aplicação em Node.JS, com o menor tempo de execução possível e com o melhor preço possível, gerando assim uma melhor economia para uma aplicação que hoje é executada em um monólito. 15 1.2 Revisão da Literatura Nesta subseção é explicitada a revisão sistemática da literatura atual sobre o tema, levantamento dos dados relacionados e problemáticas inerentes ao assunto principal do trabalho. A subseção mostra a metodologia utilizada, termos utilizados nas buscas e alguns resultados preliminares da bibliografia relacionada ao tema. O primeiro passo foi realizar uma revisão sistemática da literatura encontrada nos principais veículos de artigos científicos, publicações de jornais e revistas da área da computação nos últimos anos. No presente método de pesquisa da literatura é necessário reunir diversos estudos que testaram empiricamente hipóteses relacionadas a computação sem servidor. Para isso é necessária a revisão quantitativa das informações encontradas nos veículos de trabalhos relacionados, pesquisa denominada de meta-análise, que está focada em estimativas, relato de resultados quantitativos correlatos e exame dos relacionamentos entre eles (GALVÃO; RICARTE, 2020). Segundo os mesmos autores, visando integrar a pesquisa qualitativa, a meta- síntese é necessária para integrar a pesquisa, com a finalidade de sintetizar os estudos qualitativos e localizar temas e conceitos para fornecer novas explicações sobre os paradigmas da computação em nuvem e sem servidor. As bases de dados selecionadas foram revistas como IEEE Xplore, ACM Digital Library, ScienceDirect, entre outros. As buscas nas revistas deram-se pelas palavras-chaves “cloud computing” (Computação em Nuvem), “serverless” (Sem Servidor) e “Function-as-a-Service” (Funções-como-serviço). Foram delimitados para a pesquisa trabalhos no período de seis anos, entre janeiro de 2019 até o mês de maio de 2024. Nos últimos anos houve um aumento significativo de publicações acerca do tema, o que se faz entender que a academia está cada vez mais em busca do fomento a exploração do tema. Na Tabela 1 é representada a quantidade de publicações de trabalhos em revistas baseado na palavra-chave “serverless” no período de 2019 a 2024. Em seguida, o Gráfico 1 representa sua evolução. 16 Tabela 1 – Número de artigos baseado na palavra “serverless” 2019 2020 2021 2022 2023 2024 IEEE Xplore 83 97 254 201 259 55 ACM Digital Library 151 172 178 283 416 143 Science Direct 39 69 78 140 147 135 Total 273 338 410 624 687 333 Fonte: Desenvolvido pelo autor (2024). Gráfico 1 – Gráfico do número de artigos obtidos baseado na palavra-chave “serverless” Fonte: Desenvolvido pelo autor (2024). Após pesquisas nos meios citados, a leitura é realizada para seleção dos artigos mais relevantes e com maior pertinência relacionado ao trabalho. Com base nas evidências encontradas nas leituras é possível elevar pontos importantes e alicerçar novas pesquisas relacionadas ao tema. As outras palavras-chaves “computação em nuvem” e “Function-as-a-Service” estão sumarizadas na Tabela 2, notavelmente endossa a ideia do avanço em pesquisas relacionadas ao tema do atual trabalho. 17 Tabela 2 – Número de artigos baseados nas palavras-chaves “cloud computing” e “Function- As-a-Service” Cloud Computing Function-As-a-Service (2018-2024) 2020 2021 2022 2023 2024 IEEE Xplore 52.727 27 53 64 82 12 ACM Digital Library 142.984 35.216 36.972 36.523 39.423 15.313 Science Direct 140.684 7.680 8.242 9.534 9.633 6.163 Fonte: Desenvolvido pelo autor (2024). 1.3 Organização do texto O texto encontra-se organizado da seguinte forma: No Capítulo 2 são apresentadas definições e modelos presentes na computação em nuvem, computação serverless, exemplo do uso e principais vantagens e desvantagens. No Capítulo 3 são apresentadas plataformas comerciais e opensource da computação sem servidor, comparação entre plataformas, microsserviços e suas características de interação com serverless e, como a evolução da computação monolítica culminou em tecnologias como containers e Funções como Serviço. No Capítulo 4 é apresentado o desenvolvimento do trabalho, funcionamento da arquitetura da aplicação web em Node.JS, testes de validação conduzidos em três provedores de computação serverless e seus resultados. No Capítulo 5 tem-se a conclusão e os trabalhos futuros. 18 CAPÍTULO 2 – COMPUTAÇÃO EM NUVEM E SERVERLESS A computação em nuvem é um mercado que está sendo explorado a anos e vem trazendo resultados otimistas para seus consumidores. É sabido que com o passar dos anos houve um aumento na adoção de computação em nuvem pelas empresas de todos os ramos (KHOUN, et al. 2020). O mercado da computação em nuvem inegavelmente cresceu nos últimos anos e tem tendência de crescimento para os próximos. Em 2021 movimentou quase 450 bilhões de dólares em todo mundo e é esperado que até 2026 o movimento seja de 950 milhões de dólares, crescimento composto anual de mais de 16%, segundo (MARKETSANDMARKETS, 2021). Com a premissa de otimizar os recursos computacionais distribuídos, a computação em nuvem ganha destaque no contexto atual. Pequenas e médias empresas podem utilizar das mesmas tecnologias que grandes empresas usam, contando com a redução de custos e escalabilidade ao utilizar o poder de processamento de máquinas virtuais dos provedores de computação em nuvem (JONAS, et. al. 2019), tudo isso pagando conforme a utilização. Em resumo, toda infraestrutura de computação em nuvem é um conjunto entre hardware e software que possibilitam as cinco principais características da computação em nuvem, segundo (MELL; GRANCE, 2011). Essa infraestrutura pode ser observada como o conjunto de um nível físico junto a uma camada de diferentes níveis de abstração. A parte física consiste no ecossistema de hardware que uma empresa provedora precisa ter para oferecer seus produtos aos seus clientes, como por exemplo processadores, servidores, memória, armazenamento em discos rígidos ou de estado sólido, componentes de redes como switches, roteadores e cabeamento. As camadas de abstração são os softwares desenvolvidos com base nos componentes físicos da infraestrutura. 2.1 Definições da Computação em Nuvem Ao utilizar a computação em nuvem, o usuário utiliza recursos distribuídos oriundos de datacenters de provedores de computação em nuvem como Microsoft e Amazon. Empresas provedores oferecem serviço de rápido provisionamento, computação ubíqua e sob demanda com diferentes níveis de configuração do usuário deste modelo. Toda a parte de servidores físicos, redes, armazenamento e aplicações 19 podem, ou não, ser configuradas pelo usuário, trazendo assim níveis diferentes de abstração da computação em nuvem (MELL; GRANCE, 2011). Os mesmos autores elencam a composição do modelo de computação em nuvem em cinco principais características, três modelos de serviço e quatro modelos de implantação. As cinco características principais da computação em nuvem são: • Serviço sob demanda: O cliente do provedor de computação em nuvem pode, a qualquer momento, provisionar capacidade computacional como processamento, execução e armazenamento de qualquer dado, sem necessariamente ter interação humana no processo com seu provedor. Empresas provedores oferecem seus serviços de computação em nuvem por meio de interfaces gráficas práticas e usuais, o cliente cria uma conta e consegue utilizar os serviços de nuvem por meio de créditos em sua conta. A qualquer momento é possível aumentar, diminuir, replicar a demanda imposta ao provedor, custeado apenas o tempo que o usuário utilizar. • Acesso amplo à rede de computadores: Os serviços de computação em nuvem são ofertados para qualquer tipo de cliente, de pequeno, médio e grande porte. As capacidades computacionais das provedores ficam à disposição do cliente por meio da internet e pode ser acessado por qualquer tipo de plataforma, heterogeneamente, como celulares, computadores portáteis ou estações de trabalho. Geralmente o acesso é feito via aplicativo ou navegador de internet que qualquer dispositivo tenha. Os serviços podem ser contratados e gerenciados de qualquer aparelho, em qualquer lugar, a qualquer hora. • Aglomerado de recursos computacionais: Os serviços oferecidos pelo provedor, em escala mundial, são distribuídos em diversos datacenters espalhados por várias regiões do mundo, com diferentes condições de precificação, latência, tipos específicos de serviços oferecidos. O usuário não enxerga onde essa capacidade computacional está distribuída. De forma invisível, ao provedor oferece recursos físicos e virtuais que podem ser escaláveis conforme a necessidade do cliente. 20 • Rápida elasticidade: Aplicações em nuvem conseguem rapidamente aumentar e diminuir de tamanho conforme a necessidade do cliente, muitas vezes de forma automática. Para o cliente, a capacidade computacional aparentemente é ilimitada e, pode controlar mínimos e máximos de elasticidade que deseja para sua aplicação. O monitoramento neste caso é fundamental, para ambos os lados. • Medição do serviço consumido: Métricas são fundamentais para a computação em nuvem. Os sistemas em nuvem têm a capacidade de otimizar seus recursos computacionais e controlá-los metrificando sua capacidade. Serviços importantes como armazenamento de arquivos, processamento de dados, largura de banda são monitorados, controlados e reportados em tempo real, trazendo transparência entre o provedor da computação em nuvem e seu cliente que consegue tomar decisões baseadas no uso de seus recursos. Com tais definições, a computação em nuvem torna-se atrativa para seus consumidores como sendo uma alternativa a reduzir o investimento em bens de capital (chamado de CAPEX – Capital Expenditure), bem como despesas operacionais (OPEX – Operational Expenditure) de uma empresa. É possível que uma empresa exponha seu produto desenvolvido sem necessariamente ter uma infraestrutura de servidores, redes e pessoal para gerenciar a aplicação. A empresa neste caso simplesmente “aluga” a capacidade computacional de um provedor de computação em nuvem. 2.2 Modelos de Serviços de Computação em Nuvem Diferentes modelos de computação em nuvem são oferecidos pelos provedores, níveis diferentes de abstração e controle do cliente sobre suas aplicações. É importante destacar que serviços diferentes estão inerentes a esses níveis de abstração e tais níveis podem estar disponíveis de diferentes formas, com diferentes métricas de precificação. (MELL; GRANCE, 2011) dividem a computação em nuvem em três modelos: • SaaS – Software as a Service – Software como Serviço: Pode ser considerado o nível no qual o cliente tem o menor controle sobre determinado serviço oferecido em nuvem. Nessa camada, o usuário apenas usa aplicações oferecidas pelo provedor, como o e-mail, por exemplo. O nível de software como serviço é acessível 21 por meio de uma interface gráfica de navegador de internet ou programa. O usuário dessa aplicação não controla nem gerencia a infraestrutura do provedor do serviço como processamento, rede, sistema operacional, armazenamento, ou seja, não tem poder sobre o hardware da aplicação que utiliza. No modelo de Software como Serviço, (CHATURVEDI; RASHID, 2019) elencam benefícios como rápida escalabilidade, acesso amplo de qualquer lugar da internet, despreocupação quanto à infraestrutura, níveis diferentes de serviços oferecidos no modelo e manutenção e suporte ágil. • PaaS – Platform as a Service – Plataforma como Serviço: Nesse nível de abstração, o provedor oferece ao usuário o controle das linguagens de programação, bibliotecas, serviços e ferramentas suportadas na infraestrutura da nuvem. No caso o consumidor ainda não consegue controlar o sistema operacional, armazenamento e hardware em geral. É possível identificar os benefícios deste modelo como baixo custo, se comparado a ambientes on premises, desenvolvimento simplificado, ampla colaboração dos usuários envolvidos no modelo e, não necessidade de upgrades no que tange a infraestrutura das empresas que se beneficiam de tal modelo (CHATURVEDI; RASHID, 2019). • IaaS – Infraestructure as a Service – Infraestrutura como Serviço: Pode ser considerado o nível onde o cliente tem maior acesso e controle sobre o serviço em nuvem contratado de um provedor. O cliente neste caso tem poder para provisionar e controlar o processamento, armazenamento e rede empregado em determinado serviço em nuvem. O usuário pode instalar o sistema operacional, fazer atualizações, se preocupar com a segurança de seu serviço. Por fim, soluções que utilizam Infraestrutura como Serviço beneficiam-se de redução dos bens de capital, pagamento conforme o uso, acesso a uma gama de recursos computacionais de alto nível, ou Entreprise e possibilidade de elasticidade desses sistemas. Os três modelos ainda sim são passíveis de vulnerabilidades de segurança, os autores (BASU, et al. 2018) apontam segurança, localidade, integridade, segregação, confidencialidade e acesso aos dados, segurança de redes, autenticação e autorização como sendo possíveis brechas em ambientes em nuvem. 22 Na Figura 1 é ilustrado o modo como esses modelos de serviço são distribuídos e alguns exemplos presentes em cada nível de abstração. É possível observar uma demonstração de quatro diferentes modelos de implantação, os quais compõem da mesma forma as três premissas de abstração da computação em nuvem (MELL; GRANCE, 2011). O modelo de implantação de nuvem privada tem como principal característica ser provisionado exclusivamente por uma única empresa composta por múltiplos clientes. Deve ser gerenciada pela própria organização, ou terceiros, ou ambos. Pode-se trabalhar nesse tipo de modelo de forma on ou off premises, isso é, o hardware e infraestrutura tem sua implantação fixada no local da empresa, o que requer melhor planejamento e consequentemente maiores custos, ou não. Figura 1 – Modelos de Computação em Nuvem e alguns exemplos. Fonte: Desenvolvido pelo autor (2022). Adaptado de (SURYATEJA, 2018; RASHID, CHATURVEDI, 2019; SUBASHINI, KAVITHA, 2010) Outro modelo de implantação presente na Figura 1 é o modelo de nuvem comunitária, que tem como características ser provisionada exclusivamente para um grupo específico de consumidores que possuem preocupações em relação ao compartilhamento de recursos em nuvem, como por exemplo missões 23 governamentais. Pode ser gerenciada e operada por uma ou mais organizações, até mesmo terceiros. Também segue a possibilidade de ser on ou off premises. Já o modelo de nuvem pública é provisionado para todos que desejarem assinar serviços de computação em nuvem. Pode-se utilizar esse tipo de modelo no meio acadêmico, governamental, no ramo de negócios e, diferente dos modelos anteriores, existe apenas on premises do provedor de computação em nuvem a qual o serviço é contratado, geralmente datacenters espalhados pelo globo. A modalidade de nuvem híbrida, como o nome sugere, é a junção entre dois ou mais modelos de nuvem, citados na Figura 1. Há a possibilidade de heterogeneidade entre provedores de computação em nuvem, que possibilitam portabilidade de dados e aplicações. 2.3 Computação sem servidor Aplicações convencionais em nuvem são ofertadas aos seus usuários por meio de máquinas virtuais hospedadas e virtualizadas dentro de datacenters dos provedores, distribuídas globalmente. Um consumidor de uma aplicação em nuvem neste contexto paga por toda a máquina virtual que está provisionada em sua aplicação. Métricas como custo, latência e elasticidade são levadas em consideração no desempenho de uma aplicação. Diversas aplicações não utilizam a totalidade de recursos computacionais de uma máquina virtual para ser provisionada. Com isso, conceitos de otimização foram pensados nos últimos anos para aprimorar o uso da capacidade computacional em nuvem e oferecer para mais clientes uma solução menos custosa. Neste contexto, a abstração da computação sem servidor emergiu como uma alternativa viável, utilizando de um modelo de precificação diferente do convencional que cobra apenas pela aplicação em si que é executada, não toda a infraestrutura de máquina virtual que a aplicação usa. A nomenclatura “sem servidor” não implica que a computação seja de fato sem um servidor. No contexto atual tem o significado que parte do servidor, parte de uma máquina virtual é alugada para execução de determinada aplicação, de uma parte de código, por um período menor do que a computação em nuvem convencional oferece (VARGHESE; BUYYA, 2018). Isso quer dizer que, na computação sem servidor, o 24 desenvolvedor tem o custo inerente à execução de determinado pedaço de código, não de uma máquina virtual inteira para a execução. A abstração sem servidor da computação em nuvem permite que desenvolvedores executem suas aplicações com custo granular inerente ao uso, não havendo a necessidade de se configurar sistemas físicos e lógicos responsáveis pela execução do código (EYK, et al. 2018). Segundo (CASTRO, et al. 2019), tais aplicações abstraem uma complexidade na infraestrutura em nuvem, de forma a proporcionar ao desenvolvedor a liberdade para pensar apenas na execução do código, não no provisionamento de máquina virtual, configuração da mesma e outras preocupações. A computação serverless teve seu primeiro modelo introduzido pela empresa Amazon, com sua plataforma AWS Lambda em 2014 e posteriormente, com avanços na indústria e da academia, começou a ser oferecida por outras empresas provedores de computação em nuvem como o Google Serverless Computing e Azure Functions. Com o intuito de agilizar o desenvolvimento de soluções, o provedor se encarrega de provisionar, gerenciar e escalar servidores, máquinas virtuais, containers para que desenvolvedores apenas carreguem o código de seus programas. Por ser um paradigma emergente na computação em nuvem, a computação serverless é empregada em aplicações de aprendizado de máquina, aprendizagem profunda, computação numérica, processamento de vídeo, Internet das Coisas, análise de big data (WEN, et al. 2023), entre outros. Em 2025, (WEN, et al. 2023) indica que 50% das empresas usarão computação sem servidor, gerando um valor de mercado para tais aplicações de mais de 22 bilhões de dólares, segundo a (GARTNER, 2022). As características únicas da computação sem servidor chamam atenção da comunidade de desenvolvedores de software para o desenvolvimento de aplicações serverless (serverless-based applications). Diversos trabalhos acadêmicos focam em desafios que envolvem a evolução da computação sem servidor (TAIBI, 2020), modelagem de aplicativos (EISMAN et al. 2021; EISMAN et al. 2020), modelagem de aplicações (YUSSUPOV, 2022), framework de programação para aplicações específicas (BERMBAC, et al. 2022; ZHANG, et al. 2021), desenvolvimento de plataformas de computação em nuvem heterogêneas (SAMPÉ, et al. 2020), aplicações serverless stateful (BARCELONA-PONS, et al. 2022), migração de aplicações de monólitos on-premises (RISTOV, et al. 2020), economia serverless 25 (ADZIC; CHATLEY, 2017), datasets (ESKANDANI; SALVANESCHI, 2021) e testes e debugs de aplicações (LENARDUZZI; PANICELLA, 2020). Além disso, os desafios e avanços não estão presos à comunidade de desenvolvedores de software. Existem pesquisas que envolvem desenvolvimento de software, redes de computadores e segurança, pesquisas sobre gerenciamento de recursos (HOSEINYFARAHABADY, et al. 2017; DE PALMA, et al. 2020; ZHANG, et al. 2021), otimização de desempenho de arranque a frio (AKKUS, et al. 2018; FUERST; SHARMA, 2021; OAKES, et al. 2018), comunicação entre funções (JIA; WITCHEL, 2021; SHILLAKER; PIETZUCH, 2020), frameworks de programação generalizada (FOULADI, et al. 2019; JANGDA, et al. 2019), entre outros. Alguns autores dividem a computação sem servidor em duas vertentes (NUPPONEN; TAIBI, 2020; STEINBACH et al. 2022; KOSCHEL et al. 2021; LI et al. 2022, STEINBACH; JINDAL; CHADHA, et al. 2022). São elas: FaaS e BaaS, Funções como Serviço e Backend como Serviço, respectivamente. Funções como Serviço oferece um ambiente voltado ao desenvolvimento de softwares em nuvem com execução baseada em eventos. Tais sistemas baseados em nuvem dependem de uma combinação da lógica de programação por parte do cliente e chamadas de procedimentos advindas de serviços terceiros ao provedor da capacidade computacional em nuvem. Desenvolvedores de aplicações FaaS programam seus códigos posteriormente executados em ambientes isolados na nuvem, cada porção do código representa uma parte de uma aplicação maior e, o tempo de execução é limitado pelo provedor do serviço, por exemplo 15 minutos para execuções na plataforma Lambda (AWS, 2022). Funções ficam ociosas até que sejam acionadas por algum tipo de evento como requisição de usuário, clique do mouse, eventos gerados por sistemas terceiros e/ou entrada e saída de dados; essas funções não ficam ativas o tempo todo, pois implicam em maior custo. O provedor, neste caso, é a responsável por escalar a execução das funções quando elas são invocadas, baseado no número de execuções que ocorrem em resposta aos eventos que chegam. As funções baseadas em eventos são executadas em containers isolados com tempo de vida útil de cada função podendo ser alguns milissegundos. FaaS naturalmente são isoladas, ou stateless, pois não há garantia em relação a integridade das informações que ali invocaram a função. O provedor do serviço limita o tempo de vida útil de uma função (PAAKKUNAINEN, 2019). 26 Um ambiente de FaaS é composto por um controlador, fonte de eventos e instancias de funções. Na Figura 2 ilustra-se a interação entre os três componentes do ambiente. O controlador gerencia o desenvolvimento das funções, além de gerenciar a escalabilidade e monitoramento das instâncias e controla as funções e fontes de eventos. Fontes de eventos acionam ou transmitem eventos para as instâncias e, as instâncias são os ambientes de execução para as funções. Figura 2 – Modelo de processamento FaaS Fonte: Desenvolvido pelo autor (2022). Adaptado de (PAAKKUNAINEN, 2019). Tipicamente, o ciclo de vida de funções como serviço começa quando o código e as configurações são enviados pelo desenvolvedor para o provedor da computação em nuvem. Essas configurações contêm metadados que definem o comportamento e limitação da elasticidade da aplicação, definição das fontes de eventos e outras variáveis. Já na nuvem, o provedor recebe o código e configurações e converte em containers ou outro artefato que é implementado como uma instancia de funções. Após a criação do container, o controlador FaaS implementa e cria novas instâncias de funções baseadas em eventos. As funções ficam operantes até que a remoção seja solicitada pelo desenvolvedor da aplicação (CNCF, 2018). Backend como Serviço permite comutar processos e componentes do lado do servidor e partir para a utilização de serviços de prateleira sob demanda. Esta modalidade de serviço possibilita aos desenvolvedores terceirizarem todos os aspectos por trás de qualquer aplicação, abstrair a escrita e manutenção de sistemas para o frontend, ou seja, diretamente ligado à experiência do usuário de uma aplicação. Exemplos disso são sistemas de autenticação de dois fatores, gerenciamento de banco de dados e armazenamento de arquivos em nuvem. 27 Segundo (AMORIM, 2017), serviços de BaaS caracterizam-se por pacotes hospedados na nuvem como APIs e SDKs para serem utilizados em demais aplicações. Utilizar um backend como serviço facilita tarefas de login e armazenamento de arquivos em diversos tipos de aplicações, todo o trabalho de autenticação, por exemplo, é terceirizado para o BaaS, reduzindo assim custos, tempo de configuração e manutenção, com possibilidade de elasticidade de aplicações que se beneficiam de tal serviço. A computação sem servidor ainda não apresenta uma definição formal, pode tornar-se um desafio ao diferenciar os modelos de computação em nuvem, visto que PaaS e SaaS são modelos que também não possibilitam interação com a infraestrutura física dos servidores em nuvem. PaaS, por exemplo, abstrai os servidores do usuário, mas diferentemente do PaaS, o FaaS usa funções como unidade de implantação. Outrossim, os provedores da nuvem retem maior responsabilidade sobre a operação do software no modelo FaaS. Outra constatação é que o modelo SaaS provém funções de backend e frontend, acessível para o usuário. BaaS oferece apenas as funcionalidades backend, que se faz necessário ainda uma aplicação para utilizar (EYK, et al. 2017). Caso a computação sem servidor fosse encaixada nos modelos de computação em nuvem encontrados na Figura 1, seria encaixada entre os modelos PaaS e SaaS. Na Figura 3 sintetiza-se a arquitetura da computação sem servidor e as categorias descritas. Figura 3 – Arquitetura da computação sem servidor Fonte: Survey on serverless computing. (HASSAN, et al. 2021). 2.4 Exemplos do uso da computação sem servidor Na Figura 4 ilustra-se um exemplo do funcionamento de uma solução serverless, oferecida pela AWS Lambda. A imagem exemplifica o processamento de 28 arquivos, uma das possibilidades do modelo sem servidor. Uma fotografia é tirada a partir de qualquer dispositivo, é carregada para o sistema de armazenamento em nuvem Amazon S3, este evento aciona o sistema Lambda que se encarrega de aplicar à imagem um algoritmo de redimensionamento de imagens e, finalmente, a fotografia é redimensionada para tamanhos otimizados para web, telefones celulares e tablets. Figura 4 – Exemplo de funcionamento do AWS Lambda em processamento de arquivos Fonte: Amazon Lambda. (AWS, 2022). Outra aplicação do uso da computação sem servidor é relacionada ao IoT – Internet of Things. Na Figura 5 é possível observar o funcionamento da computação sem servidor em ambiente de internet das coisas. Sensores em um trator captam dados agindo como gatilho para plataforma serverless, que executa pedaços de código que detectam tendências, anomalias e acionam pedido de substituição de peças com defeitos. Por fim, como resultado da execução, automaticamente realiza pedido de novas peças para substituição. Figura 5 – Exemplo de funcionamento do AWS Lambda em IoT Fonte: Amazon Lambda. (AWS, 2022). Com outras propostas de soluções sem servidor, o provedor Google oferece produtos como Cloud Run, possibilitando a criação de aplicativos containerizados em linguagens como Go, Python, Java, Node.JS, .NET em poucos segundos. Cloud 29 Functions, viabilizando execução de pequenas porções de código que respondem a eventos, ou gatilhos, correspondente a um produto de função como serviço (FaaS) de forma escalonável e que é medido por período de execução, tem como base o valor de 100 milissegundos para execução (GCP, 2022). Relevante de se observar que todos os eventos e respostas são rapidamente integrados aos serviços já usados pelos provedores, como é o exemplo demonstrado na Figura 6, onde mostra-se o gatilho (mensagem de texto) acionando funções que analisam o conteúdo do texto e extração de sentimentos, por meio de inteligência artificial. Segundo o próprio provedor, é possível estender a usabilidade da computação sem servidor para criação de sites na web, integração de APIs, automação, serviços de backend e análise em tempo real de dados. Figura 6 – Exemplo de funcionamento do Google Functions em IA Fonte: Google Functions. (GCP, 2022). 2.5 Vantagens e Desvantagens É possível encontrar vantagens e desvantagens ao utilizar a computação sem servidor e analisar como os aspectos positivos e negativos se comparam com os demais modelos de computação em nuvem. Como vantagens encontradas, tem-se o escalonamento ágil, sem despesa por ociosidade, sem custo adicional por escalabilidade, redução de custo operacional, Fast Time to Market e uso eficiente de recursos. 30 • Escalonamento ágil: Provedores de serviços em nuvem escalam seus serviços automaticamente e de forma transparente para o usuário (CNCF, 2018), uma aplicação ao utilizar a arquitetura sem servidor tem a característica de elasticidade, aumentar e diminuir de tamanho conforme a necessidade, seja pelo número de usuários utilizando determinado serviço, ou até mesmo pela quantidade de eventos ocorrendo no momento (IVANOV, 2019). • Sem despesas por ociosidade: Ao utilizar os serviços de um provedor de computação em nuvem pode-se observar a capacidade de otimização de custos. No caso da computação sem servidor, quando determinada função ou aplicação está ociosa, o desenvolvedor não é cobrado por isso. Isso se dá pelo fato de as FaaS serem criadas sob demanda e, em combinação com o BaaS, os recursos são compartilhados e não alocados individualmente (CNCF, 2018). Neste cenário, não há custo dos containers ou máquinas virtuais quando o código não é executado, com o uso da computação sem servidor, um banco de dados não gera gastos ao seu desenvolvedor até que a primeira requisição ou conexão seja feita, o armazenamento não é custeado até que a primeira transferência ocorra (ADZIC, 2017). • Sem custo adicional por escalabilidade: O fato de não contabilizar a ociosidade das aplicações, como por exemplo custo, favorece também a elasticidade das aplicações. Existe o custo em relação ao tempo adicional da computação, mas não para aumentar ou diminuir determinada aplicação, isso implica em escalar do zero até milhares, milhões de requisições, o que acontece de forma transparente para o usuário, com o mínimo de custo e esforço, e máxima transparência (IVANOV, 2018). Serviços de computação sem servidor como AWS Lambda e Google Functions cobram do desenvolvedor a cada 100 ms de tempo de computação (ROBERTS, 2018). Redução de custo operacional: O uso da computação sem servidor também implica no custo operacional de uma aplicação, por conta da não necessidade de provisionar, instalar, atualizar e gerenciar a infraestrutura de servidores responsáveis pela hospedagem das aplicações. Neste quesito, o modelo de plataforma como serviço assemelha-se a premissa de redução de custos operacionais (CNCF, 2018). A adoção de máquinas virtuais pode gerar uma economia se comparada a ambientes on-premises (servidores físicos), e a computação sem servidor pode gerar uma 31 economia se comparada as máquinas virtuais ofertadas pelos provedores dos serviços em nuvem. Na Figura 7 é possível observar uma análise feita por (SCHLEIER-SMITH, et al. 2021) comparando a diferença de custo em ambientes em nuvem, servidores físicos e computação sem servidor, no que tange o custo envolvido nas diferentes modalidades. É de se notar a utilização da computação sem servidor pode gerar economia dependendo do contexto a ser utilizada, seguindo a modalidade de custo granular inerente a demanda. Figura 7 – Computação tradicional versus Computação em Nuvem versus Computação sem Servidor Fonte: SCHLEIER-SMITH, et. al (2021). • FTTM – Fast Time to Market: O tempo de uma aplicação para atingir o mercado pode ser reduzido consideravelmente quando há o uso da computação sem servidor. Premissa da necessidade de não se preocupar com a construção e provisionamento de uma infraestrutura adequada para aplicação, juntamente com o serviço compartilhado do BaaS reduzem o tempo de implementação de qualquer aplicação (ROBERTS, 2018). 32 • Uso eficiente de recursos: Por ter seus recursos compartilhados e ter um determinado tempo de vida útil, a computação sem servidor oferece uso dos recursos computacionais de feitos de forma mais eficiente. Autores (ROBERTS, 2018; KOOMEY; TAYLOR, 2017) mostram que os recursos computacionais provisionados na computação em nuvem não são totalmente utilizados. Com a computação sem servidor, provedores podem compartilhar recursos computacionais entre seus clientes de forma mais otimizada, sob demanda, sem a necessidade de reservar máquinas virtuais inteiras para apenas um cliente. Como exemplo deste ponto, para servir a cem requisições HTTP em cinco minutos, as instâncias seriam criadas sob demanda para servir as requisições, mas depois dos cinco minutos todas as instâncias seriam descartadas e a capacidade computacional poderia ser gerida para outra finalidade, para outro cliente. Em comparação a computação tradicional, um servidor dedicado ficaria ligado para servir as mesmas requisições, mas ao término do tempo, o servidor dedicado ficaria ocioso, gastando recursos e capacidade computacional. Computação sem servidor neste sentido pode permear um caminho de computação verde, mais eficiente energeticamente. As desvantagens são: desempenho, latência na inicialização, ou cold start, lock-in do provedor, segurança, precificação, sistemas legado e tempo de execução. • Desempenho: A computação sem servidor possui desafios relacionados ao desempenho e orquestração dos containers usados na execução das funções, agendamento e sobrecarga de chamadas de serviço em uma determinada instância, ativação de funções, mapeamento de eventos, ou gatilhos que geram as chamadas das execuções. Ações como tempo de inicialização, tempo de carregamento de bibliotecas e inicializações específicas no código do usuário causam impacto do ponto de vista de funções como serviço. • Latência de inicialização – cold start: Ocorre quando uma função como serviço é invocada, com base em um evento ou gatilho, a mesma deve ser executada em um container já provisionado, ou um novo container precisa ser criado durante o processo. É dado o nome de warm start, início quente quando os recursos já estão executando e, cold start, início a frio, quando os recursos precisam ser alocados antes da execução. O início a frio leva mais tempo para inicializar por conta 33 do provisionamento, atrasando a execução de determinada função em alguns milissegundos, podendo chegar a alguns segundos (PAAKKUNAINEN, 2019). Dependendo da aplicação isso pode ser um problema crítico, como aplicações web por exemplo. A repetição de inícios a frio depende do tráfego da aplicação. Aplicações com um tráfego consistente ou dez requisições por segundo se deparam com inícios a frio raramente. Já tráfegos periódicos e que oscilam demasiadamente, inícios a frio são mais frequentes (ROBERTS, 2018). O processo de como ocorre o atraso de inicialização de uma função como serviço é observado na Figura 8. Figura 8 – O cold start atrasa a execução do código Fonte: STEINBACH, et. al (2021). • Lock-in do provedor: É notável a quantidade de provedores que oferecem seus serviços de nuvem para seus clientes, especificamente a computação sem servidor. É possível notar que os serviços de computação sem servidor são amplamente integrados a outros serviços do próprio provedor, como por exemplo serviços de armazenamento e inteligência artificial. Isso gera um desafio quanto um aprisionamento a um único provedor, trazendo dificuldades na hora de migrar de um provedor para outros. Problemas dessa espécie podem ser mitigados posteriormente com padronizações e ferramentas avançadas relacionadas a computação sem servidor. Algumas ferramentas em desenvolvimento ajudam a desenvolver e implementar códigos independendo de provedores (ROBERTS, 2018), junto a isso, a Cloud Native Computing Foundation tem trabalhado na padronização da computação sem servidor, com a descrição, publicação e consumo de eventos (CNCF, 2018). 34 • Segurança: Atualmente preocupação para todo tipo de computação, seja sem servidor, na nuvem ou computação convencional. O desafio em questão é o isolamento das funções que são executadas. Por conta do compartilhamento de recursos com outros usuários e outras funções, processar e executar funções que atuam sob dados sensíveis torna-se uma tarefa preocupante no que diz respeito a segurança dessas funções. • Precificação: O foco de provedores da computação sem servidor e reduzir ao máximo os recursos computacionais empregados na execução de tarefas e funções. O modelo de precificação é desafiador, um exemplo disso é o uso de CPU que em alguns provedores é menos custoso, em contrapartida entradas e saídas podem se tornar mais caras do que máquinas virtuais dedicadas. Desta forma existe uma necessidade de atualizar métricas para precificar este tipo de serviço em nuvem. • Sistemas Legado: São sistemas mais antigos que usam técnicas e muitas vezes pré-requisitos mais obsoletos que atualmente estão fortemente presentes por muitas empresas. Em algum momento faz-se necessário levar esses sistemas legado para a nuvem e isso pode ser um desafio maior para a computação sem servidor. A migração deve acontecer em algum momento e deve chegar aos sistemas sem servidores. • Tempo de execução: O modelo de funções como serviço introduz um novo paradigma para codificação e execução de aplicações na nuvem. Por acionar containers responsáveis pela execução das funções que facilmente podem ser descartados, todas as funções não devem salvar estado ou informação durante suas invocações. Os provedores de computação sem servidor restringem o tempo de execução das funções, se determinada função não é acionada e executada durante um tempo, tal função é descartada. Como exemplo, AWS restringe o uso de funções na Lambda em 15 minutos (AWS, 2022), já o Google, com seu serviço Google Functions, resistente a execução das funções em 9 minutos (GCP, 2022). Por fim, uma comparação pode ser observada na Tabela 3, que leva em consideração aspectos como facilidade de desenvolvimento de aplicações, escalabilidade, ciclo de vida de uma função, segurança, resolução de problemas, 35 tolerância a falhas, custo de carga variável, carga estática e usuário para qual é voltado. Tabela 3 – Comparação entre serverless e computação tradicional Característica Tradicional Sem Servidor Desenvolvimento de aplicações Difícil Fácil Escalabilidade Difícil Fácil Ciclo de vida da função Longa Rápida Segurança Complexa Complexa Resolução de Problemas Fácil Difícil Tolerância a falhas Menos confiável Mais confiável Custo (Carga variável) Caro Barato Custo (Carga estática) Barato Caro Usuário Administrador e Desenvolvedor Desenvolvedor Fonte: Desenvolvido pelo autor (2022). Adaptado de (HASSAN, et al. 2021). 36 CAPÍTULO 3 – PLATAFORMAS SERVERLESS Neste presente capítulo diferentes formas de implementação da computação sem servidor são expostas, tanto do ponto de vista comercial quanto do ponto de vista opensource. Encontram-se também no capítulo alguns comparativos entre plataformas de computação sem servidor, e diferentes aplicabilidades. 3.1 Plataformas comerciais Existem vários provedores de computação em nuvem que oferecem a computação sem servidor, diversas plataformas oferecem funcionalidades e linguagens de programação distintas. Provedores comerciais distribuem soluções prioritárias e vinculadas a outros serviços do próprio provedor, portanto existe uma crescente tendência a plataformas serverless de sistema aberto (MANOR; TEICH, 2019). Na Tabela 4 são apresentados os três principais provedores de computação sem servidor, suas respectivas linguagens de programação suportadas, preço por um milhão de requisições e preço por um milhão de segundos, ambos os preços em dólares. Tabela 4 – Lista dos três principais provedores de computação sem servidor - FaaS Provedor Linguagens suportadas Preço por 1M de requisições Preço por 1M de segundos AWS Lambda Java, Go, PowerShell, Node.JS, C#, Python, Ruby, ambientes de execução personalizados $0.2 e $3.7 (HTTP) $0,208 Azure Functions C#, JavaScript, F#, Java, Python, TypeScript, PHP, Batch, Bash, PowerShell $0.2 $0.2 Google Cloud Functions Node.JS, Python, Go $0.4 $0,213 Fonte: Adaptado de PAAKKUNAINEN (2019). Dois dos três maiores provedores de computação sem servidor suportam pelo menos cinco linguagens de programação diferentes, AWS Lambda oferece ainda um 37 ambiente de execução personalizado, estendendo o suporte a outras linguagens de programação (AWS, 2022). O mesmo autor elucida também a ideia de diferentes cargas de trabalho para os provedores de computação sem servidor e o custo inerente às cargas. É possível observar na Tabela 5 cargas de trabalho de 10 bilhões de requisições HTTP em 200 milissegundos e 10 milhões de requisições assíncronas em 60 segundos de cada uma dos provedores, os valores estão quantificados em dólares. Tabela 5 – Comparação entre custo das plataformas FaaS Carga de Trabalho AWS Lambda Azure Functions Google Cloud Functions 10 bilhões de requisições 200ms $4116.75 $600.00 $862.50 10 milhões de requisições assíncronas $1252.25 $1202.00 $1391,50 Fonte: Adaptado de PAAKKUNAINEN (2019). Provedores de computação sem servidor também possuem diferenças relacionadas a quão rápida uma função é executada, o que é importante pois afeta diretamente o custo de execução das funções como serviço (RANDALL, 2018). Tempos de execução, os inícios a frio e início quente (cold e warm start) diferem também dependendo da linguagem de programação empregada (ALLIAUME; LE ROUX, 2018). Diversos comparativos entre as plataformas comerciais são feitos para diferentes funcionalidades que entregam aos consumidores, (KUMAR; SELVAKUMARA, 2022) realizaram testes e análises de desempenho e escalabilidade das plataformas da Google, Microsoft, Amazon e IBM. Na Figura 9 mostra-se o desempenho das quatro provedores de computação sem servidor em relação à execução 500 a 10000 funções concorrentes. Com a análise realizada na Figura 9, é possível interpretar que ao início da execução, o serviço AWS atinge sua máxima capacidade de requisições concorrentes. Azure Functions e IBM têm um comportamento similar, atingindo um limite de 200 invocações e declinando conforme o número de execuções vai aumentando. Google Functions por sua vez, exibe um moderado e consistente 38 aumento na largura de banda, sendo mais rápido, ao final do experimento, que IBM e Azure. Figura 9 – Relação entre a taxa de transferência por segundo e o número de execuções concorrentes Fonte: KUMAR; SELVAKUMARA (2022). Outra análise feita pelo estudo compara a carga de trabalho do processamento da CPU (KUMAR; SELVAKUMARA, 2022). Os pesquisadores desenvolveram uma função de multiplicação de matrizes para estressar o poder de CPU executando uma função com invocações simultâneas na multiplicação de uma matriz bidimensional. Na Figura 10 ilustra-se a execução entre um e cem invocações simultâneas ao longo da duração de execução da função. 39 Figura 10 – Sobrecarga para a simultaneidade da CPU Fonte: KUMAR; SELVAKUMARA (2022). Tais razões elevam a importância de se escolher o melhor provedor de computação sem servidor, é necessário testar cuidadosamente a carga de trabalho e linguagem de programação para que o custo seja otimizado (BALDINI, et al. 2017). 3.2 Plataformas FaaS opensource Plataformas de código aberto são uma opção viável para evitar aprisionamentos do provedor – lock-in discutidos na seção 2.5 – e não depender de apenas um provedor, possibilita assim uma construção heterogênea de soluções sem servidor (MOHANTY, 2018). Plataformas de código aberto permitem execução de cargas de trabalho em nuvens privadas. O ponto negativo desta prática da nuvem privada implica diretamente na escalabilidade da solução, que é limitada se comparada a uma nuvem pública, isso é um contraponto à computação sem servidor, que tem como premissas a rápida elasticidade de aplicações e redução de gastos. É possível encontrar múltiplas plataformas de FaaS na revisão da literatura, é importante considerar alguns aspectos na hora de escolher a plataforma ideal para dada necessidade. Na Tabela 6 são listadas as plataformas de código aberto mais 40 populares e suas características de linguagens suportadas, métricas de auto escalonamento, orquestrador de containers e acionador das funções. A computação sem servidor apresenta um novo conceito e abstração da computação em nuvem e tais plataformas, sejam comerciais ou de código aberto, ainda estão evoluindo. É possível visualizar a evolução das plataformas e melhorias futuras que estão sendo desenvolvidas continuamente pelas equipes. De todas as plataformas não há claramente uma vencedora ou uma como modelo a ser seguido, uma boa abordagem para os próximos passos seria a criação de padronizações e melhores práticas para se desenvolver e usar tais plataformas FaaS. Tabela 6 – Lista de plataformas opensource Plataforma Linguagens Suportadas Métrica de auto escalonamento Orquestrador de container Acionador de função Fission C#, Go, Node.JS, Java, Pearl, Python, PHP, Ruby, ambientes de execução customizados CPU Kubernetes HTTP, evento, agendamento Kubeless C#, Go, Node.JS, Java, Python, PHP, Ruby, Ballerina, linguagens customizadas CPU, QPS, métricas customizadas Kubernetes HTTP, evento, agendamento OpenFaaS C#, Go, Node.JS, Java, Python, PHP, ambientes de execução customizados CPU, memória, QPS Kubernetes, Docker Swarm, orquestradores customizados HTTP, evento OpenWhisk Ballerina, C#, Go, Java, JavaScript, Python, Ruby, PHP, Swift, ambientes de execução customizados QPS Não necessita de orquestrador HTTP, evento, agendamento Fonte: Adaptado de PAAKKUNAINEN (2019). Em plataformas de funções sob demanda, alguns fatores importantes para a escolha da plataforma, são eles: 41 • Desempenho: Comparar o desempenho entre plataformas FaaS de código aberto mostra-se relevante por cada plataforma pode performar diferentemente dependendo dos eventos ou da linguagem de programação usada. (MOHANTY, 2018; BALDINI, 2017) observou um tempo de resposta três vezes maior entre a plataforma FaaS mais lenta e a mais rápida em certas situações, o mesmo estudo mediu que, enquanto pequena, existem diferenças de desempenho entre diferentes tipos de gatilhos que desencadeiam eventos. • Comunidade de desenvolvedores: Projetos opensource podem ter o seu desenvolvimento lento, é necessário que o projeto tenha larga escala e abrangência para que se tenha uma comunidade ativa, ou até mesmo empresas que auxiliam projetos a avançar. Plataformas como Fission, Kubeless, OpenFaaS e OpenWhisk possuem uma comunidade relativamente ativa. • Linguagem de programação: As plataformas listadas na Tabela 6 interagem com várias linguagens de programação, que abrangem vários tipos de casos de uso. Quando não há suporte para uma linguagem em particular é possível utilizar ambientes de execução customizado, mas pode se tornar uma tarefa difícil e custosa fazer a manutenção desses ambientes. Com isso, as linguagens mais populares podem performar de formas diferentes, por exemplo Python que pode se mostrar mais rápida que outras linguagens de programação. O desempenho deve ser testado em diferentes linguagens de programação, a partir de diferentes plataformas de computação sem servidor (BALDINI, 2017). • Métricas de auto escalonamento: Auto escalonamento está inerente a capacidade das plataformas de aumentar ou diminuir de tamanho, boas métricas de auto escalonamento permitem melhor escalonamento granular. Para o uso intenso de CPU é mais usual utilizar métricas de auto escalonamento baseados em uso de CPU, métricas de QPS (requisições por segundo) são mais úteis em ambientes de execução com entrada e saída (I/O) mais intensas. Kubeless e OpenFaaS possuem maior repertório de métricas de escalonamento. 42 • Orquestrador de container: Os orquestradores gerenciam a infraestrutura de containers da aplicação. É imprescindível que a plataforma FaaS tenha suporte aos orquestradores já existentes para não adicionar maior complexidade a aplicação, OpenWhisk, por exemplo, não precisa de um orquestrador separado e Fission, Kubeless e OpenFaaS oferecem suporte ao Kubernetes. • Acionadores de funções: Plataformas FaaS suportam três diferentes tipos de gatilhos de funções: HTTP, evento e agendamento. HTTP são requisições HTTP que no início de uma execução de função retornam uma reposta ao cliente HTTP. Eventos envolvem transmissão de filas de mensagens externas, esses eventos podem ser originados de qualquer aplicação que tenha a capacidade de adicionar uma nova mensagem à fila. Os eventos acionam as funções de forma assíncrona (vide Figura 2). Agendamento dispara um gatilho para acionar o evento em um momento pré-definido pelo desenvolvedor da aplicação, por exemplo uma vez ao dia ou uma vez na semana. 3.3 Comparação entre plataformas disponíveis e o desenvolvimento tradicional de software As plataformas de computação sem servidor chamam a atenção de grandes provedores de serviços em nuvem e dos desenvolvedores de plataformas serverless opensource, com o principal motivo de fugir dos aprisionamentos dos provedores. Na Tabela 7 é mostrada uma comparação das plataformas serverless que mais chamam atenção em trabalhos acadêmicos reunidos no presente estudo. A comparação aborda características como por exemplo interação da plataforma com o desenvolvedor, se há plugin que integra a alguma plataforma de desenvolvimento (IDE), estilo da cobrança feita pelo provedor, limitação de tempo e tamanho de pacote, qual tamanho da disponibilidade de alocação de memória, como é possível monitorar, ou observar, as execuções e se há uma prateleira, ou marketplace, de funções pré- existentes já executadas anteriormente e compartilhadas na plataforma. 43 Tabela 7 – Comparação entre plataformas serverless Caracte- rísticas AWS Lambda Azure Functions Google Functions OpenWhisk OpenFaaS Interface do usuário CLI, API e GUI CLI, API e GUI CLI, API e GUI CLI e API CLI, API e GUI Desenvol- vimento em IDE VS e VSCode VS e VSCode Não disponível X-Code e VSCode Não disponível Cobrança Tempo de execução e Alocação de memória Tempo de execução e memória consumida Tempo de execução e memória alocada Tempo de execução e memória alocada Desconheci- do Limitação de tempo 900 segundos 600 segundos 540 segundos 600 segundos 30 segundos Limitação de tamanho de pacote 250 MB descomprimido ou 50 MB comprimido Sem limite 500 MB descomprimido ou 100 MB comprimido 48 MB descomprimido Desconheci- do Alocação de memória 128 MB a 10.240 MB 1536 MB 128 MB a 4.096 MB 128 MB a 2048 MB Desconhecido Observa- bilidade AWS Cloud Watch, AWS CloudTrail Azure Application Insights Google Cloud Operations Ferramentas terceiras Ferramentas terceiras Prateleira serverless AWS Serverless Application Repository Azure Marketplace Não disponível Não disponível OpenFaaS Function Store Fonte: Adaptado de WEN et. al (2023). O desenvolvimento tradicional de software diferencia-se em relação ao desenvolvimento baseado na tecnologia serverless em alguns aspectos importantes. O desenvolvimento tradicional pode se dividir em uma tangente on-premises e outra usando a computação em nuvem. Na Tabela 8 são mostradas características importantes no desenvolvimento de software tradicional e o desenvolvimento baseado em serverless. Na tabela, características como desempenho, implementação de funcionalidades, padrão de invocação, limitação de execuções, localidade da execução e maturidade são comparadas. 44 Tabela 8 – Comparação entre desenvolvimento de software on-premises, em nuvem e serverless Características Desenvolvimento on-premises Desenvolvimento em cloud Desenvolvimento serverless Desempenho Sempre ativo, sem cold start, mas sem flexibilidade Ativo sob demanda, sem cold start, com flexibilidade Ativo sob gatilhos, com cold start, com flexibilidade Implementação de funcionalidades Implementação desde o momento zero, baixa eficiência Implementação parcial desde o momento zero, eficiência média Código baseado em eventos, utilização do BaaS simplificada, altamente eficiente Padrão de Invocação Chamada pelo lado do cliente Chamada pelo lado do cliente Evento baseado em gatilho Limitação de execuções Depende da capacidade do servidor Depende da capacidade alugada Limitações inerentes fixas Localidade da execução Localmente Nuvem Nuvem Maturidade Alta Média Baixa Fonte: Adaptado pelo autor de WEN et al. 2023. • Desempenho: O ambiente de execução está sempre ativo em ambientes de desenvolvimento on-premises, o que faz com que as requisições da aplicação sejam respondidas imediatamente, em contrapartida, os recursos continuam sendo utilizados mesmo quando não há nenhuma requisição. Junto a isso existe o problema da flexibilidade dessas aplicações, a depender a quantidade de recursos computacionais que estão à disposição da aplicação no momento de muitas requisições, como é abordado em (INTERSOG, 2022) e (NETWORKINREVIER, 2022). Essa situação melhora ao migrar para o desenvolvimento em nuvem, que pode ter a flexibilidade sob demanda da aplicação, a elasticidade garante que independentemente do número de requisições, haverá recurso computacional suficiente para a resposta, mesmo que esse recurso sempre esteja ativo, aguardando 45 determinada requisição acontecer, o que se pode interpretar como um arranque a frio inexistente. O desenvolvimento serverless sofre com o arranque a frio, no qual a resposta a requisições depende de um evento que engatilha a execução do código, e esse tempo de preparação pode ser longo em comparação aos outros ambientes de desenvolvimento, existem alguns estudos tentam mitigar esse problema, como é visto em (AKKUS, 2018; CADDEN, et al. 2020; DAW, et al. 2020; OAKES, 2018; WANG, et al. 2019; ZUK; RZADCA, 2020). • Implementação de funcionalidades: A implementação de funcionalidades no desenvolvimento de software em ambientes de servidores físicos precisa contar com um processo complexo de escolha da pilha de tecnologias a serem utilizadas, além de frameworks que precisam estar atualizados. Localmente é preciso preparar todo o ambiente para que determinada aplicação seja desenvolvida com a compatibilidade, versionamento e atualizações corretas. Em nuvem, o processo torna- se um pouco menos complexo, mas ainda sim necessitando da configuração do ambiente que vai receber a aplicação (NOVACONTEXT, 2022). A implementação em ambiente sem servidor permite aplicações desenhadas sob medidas para serem acionados baseado em um evento, funções que tem uma curta duração de execução, dessa forma o backend e o armazenamento, por exemplo, custam um menor tempo para o desenvolvedor. • Padrão de invocação: Por ter um desempenho baseada em eventos pré-configurados, as aplicações serverless são invocadas automaticamente (JONAS, 2019; EYK, 2018). No desenvolvimento convencional, as invocações dependem das chamadas pelo lado do cliente, o que pode trazer maior complexidade para processos do servidor (ADZIC, 2017). • Limitação de Execução: A definição da limitação de execuções em ambientes on-premises é muito incerta, pois depende muito da capacidade física de cada servidor. Em um ambiente de nuvem, o desenvolvedor tem flexibilidade de alocação de recursos para sua aplicação, ao passo que a limitação de execução acompanha a alocação de recursos (BONER, 2016). No desenvolvimento serverless existem uma série de limitações quanto ao timeout de execução de funções. Confinamento do tamanho da memória e armazenamento (EYK, et al. 2018). 46 • Localidade da Execução: A localidade da execução em aplicações on- premises é a mesma que a do desenvolvedor, já a localidade na nuvem e, consequentemente, serverless é executada de forma invisível ao desenvolvedor e depende da localidade na nuvem onde existem recursos suficientes para a execução, sob responsabilidade da disponibilidade do provedor do serviço em nuvem, pode não ter necessariamente a melhor latência (NEWMAN, 2021) e (TAIBI, 2020). • Maturidade: A maturidade em ambientes on-premises é considerada alta pois funcionalidades de teste e debugging de aplicações podem ser desenvolvidas e avaliadas dentro do próprio ambiente local de desenvolvimento. Hoje em dia existe uma variedade de ferramentas que desempenham essas tarefas e estão amplamente distribuídas na comunidade de engenharia de software. Por ser uma tecnologia já estudada a muitos anos, ambientes de desenvolvimento em nuvem já possuem suas próprias ferramentas que ajudam a automatizar o processo de teste de uma aplicação, geralmente os próprios provedores de serviços em nuvem já trazem uma suíte de ferramentas que ajudam o desenvolvedor (A3LOGICS, 2022) e (COTRONEO, 2015). Já a emergente tecnologia serverless ainda carece de ferramentas de teste e debug (LENARDUZI; PANICHELLA, 2020), uma das razões é pelo funcionamento baseado em eventos, largamente distribuído e execução mascarada, ou invisível, para o desenvolvedor, o que torna o acompanhamento do fluxo de execução mais difícil de acompanhar e testar. 3.4 Microsserviços e suas características Os microsserviços oferecem o desenvolvimento de aplicações que se baseia em subdividir uma aplicação em pequenos serviços independentes entre si, que trabalham em conjunto como um único sistema. Microsserviços se apresentam também como um paradigma eficaz para aplicações distribuídas e elásticas, sendo amplamente empregada na indústria e academia. O desenvolvimento de microsserviços baseia-se na decomposição de uma aplicação em um conjunto de serviços, e cada um dos serviços é responsável por uma funcionalidade específica (BRINZA, 2022). Permite dessa forma o teste, desenvolvimento e implantação de forma independente, facilitando gerenciamento de determinada solução. 47 Um exemplo disso é um site de vendas, que pode ser modularizado em vários serviços, um sendo responsável pelo login do usuário, outro pelo cadastro, outro pelo pagamento de produtos, outros pelo cadastro de produtos. O exemplo permite que parte da aplicação continue funcionando mesmo quando as outras partes, ou módulos, deixem de funcionar. Esses módulos podem ser escritos em diferentes linguagens de programação e conversam entre si por meio de API. Módulos podem ser atualizados, substituídos, modificados sem refletir na aplicação como um todo. Segundo o artigo de (BUSHONG, et al. 2021), os Microsserviços contam com vantagens como escalabilidade, flexibilidade, agilidade no desenvolvimento, pontos que se também se evidenciam na tecnologia serverless. Outros trabalhos, como de (TAIBI, et al. 2022) e (BARESI; GARRIGA, 2019) apontam também como uma boa alternativa para aplicações complexas que necessitam de escalabilidade para lidar com grande quantidade de tráfego de dados e substituição de aplicações hospedadas em monólitos. Da mesma forma que a computação sem servidor, o uso de microsserviços em nuvem permite o desenvolvimento escalável e flexível, com recursos computacionais alocados dinamicamente de forma invisível para o desenvolvedor e para o usuário, permitindo assim a elasticidade necessária para aplicações em nuvem heterógenas. Por se tratar de serviços independentes interconectados, há a tolerância a falhas e resiliência de serviços nos Microsserviços (BUSHONG, 2021). A arquitetura de Microsserviços permite o isolamento de falas quando ocorrem, evita-se que uma falha afete outras partes da aplicação ou até mesmo a aplicação como um todo, a modularidade oferecida pelos Microsserviços reforça a premissa de implementação de recuperação e redundância, fortalecendo a resiliência da aplicação. As aplicações que usam os microsserviços também apresentam desafios parecidos com o paradigma serverless, a segurança de serviços isolados e orquestração de tais serviços devem ser mitigados ao utilizar-se da tecnologia. 3.5 Monólitos, Microsserviços, Containers e Serverless Várias aplicações podem ser desenvolvidas com diferentes objetivos e diferentes funcionalidades. Historicamente, as aplicações foram desenvolvidas e hospedadas em servidores chamados de monólitos, computadores com grande 48 capacidade de hardware hospedados localmente em empresas. Os avanços tecnológicos possibilitaram a migração para a computação altamente distribuída. O modelo de computação de monólito, ou monolítica, é adequada para aplicações de pequeno porte. No entanto, algumas aplicações começam pequenas e vão ganhando implementações com o tempo e consequentemente aumentando de tamanho, o que se torna uma desvantagem para este modelo, que tem como premissa ter a execução, armazenamento e toda codificação em um único computador (KAZANAVICIUS; MAZEIKA, 2019). Na Figura 11 é ilustrado um exemplo de entrada e saída de dados em uma aplicação monolítica. É possível observar que o mesmo servidor interage com requisições HTTP, armazena, executa, manipula dados sozinho, de forma não distribuída. Figura 11 – Exemplo de computação em monólitos Fonte: Desenvolvido pelo autor (2023) Quando a complexidade da aplicação e número de acessos simultâneos aumenta, bem como a necessidade de manutenção do código, torna-se difícil implementar funcionalidades sem comprometer a disponibilidade. Além disso, segundo (NEWMAN, 2021), a escalabilidade é comprometida quando há sobrecarga na aplicação, o monólito é deficiente no que tange a elasticidade vertical ou horizontal de uma determinada aplicação. Como uma forma de mitigar problemas advindos dos monólitos, o conceito de microsserviços foi criado com o objetivo de adicionar maior granularidade à computação moderna. Os microsserviços passaram a atender funcionalidades de um 49 sistema, não o sistema como um todo, como é ilustrado na Figura 12. Os microsserviços podem ser comunicar através de protocolos RPC, REST, SOAP e podem utilizar de API Gateways para manter uma harmonia entre a execução deles, de forma orquestrada, sem perder a independência de cada serviço. Os serviços podem ser desenvolvidos e escalar individualmente, dependendo do nível de carga de cada um. Seguindo o exemplo da Figura 12, se o serviço de login de um sistema receber múltiplas requisições por segundo, apenas o módulo de login pode aumentar de tamanho, isso serve para qualquer outro microsserviço. Figura 12 – Exemplo de computação em Microsserviços Fonte: Desenvolvido pelo autor (2023) Microsserviços apresentam além da escalabilidade, facilidade na flexibilidade de cada função, à luz das necessidades do negócio, resiliência a falhas por conta da independência dos microsserviços e facilidade de desenvolvimento, pois são pequenos pedaços de código, semelhante às funções serverless. Entretanto, os microsserviços apresentam desafios como alta complexidade de gerenciamento, devida a alta distribuição de serviços. Na Figura 13 ilustra-se a ideia central e principal diferença entre a computação sem servidor e os demais paradigmas da computação em nuvem e de alto desempenho. De forma a simplificar ainda mais os processos das aplicações, é possível com este modelo criar funções que executam partes específicas de código para determinada funcionalidade do sistema, execução baseada em gatilhos acionados pelo usuário ou pelo programador. No exemplo mostrado na Figura 13, 50 funções pré-estabelecidas são executadas quando um novo login ou cadastro é realizado, um novo produto é criado ou consultado. Figura 13 – Exemplo de computação serverless Fonte: Desenvolvido pelo autor (2023) A ideia de dividir uma aplicação, ou parte dela, em funções, promove a economia de recursos computacionais e de custos dentro da computação em nuvem onde determinada aplicação pode ser hospedada. Outro conceito que se refere o isolamento de processos, portabilidade e minimização da complexidade dos ambientes é o de containers, amplamente usado na indústria há dez anos, segundo (RANDAL, 2020). O conceito de dividir em containers é a possibilidade de isolar ou encapsular kernel, processos e recursos computacionais, onde cada container tem um número identificador único que, apesar de isolado, pode trabalhar em conjunto com outros containers, de forma orquestrada. O container agrega a aplicação e suas dependências facilitando a implementação em qualquer ambiente, trazendo uma abstração a mais no contexto da nuvem e máquinas virtuais. Segundo (JAMBUNATHAN; YOGANATHAN, 2018), é interessante destacar possibilidades como a solução de problemas de conflitos de dependências: se módulos de aplicações rodam em diferentes versões de uma linguagem de programação, basta separar em containers; instalar uma nova aplicação em um novo ambiente pode ser simples se utilizado containers. Em relação a orquestração de diversos containers, é importante automatizar o esforço operacional para executar aplicações conteinerizadas, implementando um 51 ciclo de vida de três etapas de um container, discutido por (KHAN, 2017): Criação ou instanciação com base em configurações pré-estabelecidas, escalonamento de forma horizontal com base em métricas pré-definidas e rede, que se baseia na adição automática em uma rede virtual previamente configurada. Diversos estudos comparam as possibilidades das abstrações, a evolução é constante e os cenários possíveis são ilimitados, podemos colocar em perspectiva: • Containers e Serverless: Pode-se entender que a computação sem servidor é uma evolução dos containers, por conta da perspectiva de melhor eficiência de funções serverless em relação a implementação de containers, impactando no tempo e custo de uma aplicação. Containers reduzem a necessidade de gerenciamento de máquinas virtuais e possibilitam a escalabilidade, serverless dá um passo além e elimina a necessidade de gerenciar ainda mais a infraestrutura e runtimes, por exemplo, bastando apenas entregar o código a ser executado à plataforma serverless. Serverless não exclui containers no desenvolvimento de aplicações, é possível até encapsular containers dentro de funções e conteinerizar funções. Serverless é uma técnica para desenvolver aplicações distribuídas e container é uma boa plataforma para construir essas funções. É possível visualizar que muitos benefícios podem ser extraídos entre a combinação dos dois. • Containers e Microsserviços: Containers são leves e portáteis, podem ser implementados e provisionados com facilidade em qualquer ambiente, seja on premises ou na nuvem, é consideravelmente escalável e possibilita diversas linguagens diferentes em seu desenvolvimento. Da mesma forma que uma máquina virtual, possui seu ciclo de vida e é suportado por todas os provedores de computação em nuvem. Os microsserviços são promovidos pela possibilidade e desafio de converter aplicações monolíticas, tem a premissa de decompor uma aplicação em diversos pequenos serviços integrados, microsserviços estes que se comunicam de forma síncrona ou assíncrona. Esses microsserviços são isolados e fáceis de escalar, além de tolerarem falhas, focado em aplicações distribuídas. 52 • Microsserviços e Serverless: Um microsserviço é um pedaço de uma grande aplicação que foi “quebrada” em pequenos e modulares serviços. Sobre o teste, construção e implementação, traz benefícios para o desenvolvimento de aplicações de forma mais ágil apesar de ser complexo e desafiador quanto a migração de monólitos. Serverless é uma camada maior de abstração já constatada em microsserviços, onde o foco é o desenvolvimento de aplicações sem a preocupação nas camadas de segurança, escalabilidade e disponibilidade dos servidores. Promove dessa forma a melhor economia em relação ao hardware que suporta a aplicação, melhor gerenciamento dos recursos computacionais, sejam eles sendo acionados de forma elástica. Computação sem servidor também é um facilitador de aplicações em microsserviços, permite o uso de uma infraestrutura e recursos computacionais baseados em eventos, controlado com base na necessidade da aplicação. Microsserviços e computação serverless podem complementar um ao outro, serverless permite que microsserviços sejam aplicados e executados com o mínimo de esforço possível por parte do desenvolvedor. Para sintetizar as possibilidades, na Figura 14 demonstra-se como paradigmas da computação foram aperfeiçoando-se e evoluindo para possibilidades que são possíveis hoje. Todos os modelos apresentados na imagem são utilizados em larga escala e atendem a determinadas e especificas demandas, dependendo da aplicação. Na Figura 14 tem-se um exemplo da computação monolítica que pode ser escalada vertical ou horizontalmente, camadas de persistência, lógica de negócio e apresentação podem ser segmentadas, distribuídas, se transformar em containers, microsserviços ou até mesmo funções. 53 Figura 14 – Desenvolvimento de Microsserviços e Funções Fonte: Desenvolvido pelo autor (2023). 54 CAPÍTULO 4 – DESENVOLVIMENTO Neste capítulo elucida-se a aplicação prática em um projeto de serviço web, quais tecnologias são usadas e o funcionamento do projeto. É possível encontrar sucesso no trabalho de autores que migraram serviços monolíticos para Funções Como Serviço, constatações interessantes em relação ao desempenho das aplicações web, facilidade na implementação de código, custo reduzido e mitigação do cold start são dados a serem observados no presente trabalho. 4.1 Arquitetura da aplicação web A aplicação web utilizada no desenvolvimento é baseada na linguagem de programação JavaScript, com um ambiente de execução e biblioteca, baseado em eventos assíncronos nomeado Node.JS. Essa tecnologia é amplamente adotada no desenvolvimento de aplicações web “server-side”, ou seja, uma programação ao lado do servidor que o ele entende (NODE.JS, 2023). Além disso, o Node.JS é baseado em eventos, é escalável, por conta da possibilidade de processamento simultâneo de várias requisições e, por conta disso está em conformidade com as premissas já vistas na computação sem servidor. O foco do Node.JS no contexto da aplicação é agir como um backend do sistema, servir como um interceptor de requisições HTTP e HTTPS e respondê-las. Com isso é possível criar REST APIs, microsserviços, containers e funções sob demanda. Há a possibilidade, com o Node.JS, integrar outros serviços de forma stateful, quando há a necessidade de uma instância conversar com um banco de dados, ou criar uma relação com um socket carregando um “estado”. Outra forma é manter uma comunicação stateless, ou a independência de manter um estado, quando não há uma garantia de relação e integridade com outros objetos, segundo (PAAKKUNAINEN, 2019), o que mais pactua com o princípio de funções como serviço – FaaS. Na Figura 15 é ilustrada a arquitetura de um serviço web usando Node.JS. É possível verificar algumas possibilidades quanto ao seu uso stateless ou stateful, a imagem representa a possibilidade de interação entre o ambiente Node.JS e um banco de dados (stateful) ou até mesmo a interação dele com serviços de 55 armazenamento em nuvem como o Amazon S3, Azure Blob Storage e Google Cloud Storage (stateless). Todo o pacote backend pode ser alocado em containers, ou acionar uma função como serviço. Figura 15 – Arquitetura de um serviço web usando Node.JS Fonte: Desenvolvido pelo autor (2023). A aplicação web necessita ser facilmente elástica para aguentar diferentes cargas de estresse e fácil de ser manuseada, para que o time de programadores que fazem a manutenção do código possa entender e implementar código. Por essa razão, é interessante pensar em implementar a computação sem servidor para parte da aplicação, focada na arquitetura do backend. A aplicação consiste em um frontend escrito pela trindade HTML5, linguagem de marcação, base para construção de páginas web interpretadas pelos navegadores de Internet que possibilita a criação e publicação de conteúdo como textos, imagens, formulários, entre outros elementos; CSS3, linguagem de estilos, que define formatos estéticos e visuais dentro de uma página web, possibilita efeitos visuais para textos e imagens e padrões de layout dessas páginas e JavaScript, linguagem de comportamento dos conteúdos dinâmicos, controles de mídia e interatividade da página web com o usuário. A linguagem JavaScript tradicionalmente é utilizada no frontend, linguagem de script web do lado do cliente. O Node.JS estende essa capacidade do JavaScript para 56 além do frontend, possibilita ampliar a arquitetura web para o backend, do lado do servidor, assim como o paradigma serverless da computação em nuvem. O serviço a ser testado consiste em uma única página frontend para um backend, que retorna um REST API para o frontend. Todos os dados inseridos no frontend são trazidos ao backend por meio de uma API. Backend e frontend são independentes entre si. Seu funcionamento ocorre da seguinte forma: a) O usuário do sistema insere informações de cadastro e faz upload de uma imagem, que posteriormente será utilizada para autenticação desse usuário; i. A imagem salva pode estar em diferentes tamanhos e até mesmo diferentes formatos, por conta disso, o sistema aceita apenas tamanho máximo de 6 MB e formatos .PNG e .JPG. b) A imagem capturada é salva em um diretório com a nomenclatura única do usuário; i. Um módulo do backend Node.JS chamado “Sharp” processa a imagem e a redimensiona para que pese menos no armazenamento do servidor. c) Informações do usuário são enviadas para um banco de dados; i. Essa etapa do processo não foi abordada pelos testes e implementações do presente trabalho de dissertação. d) O usuário utiliza o sistema com as suas credenciais, suas informações salvas e foto de perfil são retornadas para o uso do sistema. Os passos previstos na execução do backend da aplicação, mais especificamente o processo de redimensionamento de imagens, dão luz a possibilidade de usar funções da computação sem servidor (FaaS) para executar o código Node.JS baseado em evento, o upload de uma imagem do usuário para um diretório qualquer. Para alinhar os testes e obter resultados comparativos de desempenho da aplicação, o processo b-i da subseção 4.1 funcionará como um evento que aciona o gatilho de uma função executada em um provedor de computação sem servidor na nuvem. A investigação contempla a execução da parte de redimensionamento de imagem usando a biblioteca Sharp do Node.JS da aplicação web nos parâmetros de 57 computação em nuvem: Implementação da biblioteca e execução do código em três provedores de computação serverless em nuvem Amazon AWS, Google Cloud Platform e Microsoft Azure. Primeiro teste e comparativo engloba a execução e medição em um container na nuvem, atuando como um PaaS e comparar ao funcionamento de uma função serverless FaaS, em sequência, as funções dos três provedores serão comparadas. As métricas que serão usadas no trabalho são: i. Comparar desempenho de containers e serverless, nos provedores de computação em nuvem, acerca do tempo de execução das funções sem servidor. “Quanto o tempo de execução vai impactar a aplicação? Será mais interessante implementar containers ou funções?” ii. Comparar provedores serverless em relação ao custo monetário da execução da aplicação. “Qual provedor terá melhor custo para essa aplicação específica?” • Em ambos os casos, dois testes serão conduzidos: um teste de carga incremental e outro teste de pico de carga, de tráfego não convencional sobre as aplicações usando a ferramenta Apache JMeter. 4.2 Testes de desempenho A primeira plataforma serverless a receber as requisições é AWS Lambda, seguida da Azure Functions e por fim Google Functions. Todos os testes foram executados em duas regiões diferentes, uma com melhor latência em relação ao computador que conduz os testes e outra região com melhor custo-benefício financeiro. 4.2.1 AWS Lambda Em relação a plataforma AWS, a região que apresenta a melhor latência é São Paulo (sa-east-1), com aproximadamente 60ms de tempo de resposta, em contrapartida não é a região com o melhor custo financeiro. No que tange a região 58 com melhor custo-benefício para os testes, Virginia (us-east-1), no Leste dos Estados Unidos apresenta latência de 190ms. Como linguagem de programação utilizada, a plataforma Lambda oferece runtime para Node.JS com diferentes SDK para JavaScript. Na Tabela 9 mostram-se os runtimes suportados. Tabela 9 - runtimes do Node.JS no AWS Lambda Node.JS Nome SDK S. O Arquitetura Ciclo de Vida Node.JS 20 3.362.0 Amazon Linux 2023 X86_x64 e ARM64 Não anunciado Node.JS 18 3.362.0 Amazon Linux 2 X86_x64 e ARM64 Não anunciado Node.JS 16 2.1374.0 Amazon Linux 2 X86_x64 e ARM64 12 junho de 2024 Node.JS 14 2.1374.0 Amazon Linux 2 X86_x64 e ARM64 27 novembro de 2023 Fonte: Desenvolvido pelo autor (2023) No momento da criação da função é possível selecionar o runtime. Neste caso, a versão 18 é usada. O console da plataforma cria uma função de arquivo único