ALEXANDRE DAVI ZANELATTO NERI BURATO BEZ FONTANA FILHO
ARQUITETURA SERVERLESS BASEADA EM EVENTOS PARA APLICAÇÕES WEB UTILIZANDO A AWS
Florianópolis 2019
NERI BURATO BEZ FONTANA FILHO
ARQUITETURA SERVERLESS BASEADA EM EVENTOS PARA APLICAÇÕES WEB UTILIZANDO A AWS
Trabalho de Conclusão de Curso apresentado ao curso de Seu Curso, da Universidade do Sul de Santa Catarina, como requisito parcial para a Obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Flávio Ceci, Dr.
Florianópolis 2019
NERI BURATO BEZ FONTANA FILHO
ARQUITETURA SERVERLESS BASEADA EM EVENTOS PARA APLICAÇÕES WEB UTILIZANDO A AWS
Trabalho de Conclusão de Curso apresentado ao curso de Seu Curso, da Universidade do Sul de Santa Catarina, como requisito parcial para a Obtenção do título de Bacharel em Sistemas de Informação.
Florianópolis, 18 de novembro de 2019.
BANCA EXAMINADORA
Prof. Flávio Ceci, Dr.
Universidade do Sul de Santa Catarina
Prof. Ricardo Ribeiro Assink, Esp. Universidade do Sul de Santa Catarina
Prof. Rafael Lessa, Esp. Universidade do Sul de Santa Catarina
A evolução tecnológica está cada vez mais impactante no desenvolvimento web e todo dia vemos nascer novas startups com modelos de negócios inovadores e crescimento acelerado. Para suprir esse crescimento e se manter na competição as empresas passaram a construir novas aplicações, e/ou migrar sua arquitetura monolítica para uma arquitetura de microsserviços. A arquitetura de microsserviços a médio ou longo prazo, acaba se tornando um padrão de grande custo e alta complexidade de gerenciamento, de forma que em alguns casos acabam se tornando grandes serviços perdendo os benefícios da arquitetura. A arquitetura Serverless veio para acabar com a complexidade do gerenciamento de servidores, com ela o desenvolvedor não precisa se preocupar com a maioria dos aspectos da infraestrutura em que sua aplicação será executada. Ao mesmo tempo que essa arquitetura oferece maior escalabilidade, flexibilidade, diminuição no tempo de liberação de versões e custo reduzido, ela ajuda os desenvolvedores a entregar muito mais software em um mesmo período de tempo. Com isso, esta monografia tem o objetivo de apresentar uma proposta de uma arquitetura serverless baseada em eventos para o desenvolvimento de uma aplicação web fazendo o uso de FaaS (Function as a Service) e da AWS (Amazon Web Services). As etapas metodológicas desta monografia se caracterizam a modelar a arquitetura proposta, aplicar a arquitetura proposta em um sistema web e avaliar a escolha com a criação e a aplicação de um formulário. Para o desenvolvimento foi criado uma aplicação de lista de afazeres que se comunica com as funções desenvolvidas demonstrando a arquitetura proposta. Com base neste desenvolvimento e nos critérios abordados, foi possível criar uma aplicação web utilizando uma arquitetura serverless e apresentar os pontos positivos e negativos da mesma. A partir desta conclusão, é levantado, para trabalhos futuros, a necessidade de aplicar uma camada de segurança nas chamadas HTTPS, executar testes de carga, implementar testes de integração e definir uma pipeline de entrega e deploy contínuo para as funções, obtendo uma facilidade ainda maior de implantação.
Technological developments are increasingly impacting on web development and every day we see new startups with innovative business models and rapid growth. To meet this growth and stay competitive, companies have started to build new applications, and / or migrate their monolithic architecture to a microservice architecture. The medium- or long-term microservice architecture ends up becoming a costly and highly complex management standard, so that in some cases they become big services, losing the benefits of the architecture. Serverless architecture has come to put an end to the complexity of server management, so the developer doesn't have to worry about most aspects of the infrastructure on which your application will run. While this architecture offers increased scalability, flexibility, reduced release time, and reduced cost, it helps developers devote their primary functions, delivering much more software over a period of time. Thus, this monograph aims to present a proposal of an eventless server-based architecture for the development of a web application using FaaS (Function as a Service) and AWS (Amazon Web Services). The methodological steps of this monograph are characterized by modeling the proposed architecture, applying the proposed architecture in a web system and evaluating the choice with the creation and application of a form. For the development was created a to-do list application that communicates with the developed functions demonstrating the proposed architecture. Based on this development and the criteria addressed, it was possible to create a web application using a serverless architecture and present its positive and negative points. From this conclusion, it is raised for future work the need to apply a layer of security on HTTPS calls, perform load tests, implement integration tests and define a continuous delivery pipeline and deploy to the functions. largest deployment.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quadro 1 — Descrição do padrão MVC 15
Figura 1 — Descrição do padrão MVC 15
Figura 2 — Arquitetura MVC em tempo de execução 16
Quadro 2 — Descrição da arquitetura cliente-servidor 16
Figura 3 — Uma arquitetura cliente-servidor para uma biblioteca de filmes 17
Quadro 3 — Descrição da arquitetura em camadas 18
Quadro 4 — Descrição da arquitetura de repositório 19
Figura 4 — Uma arquitetura de repositório para uma IDE 20
Figura 5 — Uma arquitetura de microsserviços 21
Figura 6 — Um exemplo de escala versus custo 24
Figura 7 — Um exemplo de tráfego inconsistente 26
Figura 8 — Fluxograma das atividades a serem executadas no projeto 33 Figura 9 — Exemplo da arquitetura serverless proposta 34
Figura 10 — Visão histórica do UML 36
Figura 11 — Tipos de diagramas UML 37
Figura 12 — Exemplo Diagrama de Componentes 39
Figura 13 — Exemplo Diagrama de Casos de Uso 40
Figura 14 — Proposta de arquitetura detalhada 41
Figura 15 — Diagrama de componentes do sistema proposto 42 Figura 16 — Diagrama de casos de uso do sistema proposto 43
Figura 17 — Logo Git 44
Figura 18 — Logo IntelliJ IDEA 45
Figura 19 — Logo Visual Code 45
Figura 20 — Logo Node.js 46
Figura 21 — Logo React.js 47
Figura 22 — Logo AWS Lambda 47
Figura 23 — Logo AWS Api Gateway 48
Figura 24 — Logo AWS DynamoDB 49
Figura 25 — Logo Visual Paradigm for UML 49
Figura 26 — Lista de tarefas vazia 51
Figura 27 — Lista de tarefa com itens 52
Figura 28 — Arquivo de dependências - package.json 53
Figura 29 — Arquivo de configuração serverless (sessão de providers)
-serverless.yml 54
Figura 30 — Arquivo de configuração serverless (sessão das funções)
-serverless.yml 55
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . serverless.yml 56
Figura 32 — Arquivo responsável por centralizar a chamada dos códigos de
cada função da aplicação - handler.js 57
Figura 33 — Função responsável por criar e salvar uma tarefa 58 Figura 34 — Função responsável por atualizar uma tarefa 59
Figura 35 — Função responsável por deletar uma tarefa 60
Figura 36 — Função responsável por ler uma tarefa 61
Figura 37 — Função responsável por ler todas as tarefas 62
Figura 38 — Pergunta 01 do questionário 64
Figura 39 — Pergunta 02 do questionário 64
Figura 40 — Pergunta 03 do questionário 65
Figura 41 — Pergunta 04 do questionário 66
Figura 42 — Pergunta 05 do questionário 66
Figura 43 — Pergunta 06 do questionário 67
1 . . . 1.1 . . . 1.2 . . . 1.2.1 . . . 1.2.2 . . . 1.3 . . . 1.4 . . . 2 . . . 2.1 . . . 2.1.1 . . . 2.1.2 . . . 2.1.3 . . . 2.1.4 . . . 2.2 . . . 2.3 . . . 2.3.1 . . . 2.3.1.1 . . . 2.3.1.2 . . . 2.3.1.3 . . . 2.3.2 . . . 2.3.2.1 . . . 2.3.2.2 . . . 2.3.2.2.1 . . . 2.3.2.2.2 . . . 2.3.2.2.3 . . . 2.3.2.3 . . . 2.3.2.3.1 . . . 2.3.2.3.2 . . . 2.3.2.3.3 . . . 2.4 . . . 2.4.1 . . . 2.4.2 . . . 2.4.3 . . . 3 . . . 3.1 . . . INTRODUÇÃO 9 PROBLEMÁTICA 10 OBJETIVOS 11 Objetivo Geral 11 Objetivos específicos 12 JUSTIFICATIVA 12 ESTRUTURA DA MONOGRAFIA 13 REVISÃO BIBLIOGRÁFICA 14 ARQUITETURA DE SOFTWARES 14 MVC 14 Arquitetura cliente-servidor 16 Arquitetura em camadas 18 Arquitetura de repositório 19 MICROSSERVIÇOS 20 SERVERLESS 22
Desmistificando Função como Serviço 22
Estado 22
Duração da execução 23
Latência de inicialização 23
Benefícios 23
Reduzir custos operacionais 23
Custos de escalonamento 24
Chamadas ocasionais 25
Tráfego inconsistente 25
Otimização é a raiz de algumas economias de custo 27
Gerenciamento operacional mais fácil 27
Benefícios de escalonamento do FaaS além dos custos de
infraestrutura 27
Complexidade reduzida de empacotamento e implantação 27
Tempo para comercializar e experimentação contínua 28
FRAMEWORKS PARA SERVERLESS 28
Knative 28
Kubeless 28
Serverless Framework 29
MÉTODO 30
TIPOS DE PESQUISAS ADOTADOS 30
3.1.2 . . . 3.1.3 . . . 3.2 . . . 3.3 . . . 3.4 . . . 4 . . . 4.1 . . . 4.1.1 . . . 4.1.1.1 . . . 4.1.1.2 . . . 4.1.1.2.1 . . . 4.1.1.2.2 . . . 4.1.2 . . . 4.2 . . . 4.2.1 . . . 4.2.2 . . . 5 . . . 5.1 . . . 5.1.1 . . . 5.1.2 . . . 5.1.3 . . . 5.1.4 . . . 5.1.5 . . . 5.1.6 . . . 5.1.7 . . . 5.1.8 . . . 5.1.9 . . . 5.2 . . . 5.3 . . . 5.3.1 . . . 5.3.1.1 . . . 6 . . . 6.1 . . . 6.2 . . . . . . Pesquisa aplicada 31 Pesquisa qualitativa 31 ETAPAS DA PESQUISA 32
ARQUITETURA DE PROPOSTA DE SOLUÇÃO 33
DELIMITAÇÕES 34
MODELAGEM DO SISTEMA PROPOSTO 35
METODOLOGIAS E TÉCNICAS 35
UML - Linguagem de Modelagem Unificada 35
Evolução da UML 35
Diagramas da UML 37
Diagrama de Componentes 38
Diagrama de Casos de Uso 39
Etapas da modelagem 40
PROJETO DE SOLUÇÃO 41
Diagrama de Componentes 42
Diagrama de Casos de Uso 43
DESENVOLVIMENTO E VALIDAÇÃO DA PROPOSTA 44
FERRAMENTAS E TECNOLOGIA UTILIZADAS 44
Git 44 IntelliJ 45 Visual Code 45 Node.js 46 React.js 46 AWS Lambda 47
AWS Api Gateway 48
AWS DynamoDB 48
Visual Paradigm for UML 49
PROCESSO DE DESENVOLVIMENTO (HISTÓRICO) 50
SOLUÇÃO PROPOSTA 51 Análise e questionário 62 Questionário 63 CONCLUSÃO 69 CONCLUSÕES 69 TRABALHOS FUTUROS 70 REFERÊNCIAS 71
1 INTRODUÇÃO
É perceptível que a evolução da tecnologia está cada vez mais impactante na construção de sistemas web, como mostra G. M. de Figueiredo (2013) ao comentar sobre inovações causadas pelo surgimento de novos negócios, novos frameworks1,
novas linguagens e novos protocolos que surgem em um intervalo cada vez menor de tempo.
Atualmente os padrões de arquitetura web são geralmente classificadas em dois grandes tópicos: arquiteturas monolíticas e arquiteturas orientadas a micro-serviços, conforme mostra Gertel (2019) em sua introdução.
“Monolito significa tudo composto de uma peça só. A aplicação monolítica descreve uma aplicação de software de uma única camada onde componentes diferentes são combinados em um único programa de uma única plataforma” (HAQ, 2018, tradução nossa).
Esse padrão de arquitetura web é simples de desenvolver, testar, efetuar o
deploy2. e simples para escalar horizontalmente executando múltiplas cópias através de um load balancer3., como mostra Siraj (2018) ao descrever os benefícios desse padrão.
A arquitetura de microsserviços, conforme Fowler, Lewis (2014) é uma abordagem para desenvolver aplicações únicas como uma suíte de pequenos serviços, cada um rodando seus próprios processos e se comunicando com mecanismos de leve peso, normalmente uma API4. (Application Programming
Interface) de recursos HTTP5. (Hypertext Transfer Protocol)”.
Os principais benefícios desse padrão de arquitetura também são citados por Fowler, Lewis (2014), onde eles mencionam que os pequenos serviços são desenvolvidos em torno da responsabilidade de um negócio e são passíveis de
deploys independentes por processos automatizados. Esses serviços possuem o
mínimo de gerenciamento centralizado, podem ser escritos em diferentes linguagens de programação e podem usar diferentes tecnologias de armazenamento de dados.
De acordo com Roberts (2018), serverless são aplicações onde a lógica do lado do servidor continua sendo escrita pelo desenvolvedor da aplicação, mas, diferente de arquiteturas tradicionais, executa em contêineres de computação sem servidor que são ativados por eventos, efêmero (pode durar apenas uma evocação)
1 Uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica.
2 Instalação de uma aplicação, ou seja, disponibilizar ela para seus usuários.
3 Um pedaço de hardware que atua como um proxy reverso para distribui rede e/ou tráfego entre diferentes servidores de aplicação.
4 Instruções e padrões de programação para acesso a um aplicativo ou software.
5 Um protocolo de comunicação utilizado para sistemas de informação de hipermídia, distribuídos e colaborativos.
e totalmente gerenciado por um terceiro”.
Arquiteturas serverless oferecem uma grande escalabilidade, são mais flexíveis e possuem um tempo mais rápido de entrega, tudo isso a um custo reduzido, como afirma Cloudflare (2018) ao mencionar as vantagens da arquitetura, que também proporciona aos desenvolvedores a vantagem de não precisarem se preocupar com a compra, provisionamento e o gerenciamento de servidores
backend6. Entretanto, computação serverless não é uma bala de prata para todos os desenvolvedores de aplicações web.
A AWS(Amazon Web Services) provê recursos e serviços sobre demanda na nuvem. Deutsch (2017) explica que você pode executar um servidor na AWS no qual você pode acessar remotamente, realizar configuração, tornar seguro e executar como se fosse um servidor físico do seu lado.
O presente trabalho propõe apresentar o desenvolvimento de um protótipo funcional de uma aplicação web utilizando uma arquitetura serverless baseada em eventos, apresentando as vantagens, os pontos de atenção e as dificuldades de se aplicar e manter esta arquitetura.
1.1 PROBLEMÁTICA
A medida que o tamanho e complexidade dos sistemas de software aumentam, o problema de projeto extrapola as estruturas de dados e algoritmos de computação. Ou seja, projetar a arquitetura (ou estrutura geral) do sistema emerge como um problema novo, como menciona Antonio (2008).
Para Sommervile (2011), é preciso escolher a estrutura mais adequada para o cumprimento dos requisitos do sistema. Para decompor unidades estruturais do sistema, você precisa decidir sobre a estratégia para a decomposição de componentes em subcomponentes. Sommerville (2011) também comenta sobre a estreita relação entre os requisitos não funcionais e a arquitetura do software:
Desempenho: Se o desempenho for um requisito crítico, a arquitetura deve ser projetada para localizar as operações críticas dentro de um pequeno número de componentes, com todos esses componentes implantados no mesmo computador, em vez de distribuídos pela rede. Isso pode significar o uso de alguns componentes relativamente grandes, em vez de pequenos de baixa granularidade, que reduzem o número de comunicações entre eles. Você também pode considerar a organização do sistema de runtime, que permite que o sistema seja replicado e executado em diferentes processadores.
Proteção: Se a proteção for um requisito crítico, deve ser usada uma estrutura em camadas para a arquitetura, com os ativos mais críticos protegidos nas camadas mais internas, com alto nível de validação de proteção aplicado a essas camadas.
6 Parte de um sistema ou aplicativo de computador que não é acessado diretamente pelo usuário, normalmente responsável por armazenar e manipular dados.
Segurança: Se a segurança for um requisito crítico, a arquitetura deve ser concebida de modo que as operações relacionadas com a segurança estejam localizadas em um único componente ou em um pequeno número de componentes. Isso reduz os custos e os problemas de validação de segurança e torna possível fornecer sistemas de proteção relacionados que podem desligar o sistema de maneira segura em caso de falha.
Disponibilidade: Se a disponibilidade for um requisito crítico, a arquitetura deve ser projetada para incluir componentes redundantes, de modo que seja possível substituir e atualizar componentes sem parar o sistema. Manutenção. Se a manutenção for um requisito crítico, a arquitetura do sistema deve ser projetada a partir de componentes autocontidos de baixa granularidade que podem ser rapidamente alterados. Os produtores de dados devem ser separados dos consumidores, e as estruturas de dados compartilhados devem ser evitadas.
Durante o processo criativo de projeção de um sistema, uma série de decisões estruturais devem ser feitas, e elas afetam profundamente o seu processo de desenvolvimento, conforme lista Sommerville (2011, p. 105):
Existe uma arquitetura genérica de aplicação que pode atuar como um modelo para o sistema que está sendo projetado?
Que padrões ou estilos de arquitetura podem ser usados?
Qual será a abordagem fundamental para se estruturar o sistema? Como os componentes estruturais do sistema serão decompostos em sub componentes?
Que estratégia será usada para controlar o funcionamento dos componentes do sistema?
Qual a melhor organização de arquitetura para satisfazer os requisitos não funcionais do sistema?
Como o projeto de arquitetura será avaliado?
Como a arquitetura do sistema deve ser documentada?
Se deixada a arquitetura por último, o sistema vai se tornar cada vez mais custoso para se desenvolver e eventuais mudanças irão se tornar praticamente impossíveis para uma parte ou todo o sistema, como menciona Martin (2017).
Seria possível desenvolver uma aplicação de lista de afazeres utilizando um padrão arquitetural de computação sem servidor com o intuito de exemplificar e evitar os problemas citados respeitando os requisitos arquiteturais de um software? 1.2 OBJETIVOS
Esta seção aborda os objetivos a serem alcançados através deste projeto, citando o objetivo geral e os objetivos específicos.
1.2.1 Objetivo Geral
Desenvolver uma arquitetura serverless baseada em eventos utilizando a AWS.
1.2.2 Objetivos específicos
Identificar as principais características da arquitetura serverless baseado em eventos.
Definir um domínio para se desenvolver uma proposta de solução utilizando a arquitetura em questão.
Desenvolver o protótipo funcional do domínio escolhido para avaliar a arquitetura.
Avaliar a proposta da solução. 1.3 JUSTIFICATIVA
De acordo com Ian (2011), a arquitetura de software é importante, pois afeta o desempenho e a robustez, bem como a capacidade de distribuição e de manutenibilidade de um sistema.
Para Mendes (2008) diversos benefícios decorrem da incorporação da arquitetura de software como "elemento norteador" do processo de desenvolvimento de software, sendo eles:
Prover suporte ao reuso.
Servir de base à estimação de custos e gerência do projeto. Servir de base para análise da consistência e dependência. Ser utilizada para determinar atributos de qualidade do sistema. Atuar como uma estrutura para atender os requisitos do sistema.
Arquiteturas serverless oferecem maior escalabilidade, mais flexibilidade, e menos tempo para liberar versões, tudo isso com um custo reduzido. Com arquiteturas serverless, desenvolvedores não precisam se preocupar com compras, provisionamento e gerenciamento de servidores backend. (CLOUDFLARE, 2018, tradução nossa).
Este trabalho visa apresentar uma proposta de uma arquitetura serverless baseada em eventos para o desenvolvimento de uma aplicação web. Fazendo o uso de FaaS (Function as a Service), que é “[...] rodar código backend sem gerenciar seu próprio servidor” (ROBERTS, 2018) e o provedor de nuvem AWS (Amazon Web
Services). Essas funções são, para a aplicação web, como uma API e podem ser
publicadas de maneira independente.
Uma das facilidades de se utilizar e trabalhar com serverless é que normalmente cada função tem uma responsabilidade única, que, além de permitir
que a função seja facilmente testável, facilita a manutenção da aplicação pelo desenvolvedor.
A maneira que as funções trabalham e são publicadas também permitem que o desenvolvedor seja livre para escolher a linguagem de programação mais adequada para fazê-lo. Isso evita que o software fique preso a uma linguagem de programação específica ou frameworks desatualizados.
1.4 ESTRUTURA DA MONOGRAFIA
O capítulo 1 faz a introdução do trabalho, trazendo os objetivos, a justificativa, a problemática e a estrutura do trabalho. O capítulo 2 apresenta o referencial teórico. No capítulo 3, é apresentado a metodologia escolhida. No capítulo 4, é realizado a modelagem da proposta de solução. No capítulo 5, é realizado o desenvolvimento do protótipo funcional e a análise dos resultados. Por fim, no capítulo 6, são apresentadas as conclusões do projeto desenvolvido, assim como do modelo proposto, dando sugestões para trabalhos futuros.
2 REVISÃO BIBLIOGRÁFICA
Este capítulo explica a importância da arquitetura de software e lista os principais padrões arquiteturais existentes atualmente. Na sequência, explica-se arquitetura de microsserviços e arquitetura serverless.
2.1 ARQUITETURA DE SOFTWARES
De acordo com Martin (2013) a arquitetura de um sistema de software é a forma dada a esse sistema por aqueles que o desenvolveram. Essa forma depende da divisão do sistema em componentes, a organização desses componentes, e as maneiras que esses componentes se comunicam uns com o outros.
Martin (2017) também comenta que o propósito principal de arquitetura é suportar o ciclo de vida de um sistema. Uma boa arquitetura faz com que o sistema seja fácil de entender, fácil de desenvolver, fácil de manter e fácil de publicar. O objetivo principal é minimizar o custo de vida de um sistema e maximizar a produtividade do programador.
As seções seguintes abordam alguns exemplos de padrões de arquitetura amplamente utilizados.
2.1.1 MVC
De acordo com Medeiros (2013) o MVC (modelo-visão-controlador, do inglês Model-View-Controller) é utilizado em muitos projetos devido à arquitetura que possui, o que possibilita a divisão do projeto em camadas muito bem definidas. Cada uma delas, o Model, o Controller e a View, executa o que lhe é definido e nada mais do que isso.
Medeiros (2013) complementa que a utilização do padrão MVC trás como benefício isolar as regras de negócios da lógica de apresentação, a interface com o usuário. Isto possibilita a existência de várias interfaces com o usuário que podem ser modificadas sem que haja a necessidade da alteração das regras de negócios, proporcionando assim muito mais flexibilidade e oportunidades de reuso das classes. O quadro 1 traz a descrição do padrão MVC, assim como vantagens e desvantagens.
Quadro 1 - Descrição do padrão MVC
Nome MVC (Modelo-Visão-Controlador)
Descrição Separa a apresentação e a interação dos dados do sistema. 0 sistema é estruturado em três componentes lógicos que interagem entre si. 0 componente Modelo gerencia o sistema de dados e as operações associadas a esses dados. 0 componente Visão define e gerencia como os dados são apresentados ao usuário. 0 componente Controlador gerencia a interação do usuário (por exemplo, teclas, cliques do mouse etc.) e passa essas interações para a Visão e o Modelo.
Quando é usado
É usado quando existem várias maneiras de se visualizar e interagir com dados. Também quando são desconhecidos os futuros requisitos de interação e apresentação de dados.
Vantagens Permite que os dados sejam alterados de forma independente de sua representação, e vice-versa. Apoia a apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação aparecendo em todas elas.
Desvantagen s
Quando o modelo de dados e as interações são simples, pode envolver código adicional e complexidade de código.
Fonte: SOMMERVILLE (2011, p. 109)
A figura 1 exemplifica como é organizado o padrão de arquitetura MVC:
Figura 1 - Descrição do padrão MVC
Fonte: SOMMERVILLE (2011, p. 109)
Na Figura 2 tem-se uma possível arquitetura em tempo de execução, quando esse padrão é usado para gerenciamento de interações em um sistema baseado em Web.
(continua)
Figura 2 - Arquitetura MVC em tempo de execução
Fonte: SOMMERVILLE (2011, p. 109)
A seção a seguir apresenta o padrão arquitetural de cliente-servidor. 2.1.2 Arquitetura cliente-servidor
“Um sistema que segue o padrão cliente-servidor é organizado como um conjunto de serviços e servidores associados e clientes que acessam e usam os serviços”. (SOMMERVILLE, 2011, p.113).
O quadro 2 apresenta a descrição de uma arquitetura cliente-servidor, assim como vantagens e desvantagens.
Quadro 2 - Descrição da arquitetura cliente-servidor
Nome Cliente-servidor
Descrição Em uma arquitetura cliente-servidor, a funcionalidade do sistema está organizada em serviços — cada serviço é prestado por um servidor. Os clientes são os usuários desses serviços e acessam os servidores para fazer uso deles.
Quando é usado
É usado quando os dados em um banco de dados compartilhado precisam ser acessados a partir de uma série de locais. Como os servidores podem ser replicados, também pode ser usado quando a carga em um sistema é variável. Vantagens A principal vantagem desse modelo é que os servidores podem ser distribuídos
através de uma rede. A funcionalidade geral (por exemplo, um serviço de impressão) pode estar disponível para todos os clientes e não precisa ser
(conclusão)
Quadro 2 - Descrição da arquitetura cliente-servidor
Nome Cliente-servidor
implementada por todos os serviços. Desvantagen
s
Cada serviço é um ponto único de falha suscetível a ataques de negação de serviço ou de falha do servidor. 0 desempenho, bem como o sistema, pode ser imprevisível, pois depende da rede. Pode haver problemas de gerenciamento se os servidores forem propriedade de diferentes organizações.
Fonte: SOMMERVILLE (2011, p. 113)
“As arquiteturas cliente-servidor são normalmente consideradas arquiteturas de sistemas distribuídos, mas o modelo lógico de serviços independentes rodando em servidores separados pode ser implementado em um único computador.” (SOMMERVILLE, 2011, p.113).
A principal vantagem do modelo cliente-servidor é que se trata de uma arquitetura distribuída. O uso efetivo pode ser feito por sistemas em rede com muitos processadores distribuídos. É fácil adicionar um novo servidor e integrá-lo com o resto do sistema ou atualizar os servidores de forma transparente, sem afetar outras partes do sistema. (SOMMERVILLE, 2011, p. 114).
A figura 3 apresenta um exemplo de uma arquitetura cliente-servidor para uma biblioteca de filmes:
Figura 3 - Uma arquitetura cliente-servidor para uma biblioteca de filmes
Fonte: SOMMERVILLE (2011, p. 114)
De acordo com Sommerville (2011, p. 113) a Figura 3 exemplifica um sistema multiusuário baseado na Internet para fornecimento de uma biblioteca de filmes e fotos. Nesse sistema, vários servidores gerenciam e apresentam os diferentes tipos de mídia. Os quadros de vídeo precisam ser transmitidos de forma rápida e em
sincronia, mas em resolução relativamente baixa. Eles podem ser comprimidos em um arquivo, de modo que o servidor de vídeo possa lidar com a compressão e descompressão de vídeo em diferentes formatos. As fotos, porém, devem permanecer em uma resolução alta; por isso, é conveniente mantê-las em um servidor separado.
2.1.3 Arquitetura em camadas
Para Sommerville (2011) a arquitetura em camadas é uma arquitetura mutável e portável. Quando uma camada é desenvolvida, alguns dos serviços prestados por ela podem ser disponibilizados para os usuário.
O quadro 3 apresenta a descrição de uma arquitetura em camadas, assim como vantagens e desvantagens.
Quadro 3 - Descrição da arquitetura em camadas
Nome Arquitetura em camadas
Descrição Organiza o sistema em camadas com a funcionalidade relacionada associada a cada camada. Uma camada fornece serviços à camada acima dela; assim, os níveis mais baixos de camadas representam os principais serviços suscetíveis de serem usados em todo o sistema.
Quando é usado
É usado na construção de novos recursos em cima de sistemas existentes; quando o desenvolvimento está espalhado por várias equipes, com a responsabilidade de cada equipe em uma camada de funcionalidade quando há um requisito de proteção multinível.
Vantagens Desde que a interface seja mantida, permite a substituição de camadas inteiras. Recursos redundantes (por exemplo, autenticação) podem ser fornecidos em cada camada para aumentar a confiança do sistema.
Desvantagen s
Na prática, costuma ser difícil proporcionar uma clara separação entre as camadas, e uma camada de alto nível pode ter de interagir diretamente com camadas de baixo nível, em vez de através da camada imediatamente abaixo dela. 0 desempenho pode ser um problema por causa dos múltiplos níveis de interpretação de uma solicitação de serviço, uma vez que são processados em cada camada.
Fonte: SOMMERVILLE (2011, p. 110)
Bertoleti (2015) exemplifica as principais vantagens de se utilizar esse formato:
Separando em camadas, pode-se fazer o desenvolvimento de um sistema em etapas. Com isso, além da organização, ganha-se tempo e performance.
mais limpos, facilitando o entendimento futuro do software.
Caso algum problema surgir, neste tipo de organização de software é mais fácil encontrá-lo e eliminá-lo, pois como as camadas são bem “isoladas” (focadas em funcionalidades específicas), fica relativamente simples descobrir em qual camada o problema está (por conseqüência, o tempo de debug diminui).
Organizando em camadas é possível substituir uma camada inteira por outra sem comprometer o sistema todo.
A seção a seguir apresenta com detalhes o padrão arquitetural de repositório, mostrando as vantagens, desvantagens e quando deve ser utilizado.
2.1.4 Arquitetura de repositório
“A maioria dos sistemas que usam grandes quantidades de dados é organizada em torno de um banco de dados ou repositório compartilhado. Esse modelo é, portanto, adequado para aplicações nas quais os dados são gerados por um componente e usados por outro.“ (SOMMERVILLE, 2012, p.113).
O quadro 4 exibe uma descrição detalhada da arquitetura de repositório.
Quadro 4 - Descrição da arquitetura de repositório
Nome Repositório
Descrição Todos os dados em um sistema são gerenciados em um repositório central, acessível a todos os componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório.
Quando é usado
Você deve usar esse padrão quando tem um sistema no qual grandes volumes de informações são gerados e precisam ser armazenados por um longo tempo. Você também pode usá-lo em sistemas dirigidos a dados, nos quais a inclusão dos dados no repositório dispara uma ação ou ferramenta.
Vantagens Os componentes podem ser independentes —eles não precisam saber da existência de outros componentes. As alterações feitas a um componente podem propagar-se para todos os outros. Todos os dados podem ser gerenciados de forma consistente (por exemplo, backups feitos ao mesmo tempo), pois tudo está em um só lugar.
Desvantagen s
0 repositório é um ponto único de falha, assim, problemas no repositório podem afetar todo o sistema. Pode haver ineficiências na organização de toda a comunicação através do repositório. Distribuir o repositório através de vários computadores pode ser difícil.
Fonte: SOMMERVILLE (2011, p. 112)
Sommerville (2011) aponta que a organização de ferramentas em torno de um repositório constitui uma maneira eficiente de compartilhar grandes quantidades de dados. Não há necessidade de transmitir dados explicitamente de um
componente para outro.
No entanto, os componentes devem operar em torno de um modelo aprovado de repositório de dados. Inevitavelmente, esse é um compromisso entre as necessidades específicas de cada ferramenta, e pode ser difícil ou impossível integrar novos componentes se seus modelos de dados não se adequam ao esquema acordado. Na prática, pode ser difícil distribuir o repositório por meio de uma série de máquinas. Embora seja possível a distribuição de um repositório logicamente centralizado, pode haver problemas com a redundância e inconsistência de dados. (SOMMERVILLE, 2011, p. 112).
Sommerville (2011) mostra, através da Figura 4 que o repositório é passivo e o controle é de responsabilidade dos componentes que usam o repositório.
Figura 4 - Uma arquitetura de repositório para uma IDE
Fonte: SOMMERVILLE (2011, p. 112)
2.2 MICROSSERVIÇOS
De acordo com Franzini (2017) a arquitetura de microsserviços é um estilo arquitetônico que estrutura uma solução como uma coleção de serviços ligeiramente acoplados, que implementam capacidades empresariais.
Franzini (2017) também descreve que a arquitetura microservice permite a entrega e a implantação contínua de aplicativos grandes e complexos. Ela também permite que uma organização evolua sua pilha de tecnologia.
“Microsserviços foram originados da ideia de uma arquitetura hexagonal cunhada por Alistair Cockburn, Arquitetura hexagonal também é conhecida como o padrão de portas e adaptadores.” (RV, 2016).
A figura 5 apresenta um exemplo de uma arquitetura de microsserviços:
Figura 5 - Uma arquitetura de microsserviços
Fonte: FRANZINI (2017)
De acordo com Rajesh (2016) não existem padrões de comunicação ou mecanismos de transporte para microsserviços. Em geral, os microsserviços utilizam protocolos como HTTP e REST7. (Representational State Transfer), ou protocolos de mensageria, tais como JSM ou AMQP. Em casos específicos, um pode escolher um protocolo de comunicação mais otimizado, como Thrift, ZeroMQ, Buffers8. de Protocolo, ou Avro (RV, 2016).
Rajesh (2016) também fala que microsserviços são auto-contidos, podem sofrer deploys independentes e são autônomos, possuindo total responsabilidade de uma capacidade de negócio e sua execução. Eles empacotam todas as dependências, incluindo dependências de bibliotecas e ambientes de execução, como web servers, contêineres ou máquinas virtuais que abstraem recursos físicos.
7 Um estilo de arquitetura de software que define um conjunto de restrições a serem usadas para criar serviços da Web.
2.3 SERVERLESS
Segundo Roberts (2018), serverless são aplicações onde a lógica do lado do servidor continua sendo escrita pelo desenvolvedor da aplicação, mas, diferente de arquiteturas tradicionais, executa em contêineres de computação sem servidor que são ativados por eventos, efêmero (pode durar apenas uma evocação) e totalmente gerenciado por um terceiro.
2.3.1 Desmistificando Função como Serviço
Para Roberts (2018), a implantação de FaaS é muito diferente dos sistemas tradicionais, já que não temos aplicativos de servidor para nós executarmos. Em um ambiente FaaS, nós carregamos o código da nossa função para o provedor FaaS, e o provedor faz todo o resto necessário para provisionar recursos, instanciar máquinas virtuais, gerenciar processos, etc.
A escala horizontal é totalmente automática, elástica e gerenciada pelo fornecedor. Roberts (2018) explica que se o seu sistema precisar processar 100 solicitações em paralelo, o provedor lidará com isso sem qualquer configuração extra de sua parte. Os “contêineres de computação” que executam suas funções são efêmeros, com o provedor de FaaS criando e destruindo-os puramente orientados pela necessidade de tempo de execução. Mais importante ainda, com o FaaS, o fornecedor lida com todo o provisionamento e alocação de recursos subjacentes -nenhum gerenciamento de cluster ou de máquina virtual é exigido pelo usuário. 2.3.1.1 Estado
Segundo Roberts (2018) as funções FaaS (function as a service) têm restrições significativas quando se trata de estado local (ligado a máquina / instância), ou seja, dados que você armazena em variáveis na memória ou dados que você escreve no disco local. Você tem esse armazenamento disponível, mas você não tem garantia de que tal estado é persistente em várias chamadas e, mais fortemente, você não deve assumir que o estado de uma chamada de uma função estará disponível para outra chamada da mesma função.
“As funções FaaS são, portanto, frequentemente descritas como apátridas, mas é mais correto dizer que qualquer estado de uma função FaaS que precisa ser persistente precisa ser externalizado fora da instância da função FaaS.” (ROBERTS, 2018, tradução nossa).
2.3.1.2 Duração da execução
As funções FaaS são tipicamente limitadas em quanto tempo cada chamada pode ser executada. Roberts (2018) defende que certas classes de tarefas de longa duração não são adequadas para funções FaaS sem re-arquitetura, você pode precisar criar várias funções FaaS coordenadas diferentes, enquanto que em um ambiente tradicional você pode ter uma tarefa de longa duração realizando coordenação e execução.
2.3.1.3 Latência de inicialização
Segundo Roberts (2018) demora um tempo até que uma plataforma FaaS inicializa uma instância de uma função antes de cada evento. Esse tempo de inicialização pode variar significantemente, até mesmo para uma função específica, dependendo de grandes números de fatores, e pode variar de alguns milissegundos até vários segundos.
“A inicialização de uma função da AWS pode ser tanto uma “inicialização morna” (re-usando a instância de uma função e seu contêiner de um evento anterior) ou um “inicialização fria” (criando uma nova instância de contêiner, inicializando o processo da função, etc.). Surpreendentemente, quando considerado a latência de inicialização, são essas atualizações frias que trazem as maiores preocupações”. (ROBERTS, 2018).
2.3.2 Benefícios
As seções seguintes trazem benefícios em se utilizar a arquitetura serverless. 2.3.2.1 Reduzir custos operacionais
Serverless é, na sua forma mais simples, uma solução de terceirização. Roberts (2018) explica que serverless permite que você pague a alguém para gerenciar servidores, bancos de dados e até mesmo lógica de aplicativo que você poderia gerenciar sozinho. Como você está usando um serviço predefinido que muitas outras pessoas também usarão, vemos um efeito de Economia de escala: você paga menos pelo banco de dados gerenciado porque um fornecedor está executando milhares de bancos de dados muito semelhantes.
De acordo com Roberts (2018) os custos reduzidos aparecem para o usuário como o total de dois aspectos. O primeiro é o ganho de custo de infraestrutura
proveniente apenas do compartilhamento de infraestrutura (por exemplo, hardware9., rede) com outras pessoas. O segundo são os ganhos com custos trabalhistas: você poderá gastar menos tempo com um sistema sem servidor terceirizado do que com um equivalente desenvolvido e hospedado por você mesmo.
2.3.2.2 Custos de escalonamento
Conforme mencionado por Roberts (2018) uma das alegrias do serverless FaaS é que o escalonamento horizontal é completamente automático, elástico e gerenciado pelo provedor.
A figura 6 exemplifica escala versus custo:
Figura 6 - Um exemplo de escala versus custo
Fonte: https://www.trek10.com/blog/serverless-framework-for-processes-projects-and-scale
De acordo com Roberts (2018) existem vários benefícios olhando para a figura 6, mas no lado da infra-estrutura básica o maior benefício é que você paga
apenas pelo cálculo necessário, até um limite de 100 milissegundos no caso do AWS Lambda. Dependendo da sua escala e forma de tráfego, isso pode ser uma grande vitória econômica para você.
2.3.2.2.1 Chamadas ocasionais
Para Roberts (2018) o FaaS sem servidor capta a ineficiência das chamadas ocasionais, entregando o benefício a você com custo reduzido. Com o aplicativo de exemplo acima, você estaria pagando apenas 100 ms de computação a cada minuto, o que corresponde a 0,15% do tempo total.
Roberts (2018) exemplifica se você executar um aplicativo de servidor que processa apenas uma solicitação a cada minuto, leva 50 ms (milissegundos) para processar cada solicitação e seu uso médio da CPU10. (Central Process Unit) em uma hora é de 0,1%. Se esse aplicativo for implementado em seu próprio host dedicado, isso será altamente ineficiente. Mil outras aplicações similares poderiam compartilhar essa única máquina.
“Para microsserviços em potencial que possuem requisitos de carga muito pequenos, ele fornece suporte para decompor componentes por lógica / domínio, mesmo que os custos operacionais de tal granularidade fina possam ter sido de outra forma proibitivos.” (ROBERTS, 2018).
Roberts (2018) menciona que tais benefícios de custo são um grande democratizador. Se as empresas ou equipes quiserem experimentar algo novo, elas terão custos operacionais extremamente pequenos associados a “mergulhar o dedo do pé na água” quando usarem o FaaS para suas necessidades de computação. Na verdade, se sua carga de trabalho total for relativamente pequena (mas não totalmente insignificante), talvez você não precise pagar por nenhum cálculo devido à “camada gratuita” fornecida por alguns fornecedores de FaaS.
2.3.2.2.2 Tráfego inconsistente
De acordo com Roberts (2018) em um ambiente tradicional, você pode precisar aumentar sua contagem total de hardware por um fator de 10 sobre o que poderia ser para lidar com os picos, mesmo que as durações totais dos picos representem menos de 4 por cento do tempo total de funcionamento da máquina.
“Digamos que seu perfil de tráfego é muito complicado - talvez seu tráfego de linha de base seja de 20 solicitações por segundo, mas a cada cinco minutos você recebe 200 solicitações por segundo (10 vezes o número normal) por 10 segundos. Suponhamos também, para fins de exemplo, que seu desempenho de linha de base maximiza o tipo de servidor host preferido e que você não deseja reduzir seu tempo de resposta durante a fase de pico de tráfego. Como você resolve isso?”. (ROBERTS, 2018, on-line).
“O escalonamento automático provavelmente não é uma boa opção aqui, devido a quanto tempo as novas instâncias de servidores demoram a aparecer (no momento em que suas novas instâncias forem inicializadas, a fase de pico terá terminado)”. (ROBERTS, 2018, on-line).
A figura 7 exemplifica tráfego inconsistente, apresentando picos de execução em curtos períodos.
Figura 7 - Um exemplo de tráfego inconsistente
Fonte: ROBERTS (2018)
Roberts (2018) diz que usando o serverless FaaS, no entanto, isso não é um problema. Você literalmente não faz nada diferente do que se seu perfil de tráfego fosse uniforme, e você só paga pela capacidade de computação extra durante as fases de pico.
“Obviamente, eu escolhi deliberadamente exemplos aqui para os quais o Serverless FaaS oferece uma enorme economia de custo, mas o ponto é mostrar que, a partir de um ponto de vista de escala, a menos que você tenha uma forma de tráfego muito estável que use consistentemente toda a capacidade de seus servidores, Você pode economizar dinheiro usando o FaaS. Uma ressalva sobre o que foi dito acima: se o seu tráfego é uniforme e consistentemente faria uma boa utilização de um servidor em execução, você pode não ver esse custo benefício, e você pode realmente gastar mais usando o FaaS. (ROBERTS, 2018).
os custos atuais do provedor com os equivalentes de servidores em tempo integral. Descobrindo assim se os custos são ou não aceitáveis.
2.3.2.2.3 Otimização é a raiz de algumas economias de custo
De acordo com Roberts (2018) qualquer otimização de desempenho que você fizer no seu código não apenas aumentará a velocidade do seu aplicativo, mas também terá uma ligação direta e imediata para a redução dos custos operacionais, sujeito à granularidade do esquema de cobrança do seu fornecedor.
2.3.2.3 Gerenciamento operacional mais fácil
As seções seguintes trazem benefícios e vantagens que fazem da arquitetura
serverless possuir um gerenciamento operacional mais fácil.
2.3.2.3.1 Benefícios de escalonamento do FaaS além dos custos de infraestrutura Segundo Roberts (2018) se o processo de dimensionamento for manual, digamos, um ser humano precisa adicionar e remover explicitamente instâncias a uma variedade de servidores. Com o FaaS, você pode esquecer isso com muita clareza e deixar que o fornecedor do FaaS dimensione seu aplicativo para você.
“Mesmo que você tenha chegado ao ponto de usar o escalonamento automático em uma arquitetura não-FaaS, isso ainda requer configuração e manutenção. Este trabalho não é mais necessário com o FaaS.” (ROBERTS, 2018)
Roberts (2018) defende que você não precisa mais pensar sobre a quantidade de solicitações simultâneas que pode manipular antes de ficar sem memória ou ver muito de um desempenho - pelo menos não dentro seus componentes hospedados no FaaS. Logo que o escalonamento é executado pelo provedor em cada solicitação / evento. Bases de dados a jusante e componentes não-FaaS terão que ser reconsiderados à luz de um aumento possivelmente significativo em sua carga.
2.3.2.3.2 Complexidade reduzida de empacotamento e implantação
Empacotar e implantar uma função FaaS é simples comparado à implantação de um servidor inteiro. De acordo com Roberts (2018), tudo o que você está fazendo é empacotar todo o seu código em um arquivo zip11. e enviá-lo. Sem scripts de início e parada, sem decisões sobre a implementação de um ou vários contêineres em
uma máquina. Se você está apenas começando, nem precisa empacotar nada. Você pode escrever seu código no próprio console do fornecedor. Ele ainda reforça que a prática de escrever código no próprio console do fornecedor não é recomendado para o código de produção.
2.3.2.3.3 Tempo para comercializar e experimentação contínua
Roberts (2018) menciona que além do menor tempo gasto em operações significa menos pessoas necessárias para as operações, uma razão muito mais importante é a hora de comercializar.
À medida que nossas equipes e produtos se tornam cada vez mais voltados para processos enxutos e ágeis, queremos continuamente experimentar coisas novas e atualizar rapidamente nossos sistemas existentes. Embora a simples realocação no contexto de entrega contínua permita uma rápida iteração de projetos estáveis, ter uma boa capacidade de nova ideia para implantação inicial nos permite experimentar novos experimentos com baixo atrito e custo mínimo.
2.4 FRAMEWORKS PARA SERVERLESS
As seções seguintes trazem diferentes frameworks para o desenvolvimento de arquiteturas serverless.
2.4.1 Knative
O Knative estende o Kubernetes12. com o objetivo de providenciar um conjunto de componentes middlewares13. que são essenciais para construir aplicações modernas e baseadas em contêineres. De acordo com o próprio site do Knative, esses componentes podem rodar em qualquer lugar: nas dependências, na nuvem, ou até mesmo em servidores de terceiros.
2.4.2 Kubeless
Kubeless é um framework serverles Kubernetes-native que possibilita que você realize o deploy de pequenos pedaços de códigos (funções) sem a necessidade de se preocupar com a infraestrutura. De acordo com a documentação no site do Kubeless, o framework é desenhado para ter seu deploy realizado em um
12 Sistema de orquestração de contêineres open-source que automatiza a implantação, o dimensionamento e a gestão de aplicações em contêineres.
cluster do Kubernetes e tirar vantagem dos incríveis primitivos do Kubernetes. 2.4.3 Serverless Framework
O framework Serverless é um framework web gratuito e de código aberto escrito usando Node.js. Serverless é o primeiro primeiro framework que foi originalmente desenvolvido para construir aplicações exclusivamente na AWS Lambda, uma plataforma de computação sem servidor provida pela Amazon como parte da Amazon Web Services. Atualmente, aplicações desenvolvidas com o
framework Serverless podem ser entregues e publicadas em outros provedores de
3 MÉTODO
Para alcançar a proposta de uma arquitetura serverless baseada em eventos para aplicações web utilizando a AWS que é apresentada neste trabalho, foi preciso definir um caminho a ser traçado para alcançar o resultado esperado, este que foi estipulado pelo método. “Método” deriva do latim methodus, quem significa “caminho”, a palavra, no entanto, tem origens gregas: meta (através, por meio de) hodos (caminho), donde methodos.
Segundo Gil (2008, p.8), “pode-se definir método como caminho para se chegar a determinado fim”.
Para Eva e Marina (1986, p,81), método, é o “conjunto das atividades sistemáticas e racionais que, com maior segurança e economia, permite alcançar o objetivo [proposto], traçando o caminho a ser seguido, detectando os erros e analisando as decisões do cientista”.
Tendo isso, nesta seção é apresentado os caminhos definidos pelo método a fim de executar os objetivos do trabalho, em sequência esclarecer os tipos de pesquisa, as etapas metodológicas, a proposta e suas delimitações.
3.1 TIPOS DE PESQUISAS ADOTADOS
Definir e caracterizar quais tipos de pesquisa podem ser adotados é importante para a metodologia de desenvolvimento e pesquisa. Segundo Gil (2008, p.26) a pesquisa tem um caráter pragmático, é um “processo formal e sistemático de desenvolvimento do método científico. O objetivo fundamental da pesquisa é descobrir respostas para problemas mediante o emprego de procedimentos científicos”.
Segundo José (2006, p.64), “o ato de pesquisar traz em si a necessidade do diálogo com a realidade a qual se pretende investigar e com o diferente, um diálogo dotado de crítica, canalizador de momentos criativos”.
Com essa breve explicação de pesquisa, tem se base para dar início a caracterização desse trabalho. Quanto à natureza, este projeto se classifica como aplicado; quanto a abordagem, é classificada como qualitativo; quanto aos objetivos, se classifica como exploratório; e quanto aos procedimentos, como bibliográfico. 3.1.1 Pesquisa bibliográfica
Quanto à pesquisa bibliográfica, Fonseca (2002, p. 32) afirma que:
A pesquisa bibliográfica é feita a partir do levantamento de referências teóricas já analisadas, e publicadas por meios escritos e eletrônicos, como livros, artigos científicos, página de web sites. (Matos e Lerche: 40) sobre o
tema a estudar. Qualquer trabalho científico inicia-se com uma pesquisa bibliográfica, que permite ao pesquisador conhecer o que já se estudou sobre o assunto. Existem, porém, pesquisas científicas que se baseiam unicamente na pesquisa bibliográfica, procurando referências teóricas publicadas com o objetivo de recolher informações ou conhecimentos prévios sobre o problema a respeito do qual se procura a resposta. As conclusões não podem ser apenas um resumo. O pesquisador tem de ter o cuidado de selecionar e analisar cuidadosamente os documentos a pesquisar de modo a evitar comprometer a qualidade da pesquisa com erros resultantes de dados coletados ou processados de forma equívoca.
Ou seja, a partir de conhecimentos teóricos esse tipo de pesquisa busca a solução de um problema, que vão contribuir para um determinado assunto, e, em concordância com Fonseca (2002), Gil (2008, p. 50) conclui que:
A pesquisa bibliográfica é desenvolvida a partir de material já elaborado, constituído principalmente de livros e artigos científicos. Embora em quase todos os estudos seja exigido algum tipo de trabalho dessa natureza, há pesquisas desenvolvidas exclusivamente a partir de fontes bibliográficas. Parte dos estudos exploratórios podem ser definidos como pesquisas bibliográficas, assim como certo número de pesquisas desenvolvidas a partir da técnica de análise de conteúdo.
Nesse sentido, esta pesquisa deve ser considerada como pesquisa bibliográfica porque se utiliza de livros e artigos científicos para o aperfeiçoamento do tema, arquitetura serverless baseada em eventos.
3.1.2 Pesquisa aplicada
Boaventura (2004) classifica a pesquisa aplicada como o tipo de pesquisa que busca aumentar o conhecimento científico através da descoberta de leis e efeitos.
Segundo Gil (2008) a pesquisa aplicada apresenta muitos pontos de contato com a pesquisa pura, pois depende de suas descobertas e se enriquece com o seu desenvolvimento; todavia, tem como característica fundamental o interesse na aplicação, utilização e consequências práticas dos conhecimentos.
Gil (2008) também ressalta que sua preocupação está menos voltada para o desenvolvimento de teorias de valor universal que para a aplicação imediata numa realidade circunstancial. De modo geral é este o tipo de pesquisa a que mais se dedicam os psicólogos, sociólogos, economistas, assistentes sociais e outros pesquisadores sociais.
3.1.3 Pesquisa qualitativa
Quanto à pesquisa qualitativa Richardson (1999) informa que esta tem aumentado sua credibilidade nas ciências sociais. "Essa legitimidade, porém, foi comprada ao preço de incorporar critérios positivistas de validade e generalização.". A pesquisa qualitativa busca explicar o porquê das coisas, exprimindo o que convém ser feito, não se preocupando com representatividade numérica, mas, sim, com o
aprofundamento da compreensão de um grupo social, de uma organização, etc. Para Deslauriers (1991, p. 58) nesse tipo de pesquisa “o conhecimento do pesquisador é parcial e limitado. O objetivo da amostra é de produzir informações aprofundadas e ilustrativas: seja ela pequena ou grande, o que importa é que ela seja capaz de produzir novas informações.”
3.2 ETAPAS DA PESQUISA
Para Silva (2005, p. 29), “A pesquisa é um procedimento reflexivo e crítico de busca de respostas para problemas ainda não solucionados”. Para definir as etapas da pesquisa é necessário planejamento. Existem diversas maneiras de planejar estas etapas e a escolha delas.
Primeiramente é feita a revisão bibliográfica para identificar padrões utilizados em propostas de arquiteturas serverless e outras arquiteturas já publicadas. Os conceitos e características de propostas de arquitetura serverless serão identificados. É feita uma avaliação das tecnologias e ferramentas que auxiliam no desenvolvimento de arquiteturas serverless. Tendo essas definições, é criado uma proposta de arquitetura serverless para se utilizar em novos projetos. Baseado na proposta definida é criada uma aplicação modelo para a validação. Por último, é feita uma avaliação das vantagens e desvantagens da proposta em cima da aplicação modelo.
A figura 8 apresenta as atividades que serão executadas para atingir o objetivo proposto no trabalho.
Figura 8 - Fluxograma das atividades a serem executadas no projeto
Fonte: Os autores (2019)
Após a execução das atividades apresentadas na figura 8, é feita uma avaliação para atestar a viabilidade da proposta de arquitetura serverless baseada em eventos.
3.3 ARQUITETURA DE PROPOSTA DE SOLUÇÃO
O objetivo deste trabalho constitui-se em propor um modelo de arquitetura
serverless baseada em eventos na AWS, mostrando as melhores práticas e
ferramentas existentes para se criar um nova aplicação utilizando deste modelo com a utilização de diversos serviços da AWS.
Figura 9 - Exemplo da arquitetura serverless proposta
Fonte: Os autores (2019)
A arquitetura é composta por Lambdas que se comunicam entre si através de eventos utilizando o SQS e também por requisições vindas de clientes através de endpoints Rest via API Gateway e eventos via SQS. Todas as informações processadas nos Lambdas que devem ser armazenadas são enviadas para o DynamoDB.
Para avaliar se a arquitetura serverless baseada em eventos é satisfatória, é desenvolvido uma aplicação de lista de afazeres utilizando a arquitetura proposta.
Ao final do trabalho, é realizado uma pesquisa sobre Serverless com pessoas desenvolvedoras de software especialistas utilizando o Google Forms.
3.4 DELIMITAÇÕES
Como mencionado nos tópicos anteriores, este trabalho propõe apresentar uma proposta de uma arquitetura serverless baseada em eventos para aplicações web utilizando a AWS. A ideia é desenvolver uma todo list utilizando um framework JavaScript para construir o front-end da aplicação, que irá se comunicar através de eventos com as funções Lambda na AWS, utilizando serviços já existentes disponibilizados pela plataforma para montar o fluxo e a estrutura das funções. Esta proposta não contemplará nenhum aspecto de segurança, como a segurança das informações que trafegam nos eventos, assim como o código do frontend da aplicação. O objetivo é propor um fluxo de comunicação entre as partes da aplicação web com esta nova arquitetura de funções como serviço.
4 MODELAGEM DO SISTEMA PROPOSTO
Para facilitar o processo de desenvolvimento de software é preciso entender as características do sistema e seus comportamentos. Diferentes estratégias de modelagem podem ser utilizadas durante a construção de um sistema e guiar o desenvolvimento de maneira consistente e mantendo o rumo do planejamento durante a duração do projeto.
4.1 METODOLOGIAS E TÉCNICAS
Existem inúmeros métodos e técnicas que podem ser utilizadas durante o processo de modelagem e tudo pode variar de acordo com a necessidade do modelo de software proposto. Nas seções seguintes são apresentadas algumas das técnicas e padrões que podem ser utilizados nesse processo.
4.1.1 UML - Linguagem de Modelagem Unificada
O UML (do inglês Unified Modeling Language) é uma linguagem para especificação, construção, visualização e documentação de artefatos de um sistema de software. Silva et al (2001) menciona que o UML é independente das linguagens de programação, das ferramentas CASE14. (do inglês Computer-Aided Software Engineering), bem como dos processos de desenvolvimento.
Silva et al (2001) também relata que o objetivo do UML é que, dependendo do tipo de projeto, da ferramenta de suporte, ou da organização envolvida, devem ser adotados diferentes processos/metodologias, mantendo-se contudo a utilização da mesma linguagem de modelação.
O UML é independente das ferramentas de modelação. Silva et al (2001) ressalta que apesar da especificação do UML incluir sugestões para os fabricantes de ferramentas adotarem na apresentação dessas notações (e.g., tópicos como o desenho de diagramas, cor, navegação entre esquemas, etc.), não aborda todos os requisitos necessários por não ser esse, propositadamente, o seu objetivo.
4.1.1.1 Evolução da UML
Na primeira metade da década de 1990 assistiu-se a uma proliferação de métodos e notações para modelagem segundo a abordagem orientado por objetos. De acordo com Silva et al (2001), por essa altura percebeu-se a necessidade da
14 Uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de engenharia de software.
existência de uma linguagem que viesse a tornar-se uma norma, que fosse aceite e utilizada quer pela indústria, quer pelos ambientes acadêmicos ou pelos pesquisadores.
De acordo com Silva et al (2001) o UML apareceu em 1996 melhor posicionado como uma linguagem unificadora de notações, diagramas e formas de representação existentes em diferentes métodos, em particular nos métodos Booch, OMT e OOSE (fase da unificação).
A figura 10 traz uma visão do enquadramento histórico relativo ao UML:
Figura 10 - Visão histórica do UML
Fonte: Rodrigues da Silva (2001)
“Seguiu-se um esforço significativo nessa unificação com contributos de vários parceiros com vista à normalização no âmbito da OMG, o que aconteceu em 1997”. (SILVA, 2001, p.120).
Atualmente tem-se a adoção generalizada do UML como ”a” linguagem de modelação de software segundo a abordagem orientada por objetos. Silva et al (2001) cita sobre o início das publicações específicas sobre UML, teses, relatórios e artigos técnico-científicos que usam o UML por volta dessa mesma época.
A versão mais recente da UML é a 2.5 e foi lançada em 2013. De acordo com o site uml-diagrams.org a nova edição trouxe novos padrões de modelagem tanto para diagramas estruturais, quanto para diagramas de comportamento.
A figura 11 apresenta os tipos de diagramas que existem atualmente na versão 2.5 da UML.
Figura 11 - Tipos de diagramas UML
Fonte: UML Diagrams
De acordo com Silva et al (2001) a UML é usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer característica de um sistema em um de seus diagramas e é também aplicada em diferentes fases do desenvolvimento de um sistema, desde a especificação da análise de requisitos até a finalização com a fase de testes.
4.1.1.2 Diagramas da UML
A UML possui muitos diagramas e o objetivo disso é fornecer múltiplas visões do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos, procurando-se, assim, atingir a completitude da modelagem, permitindo que cada diagrama complemente os outros. Guedes (2009) compara esse processo como se o sistema fosse modelado em camadas, sendo que alguns diagramas enfocam o
sistema de forma mais geral, apresentando uma visão externa do sistema, como é o objetivo do Diagrama de Casos de Uso, enquanto outros oferecem uma visão de uma camada mais profunda do software, apresentando um enfoque mais técnico ou ainda visualizando apenas uma característica específica do sistema ou um determinado processo.
“A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrência de erros futuros.“ (GUEDES, 2009, p.120).
Os diagramas UML conhecidos são: Classe, Componentes, Objetos, Estrutura Composta, Instalação, Pacote, Atividade, Interação, Casos de uso, Estados, Sequência, Visão de Interação, Comunicação e Tempos.
Como este trabalho diz respeito a uma arquitetura serverless, opta-se por dar enfoque maior nos diagramas de componente e implantação.
Esta escolha foi feita com base na melhor representação gráfica da comunicação entre as requisições HTTP do client, feito em React.js, para o Api Gateway, que através de eventos se comunica com o Lambda, que por sua vez salva no banco de dados.
4.1.1.2.1 Diagrama de Componentes
De acordo com Guedes (2009) o diagrama de componentes está amplamente associado à linguagem de programação que será utilizada para desenvolver o sistema modelado.
Figura 12 - Exemplo Diagrama de Componentes
Fonte: GUEDES (2009, p. 39)
O diagrama representa os componentes do sistema quando o mesmo for ser implementado em termos de módulos e determina como tais componentes estarão estruturados e irão interagir para que o sistema funcione de maneira adequada. 4.1.1.2.2 Diagrama de Casos de Uso
De acordo com Guedes (2009) o diagrama de casos de uso é o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e análise de requisitos do sistema. O diagrama apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar.
Figura 13 - Exemplo Diagrama de Casos de Uso
Fonte: GUEDES (2009, p. 31)
Guedes (2009) menciona que este modelo procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial) que utilizaram de alguma forma o software, bem como os serviços, ou seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas neste diagrama como casos de uso.
4.1.2 Etapas da modelagem
O projeto inicial consiste de uma série de funções Lambda na AWS que serão consumidas por um cliente, cada uma das funções é responsável por uma ou mais ações como: salvar, buscar, editar e excluir. Para definir quantas funções e qual a responsabilidade de cada uma delas foram elencadas as necessidades das operações no banco de dados e as regras de negócio para a aplicação.
estado a modelagem resulta em um total desacoplamento das funcionalidades, garantindo facilidade em manutenções futuras e mudanças nas implementações. 4.2 PROJETO DE SOLUÇÃO
A aplicação web proposta é um sistema de lista de tarefas, e com base nisso foi criado um diagrama de componente, apresentado na figura 12 e um diagrama de casos de uso, apresentado na figura 13. Ambos englobam o contexto da aplicação que foi desenvolvida.
Para a criação da arquitetura primeiro é definido uma API REST criando endpoints personalizados utilizando o Amazon API Gateway, nele é possível mapear métodos individuais para cada requisição HTTPS, como requisições de GET e PUT.
A figura 14 mostra, de maneira detalhada, como a aplicação interage com o API Gateway e demais elementos da arquitetura proposta.
Figura 14 - Proposta de arquitetura detalhada
