Implementação de Serviços em Nuvem Baseado no Conceito de Serverless

Transcrição

1 Implementação de Serviços em Nuvem Baseado no Conceito de Serverless Felipe Augusto Braga¹, Marcos A. Lopes da Silva¹ ¹Sistema de Informação Centro Universitário do Triângulo (UNITRI) Av. Nicomedes Alves dos Santos, 4545, Bairro Gávea - CEP Uberlândia MG Brasil felipea.braga.br@gmail.com, malopes21@gmail.com Resumo. O presente artigo relata o uso de serviços em nuvem tendo como base o conceito de Serverless. Foi feita uma análise acerca do tema através de revisões bibliográficas com o intuito de conceituar e apresentar os benefícios e limitações da utilização dessa tecnologia. Além disso, foi demonstrado com um exemplo prático a arquitetura de uma aplicação Serverless na plataforma da AWS desde a sua configuração até a sua implementação. Realizado o prova de conceito, concluiu-se que ainda é necessário evolução das ferramentas e maturidade do desenvolvedor. 1. Introdução Há alguns anos, a maioria das empresas eram inteiramente responsáveis pelas operações de suas aplicações, configurações de rede, segurança e recuperação de desastres. Isso demandava tempo das equipes de infraestrutura e desenvolvimento e custos altos com mão de obra e data centers. Nesse cenário, a computação em nuvem dá seus primeiros passos com o lançamento do serviço de infraestrutura, o IaaS (Infrastructure as a Service). O modelo revolucionou a indústria de TI (Tecnologia da Informação) por ser possível provisionar recursos computacionais sob demanda e eliminando os gastos na compra de hardwares [Roberts et al. 2017]. Entretanto, apesar da revolução, os modelos de computação em nuvem ainda eram atrelados a servidores e atividades como gerenciamento que, na prática, geram poucos resultados. A fim de suprirem as carências deixadas pelos modelos anteriores, surgiram os modelos BaaS (Backend as a Service) e o FaaS (Function as a Service). Esses modelos passam a ser conceituados como Serverless. O conceito de Serverless é recente se comparado ao modelo tradicional de computação em nuvem. Os estudos já desenvolvidos acerca do tema dão ênfase na abordagem teórica e são pouco demonstrativos. Neste contexto, o objetivo deste trabalho é conceituar e demonstrar os aspectos e características da computação Serverless, apresentando seus benefícios e limitações, e explorando uma das ferramentas disponíveis no mercado, a AWS Lambda. Dessa maneira, o artigo foi composto em seções, das quais na seção 2 foi apresentado a origem da computação em nuvem, bem como o seus conceitos. Posteriormente, na seção 3, foi abordado o surgimento dos dois modelos de serviço citados anteriormente. Além disso, o termo Serverless foi definido apresentando suas características, benefícios e limitações. Neste ponto também foi apresentado as particularidades do FaaS na plataforma da AWS. Na seção 4 foi exposto uma prova de

2 conceito demonstrando através de um exemplo prático como se dá o funcionamento de uma arquitetura e aplicação Serverless. Por fim, na seção 5 foi apresentado a conclusão do artigo através das análises conceituais do tema e de seu modelo arquitetural. 2. Computação em Nuvem O termo cloud computing (computação em nuvem) surgiu em Novembro de 1996 por Sean O Sullivan e George Favaloro num artigo de marketing interno da Compaq Computer. Suas ideias antecipavam o que viria a ser a computação em nuvem, não somente todas as aplicações estariam na Internet, como também serviços para armazenamento de arquivos seriam comuns [Regalado 2011]. Entretanto, o conceito havia sido descrito pelo Prof. John McCarthy em 1961, descrevendo o termo utility computing referindo-se ao modelo de cobrança similar aos serviços de consumo, como telefonia, eletricidade e água. Nesse caso, a cobrança seria definida pelo uso e não por uma taxa fixa [Garfinkel 1999]. Esse modelo de cobrança se tornou parte de uma de cinco características básicas definidas pelo NIST (National Institute of Standards and Technology - Instituto Nacional de Padrões e Tecnologia). Apesar de ter sido descrito ainda no século XX, a utilização do termo cloud computing somente ganhou força em Agosto de 2006 quando o então CEO do Google, Eric Schmidt, introduziu o termo em uma conferência. Na ocasião, explicou que a computação em nuvem seria um novo modelo de negócio em ascensão, fornecendo infinitas possibilidades através da Internet e como grandes corporações de TI se beneficiariam dessa nova tendência [Schmidt 2006]. O que Schmidt talvez não soubesse era que a Amazon através de sua subsidiária Amazon Web Services (AWS) estava prestes a lançar em fase beta o primeiro serviço de infraestrutura sob demanda (IaaS - Infrastructure as a Service), o Amazon Elastic Compute Cloud (EC2) [Barr 2006], um serviço de fácil configuração e de baixo custo. O lançamento do serviço Amazon EC2 rompeu barreiras para a consolidação da computação em nuvem proporcionando de forma simples que empresas e usuários domésticos alugassem recursos de computação sem necessidade de grandes investimentos em data centers. Além disso, conta com a facilidade de, em apenas alguns cliques, ter vários servidores em execução e pagando apenas pelo o que é utilizado. Embora o termo tenha ganhado popularidade ainda existia muita confusão em relação ao conceito, que mesmo os gigantes da indústria de tecnologia tinham dúvidas acerca do termo. Segundo o CEO da Oracle Larry Ellison, o termo não fazia sentido, pois somente nomeava o que a indústria já fazia há anos [Armbrust 2009]. Um executivo da Hewlett-Packard (HP) também apontou que o termo estivesse sendo banalizado [Worthen 2008]. Contudo, a confusão não ficou somente com a indústria. O próprio governo americano teve problemas em compreender o termo e foi então que a seu pedido, o NIST em meados de 2011 apresentaria um rascunho com a definição de computação em nuvem [Regalado 2011]. Para o NIST a definição de computação em nuvem é permitir acesso de rede universal, conveniente e sob demanda de um conjunto compartilhado de recursos de computação configuráveis, por exemplo: redes, servidores, armazenamento, aplicativos

3 e serviços. Esses recursos devem ser rapidamente fornecidos e liberados com esforço mínimo de coordenação ou interação do provedor de serviço [Mell et al. 2011]. Para ampliar a compreensão o documento também descreve de forma simples cinco características básicas, quatro modelos de implantação e três modelos de serviços, que são resumidos a seguir. Características básicas: Serviço sob demanda: permitir que o cliente possa alocar os recursos computacionais automaticamente sem intervenção humana no provedor de serviços; Amplo acesso via rede: determina que os recursos estejam disponíveis na rede e que possam ser acessados por quaisquer dispositivos conectados a Internet; Agrupamento de recursos: são os recursos de computação do provedor de serviços agrupados para atender vários clientes no modelo de multilocação (multi-tenant), com diferentes recursos físicos e virtuais sendo atribuídos e reatribuídos dinamicamente de acordo com a demanda; Elasticidade rápida: é a possibilidade dos recursos serem provisionados e liberados de forma elástica, em alguns casos automaticamente. Isso dá a impressão que os recursos são ilimitados e disponíveis a qualquer momento; Serviço de medição: mecanismo utilizado pelo provedor do serviço para controlar e medir a utilização dos recursos, como processamento, armazenamento, largura de banda e usuários ativos. Com isso, é possível fornecer ao cliente transparência para a cobrança dos serviços. Modelos de implantação: Nuvem privada: descreve a infraestrutura provisionada para uso exclusivo de uma organização, onde o gerenciamento e operação ficam a cargo da organização ou de outros provedores. Na nuvem privada a organização tem controle total sobre os recursos; Nuvem pública: é a infraestrutura provisionada fornecida pelos provedores de serviços para uso do público em geral (empresas e usuários domésticos), e o controle dos recursos ficam a cargo dos provedores; Nuvem comunitária: descreve a infraestrutura provisionada para uso exclusivo entre organizações que compartilham os mesmos interesses e preocupações, como pesquisas, segurança, política, entre outros; Nuvem híbrida: é a combinação da infraestrutura de dois ou mais modelos de nuvem, com o intuito de fornecer maior capacidade ou ampliar o nível de acesso aos recursos. Modelos de serviços: Infraestrutura como Serviço (IaaS): refere-se ao fornecimento de recursos de infraestrutura sob demanda. Nesse modelo o cliente não tem controle sobre o hardware, mas pode controlar armazenamento, sistema operacional, processamento e alguns recursos de rede; Plataforma como Serviço (Platform as a Service - PaaS): refere-se a capacidade de oferecer implantação de aplicações customizados ou adquiridas pelo cliente. Nesse modelo o cliente não gerencia ou controla a infraestrutura,

4 porém tem controle das aplicações e do ambiente de configurações para os aplicativos; Software como Serviço (Software as a Service - SaaS): refere-se a capacidade de oferecer aplicações pela Internet sob demanda, não permitindo ao cliente nenhum gerenciamento sobre a infraestrutura ou controle da aplicação. No entanto, pode oferecer configurações específicas na aplicação de forma limitada. A computação em nuvem é um paradigma em evolução e o objetivo do documento do NIST é a definição de aspectos importantes da nuvem e criar pontos de referência para comparações dos serviços e estratégias e fomentar discussões do que é computação em nuvem. Além disso, deixa claro que o foco principal é buscar métodos mais econômicos, com maior qualidade e rapidez a um custo reduzido para os usuários da computação em nuvem e promover a padronização dos serviços fornecidos pelos provedores [Mell et al. 2011]. Ainda que a computação em nuvem tenha introduzido o provisionamento sob demanda de recursos, permitindo a redução de custos, agilizando e facilitando tarefas de implantação e desenvolvimento [Pérez et al. 2018], algo ainda permanecia quase intacto ao modelo de computação tradicional. As aplicações eram pensadas em termos de servidores, provisionamento, configurações, implantação, monitoramento e gerenciamento. O problema na maioria das vezes, é que essas atividades não importam, mas sim se a aplicação está executando corretamente e que as informações nela inserida estão seguras e corretas. Esse provavelmente seja o principal incentivo para o surgimento dos novos modelos de serviços. 3. Além dos Servidores A partir de 2011 o mercado de computação em nuvem sofre uma disruptura com a popularização dos dispositivos móveis, criando assim uma alta demanda por aplicativos móveis. O crescimento é tão expressivo que 68% da população mundial em Janeiro de 2018 possui um smartphone [Kemp 2018]. Segundo um estudo do Google Consumer Barometer, esse percentual era de apenas 14% em 2012, o que indica um crescimento de 485% em 6 anos [Patah 2018]. Com números tão expressivos de usuários e uma demanda quase ilimitada por aplicativos móveis, a indústria de tecnologia se viu motivada a desenvolver novos modelos de serviços buscando absorver um mercado global estimado em US$ 25 bilhões em 2015 [Costa et al. 2015]. Em 2012 a empresa Firebase lançou uma plataforma de serviço para atender essa demanda no desenvolvimento de aplicativos. Essa vem a ser chamada de Backend como Serviço (BaaS) ou por vezes Mobile Backend as a Service (MBaaS). Esse é o modelo de serviço para o desenvolvimento de aplicativos móveis ou aplicações web de menor complexidade com o intuito de servir de middleware para serviços e aplicações de terceiros, tais como banco de dados, autenticação e push notifications, a fim de acelerar e simplificar o desenvolvimento de aplicativos. Nesse modelo, o desenvolvedor perde todo o controle da infraestrutura [Paiva et al. 2015]; O BaaS se torna bastante popular entre startups, pois permite que novos produtos ou conceitos sejam implementados em tempo hábil, permitindo que os desenvolvedores foquem os esforços em pontos chaves para o sucesso destes. Esse modelo elimina preocupações com escalabilidade e segurança, por exemplo. Porém, o

5 desenvolvedor perde controle quanto aos detalhes dos serviços oferecidos por um provedor de BaaS. Entretanto, o BaaS é voltado para um nicho de mercado bastante específico. Para grandes empresas, onde componentes da aplicação podem ser altamente complexos ou precisam de vasta customização, esse modelo de serviço é inviável. Por esse motivo, várias empresas buscaram um caminho diferente. Elas migraram ou consideram migrar suas aplicações para um modelo arquitetural mais adequado a utilização em nuvem como a arquitetura de microsserviços (microservices). Essa é definida como uma abordagem para desenvolvimento de uma única aplicação com uma coleção de pequenos serviços, onde cada um executa um processo próprio e comunica-se por mecanismos leves, como uma API HTTP. Em contraste à arquitetura monolítica, os microsserviços podem ser desenvolvidos por equipes independentes e ser implementado em diferentes tecnologias [Garriga 2018]. Mesmo aumentando a granularidade da aplicação com microsserviços, ainda se faz necessário o provisionamento, configuração, gerenciamento e monitoramento dos servidores onde esses serviços serão executadas. Recentemente, em 2014 a AWS lançou a plataforma AWS Lambda [Handy 2018], uma plataforma para execução de código baseada no conceito de Serverless, introduzindo um novo modelo de serviço denominado Função como Serviço (FaaS), que consiste na execução de lógica de negócio ou código em resposta a eventos externos (event-driven), por exemplo a requisição a uma API de pagamentos. O modelo FaaS traz o benefício de uma granularidade ainda maior em relação a uma aplicação em microsserviços, que por vezes é até chamada de nanoserviços (nanoservices) [Sutrisno et al. 2018], um exemplo dessa abordagem pode ser visto na Figura 1. Figura 1. Evolução de aplicação monolítica para microsserviços depois FaaS [Techlabs 2018] Os dois modelos citados BaaS e FaaS são atualmente a evolução da computação em nuvem e a eles pode ser aplicado o conceito de Serverless.

6 3.1. Serverless Serverless computing ou simplesmente Serverless é um novo paradigma para o desenvolvimento de aplicações em nuvem, que descreve um modelo e arquitetura onde pequenos trechos de código são executados na nuvem sem o controle dos recursos onde esses códigos são executados. O termo Serverless entretanto, é confuso, pois denota a ideia sem servidor, o que não é verdade. Uma aplicação Serverless ainda precisa ser executada em um servidor, o que ele fornece é uma nova abordagem mais conceitual e abstrata que coloca uma distância entre o software e a máquina que o executa [Savage 2018]. Isto é, ainda existe a necessidade de servidores, porém a responsabilidade pelo servidor é transferida para um terceiro, como a AWS. Além deste, existe ao menos 3 grandes empresas, que são: Microsoft Azure (Azure Functions), Google Cloud Platform (Cloud Functions) e IBM OpenWhisk (IBM Cloud Functions). Contudo, definir Serverless pode ser um pouco mais complicado, e para buscar melhor entendimento é necessário responder a uma pergunta: Onde Serverless se encaixa na definição dos modelos de serviços do NIST? Uma forma de responder a esta pergunta, é considerando os diferentes níveis de gerenciamento da nuvem entre o usuário e o provedor de serviço, conforme Figura 2. Figura 2. Nível de gerenciamento entre os modelos de serviços em nuvem. Adaptado de [van Eyk et al. 2017] Na Figura 2 é possível ver que na extrema esquerda temos IaaS onde o usuário possui total gerenciamento dos recursos, em seguida temos o PaaS onde passa a existir uma responsabilidade compartilhada entre o usuário e o provedor e na extrema direita temos SaaS onde o gerenciamento é responsabilidade do provedor. Vendo dessa perspectiva, Serverless se encaixa na lacuna entre o PaaS e SaaS sobrepondo-se parcialmente a eles. Embora PaaS e SaaS não sejam Serverless existem exemplos de serviços que possuem características similares [van Eyk et al. 2017]. A lacuna entre PaaS e SaaS é ampla, o que ajuda a explicar o surgimento dos modelos FaaS e BaaS. Como mencionado, o BaaS é útil para aplicações com funcionalidades restritas e possui limitações quanto a customizações. Porém, FaaS é considerado sinônimo de serverless computing e, como tal, é um componente central para a criação de arquiteturas Serverless. Dito isso, o trabalho será direcionado ao modelo FaaS.

7 Como dito anteriormente, não se faz necessário o gerenciamento de servidores ou de processos no servidor. Todavia, deve ser citado outros pontos que ajudem a definir serverless computing: Não requer o gerenciamento de uma instância de aplicativo ou host de longa duração: possivelmente o pilar de Serverless, pois a forma mais comum de operar uma aplicação no servidor exige implantação, execução e monitoramento da instância da aplicação e o tempo de vida dessa aplicação abrange um longo período de tempo. Serverless presa o oposto disso, não há um servidor e processos de longa duração. Contudo, em FaaS ainda é necessário implantação e monitoramento, mas esse deve ser feito por requisições ou baseado em métricas; É auto-escalável e dinamicamente provisionado, dependendo da carga de trabalho: isso significa que o aplicativo tem a capacidade de ajustar dinamicamente os recursos necessários para atender a demanda crescente de requisições sem a mínima necessidade de intervenção; Os custos são precisos baseados no uso: isso quer dizer que a cobrança é feita em menor granularidade e cobra-se exatamente o que foi utilizado. Por exemplo a AWS Lambda cobra a cada 100 milissegundos na execução de uma função; Possui recursos de desempenho definidos em termos diferentes de tamanho ou contagem de servidores: quando se fala de FaaS esse é o único ponto pensado em provisionamento, mas é razoável e útil poder definir a quantidade de memória RAM que a função possa precisar; Tem alta disponibilidade (high availability - HA): refere-se a capacidade que um serviço tem de continuar processando requisições mesmo quando alguma parte falha. Serverless fornece isso de forma transparente [Roberts et al. 2018]. Segundo Roberts estes são os cinco pontos essenciais que uma tecnologia deve possuir para ser considerada Serverless e tanto BaaS quanto FaaS possuem essas características Benefícios e Limitações de Serverless Computing A utilização de Serverless trás consigo vários benefícios e limitações se comparado ao modelo tradicional de nuvem. Ela permite que os desenvolvedores concentrem seus esforços no design e na lógica de negócio da aplicação, itens esses que realmente agregam valor a aplicação. Além destes, existem outros prós para a utilização de Serverless: Redução de custos operacionais: remete a redução dos trabalhos operacionais. Além disso, devido a utilização de softwares ou serviços de terceiros, como em BaaS, reduz a quantidade necessária de código a ser implementado em um novo serviço; Redução de risco: normalmente quando se mantém uma aplicação é importante considerar as falhas e tempo de indisponibilidade. Quanto maior a quantidade de sistemas, serviços ou outros recursos para se gerenciar, maior é o risco de falhas. Em Serverless esses riscos são reduzidos devido a menor quantidade de tecnologias para operar diretamente, deixando a responsabilidade destes para o provedor de serviços; Redução de custos com recursos: ao desenvolver uma nova aplicação é comum planejar e provisionar os recursos computacionais e ao fazer isso raramente se

8 sabe exatamente quanto de recurso será necessário. Frequentemente se vê um super provisionamento dos recursos, provocando maiores gastos. Como benefício, serverless elimina a necessidade de planejar, alocar e provisionar esses recursos. Todo recurso necessário é feito sob demanda.. É interessante salientar que dessa forma quando são implementados melhorias de otimização na aplicação serverless a redução de custo é percebida imediatamente; Maior flexibilidade de dimensionamento: o contexto de FaaS refere-se a capacidade da plataforma de receber e processar requisições de forma flexível, ou seja, automaticamente a plataforma vai fornecer novas instâncias das funções até ter o suficiente para atender toda a demanda. No caso da AWS Lambda a cobrança não está relacionada à quantidade de instâncias criadas, mas sim ao tempo que cada requisição demorou para ser executada e ao quanto de memória RAM foi consumido; Menor tempo de desenvolvimento: além da redução de custos, serverless proporciona significamente a redução da complexidade de construção, implantação e gerenciamento das aplicações, ou seja, menos códigos, menos camadas de backend e consequentemente aceleramento do processo de inovação de novos produtos e ideias. Como se sabe, todas as tecnologias, técnicas e ferramentas possuem suas limitações, com serverless não poderia ser diferente e por ser uma tecnologia recente algumas dessas podem vir a desaparecer ou serem contornadas conforme a tecnologia avança e sua popularidade aumenta. As limitações podem ser separadas em dois contextos distintos, limitações intrínsecas e de implementação. Limitações intrínsecas: Estado: os componentes Serverless, são naturalmente sem estado (stateless), o que é desejável para a escalabilidade. Contudo, existe interação entre componentes com estado (stateful) principalmente para o armazenamento de informações; Latência: em aplicações tradicionais a comunicação entre os diferentes componentes pode ser feita de forma otimizada com protocolos de rede especializados ou rodando no mesmo servidor. Em Serverless a comunicação é feita em grande parte via APIs HTTP que podem ser mais lentas que outros protocolos de comunicação. Se a latência for um ponto chave para a aplicação, Serverless não será uma solução viável; Teste local: possivelmente é a maior limitação de Serverless, pois usualmente os desenvolvedores possuem ambientes de desenvolvimento similares ao ambiente de produção que podem ser integrados de forma quase idêntica. Em Serverless, deve se confiar em testes de unidade, mas para os testes de integração é necessário fazê-los remotamente na plataforma. Perda de controle: apesar de FaaS possuir maior controle que BaaS, muitas dessas limitações são devido a própria plataforma ser operada e mantida por terceiros. No modelo tradicional de nuvem o controle está nas mãos do desenvolvedor além disso, ele tem a responsabilidade de operar e manter, o que por sua vez divide o foco com a lógica de negócio. Porém, a utilização de serverless envolve abrir mão desse controle para concentrar no que é importante.

9 Em contraste com as limitações intrínsecas, as de implementação são aquelas que por hora fazem parte de serverless, mas que num futuro podem desaparecer ou ter melhoras significativas, são elas: Cold Starts ou inicialização fria: um dos problemas mais comuns de desempenho é a inicialização fria, que é caracterizada pelo tempo que uma função leva para estar disponível (warm) logo após a primeira requisição. Se uma função é utilizada com bastante frequência ela estará operacional a maior parte do tempo, mas assim que a função ficar inativa por algum tempo, ela volta para o estado frio. Ferramentas: como serverless é uma novidade, faltam ferramentas para desenvolvimento, implantação e gerenciamento de aplicações. As que existem sofrem por imaturidade ou por falta de funcionalidades. Aprisionamento tecnológico (vendor lock-in): caracterizado pela dependência que o desenvolvedor possui ao utilizar um provedor de FaaS. Devido às diferenças entre provedores, torna-se quase impossível portar uma aplicação serverless entre esses. Apesar dos principais fornecedores oferecerem produtos parecidos, individualmente eles possuem particularidades próprias. Conforme os provedores evoluem suas plataformas essas limitações tendem a desaparecer em favor de soluções bem projetadas e bem definidas Particularidades do FaaS na plataforma AWS Lambda A fim de implementar uma função Lambda adequadamente é importante entender que os códigos das funções são executadas em resposta a eventos, e na AWS esses eventos podem vir de diferentes fontes, como requisições HTTP via API Gateway, eventos internos da AWS (S3, Cognito, CloudFront), Chamadas de API via AWS SDK e chamadas manuais via o console de gerenciamento da AWS. A importância de compreender quais eventos chamam a função se dá pela diferença de dados que cada evento possui, isto é, o evento de uma função Lambda que atenda uma requisição HTTP será diferente de um evento originado pelo Cognito após uma confirmação de cadastro. Em suma, uma função não deveria ser compartilhada com outra fonte de evento devido a incompatibilidade de dados deste. As funções Lambda podem ser chamadas de dois modos distintos, sincronamente e assincronamente, isto é, em eventos assíncronos a função Lambda será invocada, porém nenhuma resposta será enviada de volta ao evento de origem. Nos eventos síncronos a Lambda é invocada e o evento de origem aguarda uma resposta da função. Os modos são chamados de Event e RequestResponse, respectivamente. Portanto, em função de garantir um padrão adequado de programação a AWS Lambda fornece um modelo de programação básico [AWS 2018]: Função handler: é a função que a Lambda chama ao ser executada, também é nela que os parâmetros event, context e callback serão passados; Objeto de evento (event): é o objeto que contém todas as informações relativas ao evento de origem responsável por chamar a Lambda; Objeto de contexto (context): é o objeto que permite ao código interagir com a AWS Lambda e fornece importantes informações sobre a execução;

10 Função de retorno (callback): a função de callback é um item opcional para algumas linguagens de programação na AWS Lambda, mas ela é responsável por retornar informações ao evento de origem, isso é útil quando uma função é invocada por um evento do tipo RequestResponse. 4. Prova de Conceito Com o objetivo de demonstrar a arquitetura serverless, será proposto uma aplicação no modelo Single-page Application (SPA) de controle de ponto simplificado dentro do seguinte contexto: comumente desenvolvedores de software trabalham por hora e precisam anotá-las. Com o objetivo de facilitar esse processo, a aplicação tem o intuito de fornecer de forma simples que eles registrem o dia trabalhado, informando as horas de entrada e saída para que ao final do dia seja calculada às horas totais, bem como o valor a ser recebido. Além disso, será possível fazer um fechamento por período, agrupando vários dias. Para acessar o aplicativo o desenvolvedor fará o próprio cadastro e informará um código de verificação recebido no cadastrado. O modelo de dados da aplicação pode ser conferido na Figura 3 e devido a utilização de um banco de dados NoSQL não terá nenhuma linha ligando as relações entre as tabelas, para isso o modelo deixa explícito as relações com a nomenclatura dos campos. Figura 3. Modelo de dados para a aplicação de controle de ponto simplificado. Para o desenvolvimento da aplicação serão utilizados alguns serviços da AWS que são parte do conceito de Serverless. Os quatro primeiros voltados para o backend e os dois últimos para atender o frontend, são eles: Amazon Cognito para controle de usuários, autenticação e autorização; Amazon API Gateway para desenvolvimento e gerenciamento de APIs HTTP que funciona como porta de entrada aos serviços internos da AWS, como o EC2 e AWS Lambda;

11 AWS Lambda (FaaS) para execução de código e lógica de negócio em resposta a eventos externos, sejam por eventos de outros serviços na AWS ou por requisição direta via API Gateway; Amazon DynamoDB um banco de dados NoSQL de alta performance; Amazon CloudFront serviço de rede de distribuição de conteúdo (Content Distribution Network - CDN) em escala global, possui baixa latência e alta velocidade de transferência; Amazon Simple Storage Service (S3) para armazenamento de arquivos. A AWS foi escolhida levando em consideração a maturidade de suas ferramentas e a possibilidade de utilizar recursos de serverless gratuitamente. Além disso a AWS é líder no mercado de computação em nuvem. No contexto de serverless, o S3 vai além da armazenagem de arquivos. Nele também é oferecido o serviço de hospedagem de sites estáticos (web hosting) e em associação com CloudFront o conteúdo de um bucket S3 é distribuído globalmente. Com isso, o site tem capacidade de suportar um número quase ilimitado de acessos simultâneos, a combinação do S3 com CloudFront para servir conteúdo estático proporciona a redução de custos, riscos de falhas são reduzidos e não se faz necessário nenhum tipo de provisionamento. Porém conta com algumas limitações como a perda de controle e a impossibilidade de testes locais. Na Figura 4 é possível visualizar como esses serviços se interagem. Figura 4. Diagrama de arquitetura da proposta na AWS. O diagrama de arquitetura demonstra o funcionamento de uma aplicação serverless na AWS. O navegador faz uma requisição para o site que corresponde ao endereço do CDN, este por sua vez obtém os dados de um bucket, em resposta o navegador recebe os conteúdos estáticos de uma SPA. Após o carregamento da página o usuário poderá se cadastrar ou efetuar o login para ter acesso completo a aplicação. As requisições de cadastro e login são feitas diretamente no Cognito e as demais requisições serão encaminhadas ao API Gateway que fará o

12 controle de autorização e encaminhará a solicitação para a função Lambda correspondente. Para unir todo esse ecossistema e agilizar o desenvolvimento será utilizado a ferramenta Serverless Framework. Ela fornece mecanismos para a configuração de todos os serviços utilizados nesse artigo e facilita a implantação das funções Lambda. Com o framework é possível configurar todo o ambiente da AWS com um único arquivo YAML. O framework oferece de forma agnóstica mecanismos para configuração em diferentes provedores de serviços. Além dos variados provedores, fornece também suporte para múltiplas linguagens de programação [Serverless 2018]. Para o desenvolvimento das funções no AWS Lambda será utilizado Node.js, um interpretador de JavaScript no lado do servidor. Já para o frontend será empregado a biblioteca ReactJS frequentemente utilizada na criação de SPAs Configuração Para o desenvolvimento na AWS é preciso possuir uma conta e para cada novo usuário é fornecido uma credencial (Access Key ID e Secret Key) que é utilizada para acessar os serviços da AWS via CLI (Command-Line Interface). Essa credencial será utilizada para configurar o Serverless Framework e permitir que ele execute todos os processos relacionados a configuração dentro da AWS. O framework fornece o arquivo serverless.yml para que sejam feitas as configurações necessárias, como: o nome da aplicação Serverless, o provedor de serviço, a região e a plataforma de execução das funções, variáveis de ambiente e variáveis de uso no arquivo e provisionamento de memória, conforme visto na Figura 5. Figura 5. Configuração da aplicação no Serverless Framework. Na Figura 6 é possível ver o item functions que é o agrupador para todas as funções. No nível seguinte é informado o nome da função Lambda criarusuario, no item interno da função o handler define o nome do arquivo de código fonte (criarusuario.js) e o nome do método para a execução (handler). Em seguida o item events define uma listagem de eventos responsáveis por disparar a função, no exemplo é utilizado o evento http do API Gateway para a definição de um endpoint utilizando o path (usuarios), o method (post), habilitando o recurso de cors (Cross-origin resource sharing) e o authorizer que define o mecanismo de autorização a ser utilizado, que no caso da AWS é o Cognito. No API Gateway será criado o endpoint acessível via HTTP POST e no último item no nível da função está definido o environment que declara uma variável de ambiente exposta no Lambda com o nome da tabela no DynamoDB.

13 Figura 6. Declaração de criação para uma função Lambda. A AWS fornece o Amazon CloudFormation uma linguagem para descrever e provisionar os recursos de infraestrutura em nuvem. Além disso, o CloudFormation permite configurar todos os serviços fornecidos pela AWS e é este mecanismo que o Serverless Framework utiliza. Como mencionado, o framework permite utilizar o mecanismo do CloudFormation para automatizar o processo de criação e configuração da arquitetura Serverless dentro da AWS. Para aproveitar o máximo deste recurso, será adicionado ao arquivo serverless.yml o item resources, para o qual é adicionado as configurações do CloudFormation para os serviços: DynamoDB, Cognito, S3 e CloudFront. Como demonstrado na Figura 7. Figura 7. Declaração de recursos para criação via CloudFormation. Para implantar a aplicação é executado o comando $ serverless deploy -v. A verificação é feita conferindo o console de gerenciamento do CloudFormation Implementação Como proposto no início da seção 4, uma aplicação para controle de ponto será implementada e neste tópico será demonstrado trechos dos códigos desenvolvidos. As

14 informações mencionadas na seção 3.3 foram utilizadas como base para o desenvolvimento desses código. Ao acessar a aplicação o usuário visualiza a página principal, Figura 8. Figura 8. Página principal da aplicação. Ao clicar no botão Cadastrar o usuário visualiza a tela de cadastro intitulada na Figura 9 por A. Figura 9. A - Tela de cadastro de usuário, B - Tela de confirmação de cadastro Como parte inicial do fluxo da aplicação o usuário efetua o cadastro e receberá um código de verificação enviado no . Esse código será utilizado na tela de confirmação intitulada por B na Figura 9. Após esse processo será efetuado uma requisição HTTP POST no endpoint do API Gateway que encaminhará para a Lambda criarusuario e assim persistir as informações no DynamoDB. O trecho dessa função pode ser visto na Figura 10.

15 Figura 10. Trechos de código do arquivo criarusuario.js Após o cadastramento o usuário terá acesso completo a aplicação. No item de menu Registro o usuário terá acesso a tela de cadastro em que informará os dados referentes ao dia trabalho, informando as horas de entrada e saída, bem como a descrição e comentários das atividades. Essa tela pode ser visualizada na Figura 11. Figura 11. Tela para registrar um dia de trabalho O usuário ao clicar no botão Criar será feita uma requisicao HTTP POST no endpoint que encaminhará para Lambda criarregistro, a função executa a regra para verificar se existe uma outro registro para a mesma data de referência. Caso exista, uma mensagem de validação será mostrada ao usuário. Se não existir, os dados serão armazenados. O trecho dessa função pode ser visto na Figura 12. Como mostra na Figura 13 os registros diários cadastros são organizados de forma que o registro mais recente estará localizado no primeiro item. Além de visualizar a descrição das atividades, o usuário terá accesso raṕido ao tempo trabalhado e ao valor a ser recebido.

16 Figura 12. Trechos de código do arquivo criarregistro.js Figura 13. Tela de listagem dos registros diários. A tela da Figura 13, foi desenvolvida com o trecho de código visualizado na Figura 14. Ao acessar a tela os dados serão obtidos através de uma requisição HTTP GET no endpoint que encaminhará para a Lambda listarregistros que fará a consulta dos registros do usuário no DynamoDB. Caso não seja encontrado nenhum registro, uma mensagem será mostrado ao usuário. Na tela de listagem dos registros diários, o usuário poderá fazer a exclusão de um item, clicando no ícone lixeira. Caso o usuário confirme a exclusão, será chamado uma requisição HTTP DELETE no endpoint que encaminhará para a Lambda removerregistro que fará a remoção do item no DynamoDB. O trecho de código pode ser visualizado na Figura 15.

17 Figura 14. Trechos de código do arquivo listarregistros.js. Foi exposto alguns trechos de códigos para demonstração de como é efetuado a implementação de funções na AWS Lambda, as demais funções desenvolvidas seguem o mesmo modelo de programação mostrado, com a diferença sendo relacionada a regras de negócio e as diferentes ações no DynamoDB. 5. Conclusão Levando-se em consideração os aspectos mencionados ao longo do texto, a utilização de um modelo arquitetural serverless pode ser considerado viável se analisado os benefícios que esta traz como a redução de custos, trabalho operacional e agilidade no desenvolvimento. Entretanto, o serverless ainda não é adequado a todas as circunstâncias e é importante que seja avaliado cuidadosamente o contexto da aplicação a ser criada e quais limitações são aceitáveis. Feito isso, utilizando-o em um contexto adequado e aproveitando ao máximo seu potencial, os benefícios podem se revelar muito superiores às limitações. Os provedores têm como desafio atualizar suas ferramentas aprimorando os processos de configuração e implantação. Além do mais, os usuários da plataforma devem aprimorar seus conhecimentos na utilização desta, de maneira a reduzir os problemas da plataforma. Além disso, eles devem buscar aperfeiçoar seus processos de desenvolvimento, pois o uso das técnicas convencionais não são adequadas a um trabalho conceituado em serverless. Dessa maneira, ainda deve levar algum tempo para que esse modelo se torne disseminado. Trabalhos futuros podem ser desenvolvidos explorando os diferentes provedores de serverless, como Microsoft Azure e Google Cloud. Além desses, há a possibilidade de explorar a plataforma de código aberto Apache OpenWhisk e, ainda, comparar os modelos arquiteturais serverless com os modelos arquiteturais de microsserviços e monolíticos. Também é interessante fazer um trabalho técnico relacionado às nuances por trás do funcionamento de uma plataforma serverless.

18 Referência Armbrust, M. (2009) Above the Clouds: A Berkeley View of Cloud Computing, Electrical Engineering and Computer Sciences University of California at Berkeley AWS, Amazon Web Service (2018) Programming Model Dezembro 2018 Barr, Jeff (2006) Amazon EC2 Beta, Outubro 2018 Costa, I., Araujo, J., Dantas, J., Campos, E., Silva, F. A., and Maciel, P. (2015). Availability Evaluation and Sensitivity Analysis of a Mobile Backend-as-a-service Platform. Quality and Reliability Engineering International, 32(7), Garfinkel, Simson (1999) Architects of the Information Society: Thirty-Five Years of the Laboratory for Computer Science at MIT, Edited by Harold Abelson, p. 1. The MIT Press Garfinkel, Simson (2011) Cloud Computing Defined, Outubro 2018 Garriga, M. (2018) Towards a Taxonomy of Microservices Architectures Lecture Notes in Computer Science, Handy, A. (2014) Amazon introduces Lambda, Containers at AWS re:invent. Novembro 2018 Kemp, S. (2018) Digital in 2018: World s internet users pass the 4 billion mark Novembro 2018 Mell, P. and Timothy, G. (2011) The NIST Definition of Cloud Computing, Outubro 2018 Paiva, J. C., Leal, J. P. and Queirós, R. (2015) Odin: A Service for Gamification of Learning Activities, Communications in Computer and Information Science, vol. 563, pp Patah, R. (2018) O boom dos smartphones e seu impacto no comportamento do consumidor, Novembro 2018 Pérez, A., Moltó, G. and Caballer, M. (2018) Serverless computing for containerbased architectures, Future Generation Computer Systems, vol. 83, pp Regalado, Antonio (2011) Who Coined 'Cloud Computing'?, Outubro 2018 Roberts, M., and Chapin, J. (2017) What is Serverless? - Understanding the Latest Advances in Cloud and Service-Based Architecture, O Reilly: Sebastopol, CA, USA, 2017 Savage, N. (2018) Going serverless, Communications of the ACM, 61(2), 15-16

19 Schmidt, Eric (2006), Outubro 2018 Serverless (2018), Novembro 2018 Sutrisno, Panduwinata, F., & Yugopuspito, P. (2017), Nanoservices as Generalization Services in Service-Oriented Architecture, 2017 International Conference on Soft Computing, Intelligent System and Information Technology (ICSIIT) Techlabs, M. (2018) Serverless Architecture The Future Of Business Computing, Novembro 2018 van Eyk, E., Iosup, A., Seif, S., and Thömmes, M. (2017) The SPEC cloud group s research vision on FaaS and serverless architectures Worthen B. and Fowler, G. A. (2008) The Internet Industry Is on a Cloud -- Whatever That May Mean, Outubro 2018