____________________________________________
Trabalho de conclusão de curso apresentado ao curso de Bacharelado em Sistemas de Informação da Universidade Federal Fluminense como requisito parcial para conclusão do curso.
*Graduando do Curso de Sistemas de Informação-UFF; kadu.jr95@gmail.com
Graduando do Curso de Sistemas de Informação-UFF; felipe14_mendes@hotmail.com
1
Analisando o desempenho de microsserviços implementados através da
decomposição parcial de sistemas monolíticos
Analyzing the performance of microservices developed through the partial
decomposition of monolith systems
Marins, Carlos Jr* Mendes, Luiz** Resumo
Embora a arquitetura monolítica seja comumente empregada no desenvolvimento de aplicações em geral, ela pode gerar complicações quando é necessário escalar parte da aplicação. A arquitetura de microsserviços surgiu como uma alternativa e hoje é vista como método preferido de desenvolvimento quando o assunto é escalabilidade. As vantagens presentes nesta arquitetura fazem com que a migração de aplicações monolíticas para microsserviços, traga melhorias significativas ao software. Entretanto, embora a migração gradual da aplicação seja o caminho ideal, caso não seja considerada uma reestruturação da forma com que os dados são dispostos, a escalabilidade da solução final pode acabar comprometida. Este artigo aplica um método de decomposição parcial de uma aplicação monolítica em microsserviço para então avaliar o desempenho da aplicação em termos de escalabilidade.
Palavras-chave: Microsserviços, Migração, Escalabilidade. Abstract
Although the monolithic architecture is widely used when developing software, its use could also generate performance issues when focusing on scalability. The Microservice Architecture emerged as an alternative to this approach, and nowadays it is seen as a superior architecture when scaling is at stake. Given the advantages of this architecture, migrating from monolithic to the microservice architecture can bring relevant upgrades to an application. However, even though a gradual migration may be the best approach, overlooking the database structure may jeopardize the outcome of the system. This paper uses the partial decomposition of a monolith application into a microservice to analyze its performance in terms of scalability.
Keywords: Microservices, Migration, Scalability.
2 1 INTRODUÇÃO
A arquitetura de microsserviços vem ganhando popularidade e promete mudar a maneira com que aplicações são percebidas, concebidas e desenhadas (Dragoni; Giallorenzo; Lafuente; Mazzara; Montesi; Mustafin; Safina 2017). Porém, eventuais problemas inerentes a essa tecnologia, ainda levantam dúvidas sobre quando seria necessário utilizá-la ao invés do popular padrão monolítico. Um dos maiores desafios está relacionado à criação de um ambiente distribuído, onde desenvolvedores devem lidar com uma maior complexidade quanto à comunicação entre os serviços, realização de testes e estruturação do banco de dados (Richardson, 2018). Para garantir a construção de uma aplicação utilizando a arquitetura de microsserviços é necessário, primeiro avaliar se os requisitos da mesma abrangem esse conceito, e ter certeza de que o esforço adicional em relação a uma aplicação monolítica vale a pena.
Os sistemas monolíticos são conhecidos por terem toda sua base de código contida em um só lugar, sendo assim todas as suas funcionalidades permanecem em um mesmo bloco e os dados que alimentam a aplicação ficam contidos em uma base de dados compartilhada (Figura 1).
Tais características possuem suas vantagens como simplicidade arquitetural, onde você não tem muitas camadas para se preocupar. Existe também a agregação da tecnologia, onde como toda a solução é feita em uma mesma tecnologia, as equipes de software se tornam mais agregadas, gerando um conhecimento uniforme. Adicionalmente, a implantação é mais simples e o desenvolvimento tende a ser mais rápido, devido a simplicidade da arquitetura.
Um dos maiores problemas da arquitetura monolítica é o risco que a aplicação corre caso um processo falhe, deixando toda a aplicação comprometida, além do fato de que adicionar melhorias e novas funcionalidades se torna muito mais complexo à medida que a base de código aumenta (Almeida, 2015). A agregação de tecnologia também pode ser considerada uma desvantagem, pois um problema que poderia ser resolvido facilmente com outra tecnologia existente acaba sendo ignorado (Richardson, 2014).
Microsserviços, por sua vez, são serviços leves e independentes que realizam funções específicas, colaborando com outros serviços similares através de uma interface bem definida (Dmitry, 2014). Essa arquitetura vem ganhando cada vez mais espaço no campo de engenharia de software, principalmente por sua natureza minimalista, tratando problemas inerentes às aplicações monolíticas, que se utilizam de serviços dependentes e com alto acoplamento
3 executados como um único serviço. Com a arquitetura de microsserviços, cada processo da aplicação se torna um componente independente, e eles se comunicam utilizando chamadas HTTP (Figura 1). Esses pequenos serviços apenas realizam uma única função, e como são independentes, eles podem ser desenvolvidos e melhorados, sem afetar a aplicação como um todo.
Suas principais características são autonomia e singularidade. Isso significa que cada serviço pode ser desenvolvido, implantado, operado e dimensionado sem afetar a aplicação como um todo. Além disso, pelo fato de desempenhar uma função específica, caso cresça ele pode ser reparticionado em outros serviços menores.
Pela inerente característica de tamanho compacto, microsserviços são geralmente mantidos por pequenas equipes, que ficam focadas em um contexto pequeno e bem compreendido (Fowler, 2015). Tal método provê mais liberdade para trabalhar de forma independente e rápida, reduzindo significativamente o ciclo de desenvolvimento e aumentando a quantidade de entregas. O fato dos microsserviços serem independentes permite que os mesmos sejam dimensionados de acordo com a demanda atual. Tal benefício permite um melhor direcionamento de recursos de infraestrutura para atender corretamente às necessidades das aplicações.
Figura 1. Modelo de implantação de uma aplicação Monolítica X Microsserviços.
4 Pelas vantagens mencionadas, o desenvolvimento de aplicações utilizando a estrutura de microsserviços atrai tanto os desenvolvedores construindo uma nova aplicação quanto aqueles que já possuem uma aplicação monolítica. Dificuldade para manter, escalar, e delegar responsabilidades a cada time são umas das principais razões que levam desenvolvedores e arquitetos a migrarem suas aplicações. Entretanto, a necessidade de migração e separação dos dados é considerada um dos maiores desafios dos mesmos (Gouigoux, 2017). Alteração da estrutura de dados de uma aplicação é um assunto bastante delicado quando se tratam de aplicações bastante complexas. Resta saber se essa reestruturação dos dados é de fato necessária e qual o seu impacto na aplicação.
Neste contexto, este trabalho propõe a decomposição de um serviço, monolítico para a arquitetura de microsserviços, preservando a modelagem do banco de dados e avaliando sua escalabilidade. O método aplicado é constituído pela decomposição parcial de uma aplicação monolítica de código aberto usado pelo Instituto de Computação para a gestão de bolsas de pós-graduação, o SAPOS. Após a implantação da solução como microsserviço, foram realizados testes de carga a fim de verificar a escalabilidade da aplicação. O restante do artigo está estruturado da seguinte maneira. Na seção 2 são discutidos os principais métodos de decomposição de aplicações monolíticas e suas características. Na seção 3, é explicada a metodologia da migração do SAPOS. Na seção 4, é descrito o SAPOS, Sistema de Apoio à Pós-Graduação. Na seção 5, é abordada a fundo a aplicação desenvolvida, descrevendo sua estrutura, implementação e implantação. Na seção 6 são apresentados os resultados da execução dos testes, assim como uma análise dos dados coletados. Por fim, na seção 7 é descrita a conclusão do trabalho, bem como sugestões para trabalhos futuros.
2 DECOMPOSIÇÃO
Quanto à implementação, a adoção de microsserviços na criação de aplicações encontra várias resistências. Uma delas é a pré-existência de uma aplicação monolítica, fazendo com que a necessidade de migração torne a situação ainda mais complexa (Ganzha; Maciaszek; Paprzycki 2018). Para se decompor uma aplicação monolítica em microsserviços, é preciso primeiro definir quais funcionalidades serão separadas e quais serão mantidas. Após a definição, é escolhido dois dos principais modelos de decomposição para essas aplicações: decomposição por negócio e decomposição por subdomínio.
5 Richardson (2016) define a decomposição por negócio como a separação da aplicação pelas funcionalidades que a mesma precisa gerar valor. Depois de definidos os componentes essenciais para cada parte da aplicação, estes são então transformados em microsserviços. Já na aplicação por subdomínio, a aplicação é dividida de acordo com sua parte do negócio, são elas: Núcleo, Suporte e Genérico. O Núcleo do negócio envolve as partes da aplicação essenciais para seu funcionamento e geração de valor; Suporte refere-se a funcionalidades que embora sejam relevantes para o negócio, não geram valor diretamente, podendo inclusive ser realizado por terceiros; por último, Genérico é o domínio que contém partes que não são especificas do negócio.
O popular conceito de um banco de dados relacional com estruturas que se comunicam localmente, presente principalmente na estrutura monolítica, pode apresentar problemas quando o foco é construir uma aplicação com a estrutura de microsserviços. Fowler (2015) discute o possível problema de escalabilidade horizontal que essa estrutura propõe. A escalabilidade horizontal faz parte do modelo chamado Scale Cube, que basicamente divide a decomposição de um sistema em 3 partes: Decomposição Funcional, Decomposição Horizontal e Particionamento de Dados. A Decomposição Funcional trata da decomposição do código por diferentes funções, sendo a estrutura de microsserviço um exemplo de decomposição funcional. Na Decomposição horizontal, a decomposição é obtida através da replicação da aplicação em partes idênticas, com um balanceador de carga responsável por dividir as requisições. No Particionamento dos Dados, a escalabilidade é obtida através da separação dos dados da aplicação, e alocação de recursos conforme a necessidade.
No que se trata da decomposição parcial, a questão é que ao utilizar a separação funcional do sistema baseado, como ficaria estruturado o banco de dados? Richardson (2018) defende a estrutura Database per Service, onde cada serviço é responsável por seu próprio banco de dados. Neste caso, decompor uma aplicação funcional implicaria que os dados também devem ser particionados, pois a parte funcional decomposta deverá levar com ela os dados pelo qual ela é responsável.
A metodologia proposta neste artigo procura justamente analisar a escalabilidade da aplicação mantendo a modelagem do banco de dados. Ao decompor o banco de dados para que a decomposição funcional respeite o conceito de Database per Service, é natural pensar na simples repartição do banco de dados. Porém, resta saber se este método se mostra eficiente e escalável após a migração da aplicação.
6 3 METODOLOGIA
A metodologia deste artigo consiste em realizar a decomposição parcial de uma aplicação monolítica para microsserviços, a fim de testar a aplicação em termos de escalabilidade. Com a intenção de atingir o objetivo proposto, este trabalho adota uma metodologia de estudo de caso analítico, buscando explorar o tema discutido através da decomposição de parte de um sistema para a arquitetura de microsserviços e sua implantação na nuvem. Para isto, foram utilizados: a plataforma de computação em nuvem da Amazon, AWS (Amazon Web Services) para implantação do sistema; a ferramenta JMeter para gerar e avaliar cargas de teste na aplicação desenvolvida; o framework Ruby on Rails, desenvolvido na linguagem de programação Ruby, para o desenvolvimento do microsserviço; e o banco de dados relacional MYSQL como responsável por gerir os dados contidos na aplicação. Neste artigo, o sistema alvo dessa decomposição será o SAPOS, Sistema de Apoio à Pós-Graduação.
Para a construção do microsserviço a ser migrado, optamos por realizar o método de decomposição por negócio, devido a clara facilidade de dividir o SAPOS em partes de acordo com o valor que precisa ser entregue.
É relevante notar que todas as ferramentas de desenvolvimento, inclusive o código fonte da aplicação são open-source, ou seja, é possível não apenas utilizá-las sem custo, mas também ajudar no seu desenvolvimento. Importante notar também que embora o Amazon Web Services seja um serviço privado da Amazon, os recursos utilizados para a implantação e realização de testes foram livres de custo, o que significa que qualquer pessoa pode replicar o trabalho realizado sem qualquer custo econômico.
4 SOBRE O SAPOS
É muito comum observar na Universidade Federal Fluminense uma diversidade de sistemas de gerenciamento de dados dos alunos, professores e bolsas, causando certa dúvida na comunidade acadêmica para a identificação da utilidade do mesmo. Nos cursos de Pós-Graduação, a situação era ainda mais descentralizada, pois tais serviços ficavam a cargo das coordenações de curso. A duplicidade de informações e inconsistência de dados eram os principais problemas, sem levar em consideração o fato de que os sistemas
7 disponíveis não atendiam as necessidades dos principais interessados, que eram os responsáveis pela administração dos Portais, sendo assim muitas informações ainda eram administradas em planilhas e diversos documentos.
Como uma solução para esse problema foi desenvolvido o SAPOS (Sistemas de Apoio à Pós-Graduação), que possibilitou cobrir esses vazios, melhorar a gestão das informações presentes nos sistemas legados e adicionar melhorias que possibilitem agilizar processos e diminuir a quantidade de informações duplicadas.
Para a construção do SAPOS foi utilizado o Framework Ruby on Rails, principalmente por sua escalabilidade, implementação e fácil manutenção por futuros desenvolvedores (Ferreira; Amaro 2013). O SAPOS usa o banco de dados MYSQL para persistência de dados, e o sistema foi construído completamente de forma monolítica.
Figura 2. Arquitetura do Ruby on Rails
Fonte: FERREIRA; AMARO 2013
A área de Alunos é a mais importante de do sistema, pois nela se concentram as informações sobre os discentes, logo foi escolhida como tela inicial após o Login. Nela temos 6 subdivisões que as compõe, são elas: Alunos, onde temos as descrições e informações mais relevantes dos discentes; Matrículas, responsável pelo relacionamento de um aluno e a um nível de curso e possui as informações necessárias entre o aluno e o curso; Níveis, seção
8 responsável pelo nível do curso; Tipos de Matrícula, onde estão cadastradas as possíveis ligações que uma matrícula tem ao curso (e.g., avulso ou regular); Razões de Desligamento, onde é possível selecionar umas das opções de desligamento de uma matrícula; e Desligamentos, que a seção que refere-se às matrículas que foram desligadas do curso.
Outras áreas importantes do sistema são: Professores, que contempla as informações básicas dos professores e suas relações com os alunos; Bolsas, que é a seção que contém as informações essenciais sobre o gerenciamento das bolsas de fomento, e também é responsável por relacionar um aluno a uma bolsa pela sua matrícula; Etapas, área designada ao gerenciamento das informações de titulação dos alunos, como: prova de inglês, pedido de banca, entre outras; Formação, onde é cadastrado as Instituições de Ensino, afim de mitigar possíveis erros de duplicidade de dados; Localidades, onde está todo registro de países, estados e cidades, com a mesma finalidade da área anterior; e por fim as Configurações, onde os administradores do sistemas, podem configurar os acessos ao sistema, adição e exclusão de usuários e também alterações de nome e senha.
5 APLICAÇÃO DESENVOLVIDA
5.1 Funcionalidade decomposta
A funcionalidade decomposta foi a parte responsável pela geração de relatórios na interface. Basicamente, a geração de relatórios gera valor à aplicação através de quatro partes: Realização de consulta, Construção de template, Inserção de imagens e Entrega do relatório.
A realização de consulta é a parte responsável por obter os dados desejados pelo usuário. Nesta parte, o usuário é responsável por criar uma consulta SQL que vai obter dados das tabelas do sistema. É importante notar que, devido ao alto privilégio que a tarefa garante, apenas os administradores do SAPOS são autorizados a criar consultas.
Na segunda parte, o resultado da consulta é enviado para um template HTML, onde o código HTML do template é combinado com o resultado da consulta, gerando uma página. O template é construído usando a ferramenta Handlebars.
Após a construção do template, a página é então populada com imagens definidas pelo usuário. As imagens já se encontram guardadas no SAPOS, na interface
9 responsável pelas imagens de relatórios. Nela o usuário pode gerenciar imagens guardadas no SAPOS, assim como criar novas imagens.
Por último, a página é transformada em um relatório PDF e enviada ao usuário.
Figura 3. Estrutura da geração de relatórios.
Fonte: O AUTOR. 2018
A estrutura da geração de relatório pode ser observada na Figura 3. Como estas etapas são essenciais para a criação de relatórios do SAPOS, toda a funcionalidade responsável por elas foi decomposta em um único microsserviço.
5.2 Implementação
Apesar da possibilidade de criar o microsserviço com qualquer tecnologia - devido ao fator da independência entre os serviços -, decidimos por usar o mesmo
Framework, Ruby on Rails, para a construção do microsserviço responsável pela geração de
10 utilizando o Framework, já que a prioridade deste artigo é o desempenho e pela rápida curva de aprendizado que a linguagem nos oferece.
A comunicação entre a aplicação principal (monolítica) e o microsserviço se deu exclusivamente através de chamadas HTTP. O microsserviço permite apenas o gerenciamento dos objetos contidos e a geração do relatório utilizando exclusivamente seus recursos.
Para a decomposição do banco de dados, os modelos pertencentes à interface de relatórios - Imagens, Templates e Consultas - foram migrados junto com a aplicação. Tal medida foi tomada para evitar problemas advindos do modelo de banco de dados compartilhados, como interferência de um serviço nos dados de outro (Richardson, 2016). É importante notar que, embora essa medida tenha mudado a estrutura física do banco de dados, a modelagem do banco continuou intacta. O banco de dados a ser usado pelo microsserviço foi implementado no MYSQL. Para reduzir problemas de latência nos testes de carga devido à conexão, o banco de dados foi implementado na mesma rede local em que as instâncias do microsserviço foram implantadas.
5.3 Implantação
Após implementado, o sistema foi implantado no Amazon AWS (Amazon Web Services), contando assim com uma infraestrutura robusta capaz de suportar os múltiplos testes de carga realizados. Além disto, outro ponto crucial foi a estrutura da Amazon AWS, propícia para a rápida implantação e replicação de microsserviços. As máquinas utilizadas foram do tipo t2.micro, com 1GB de memória RAM e 10GB de espaço em disco.
O banco de dados foi instalado em uma máquina virtual no ambiente da Amazon, o Amazon EC2. A Figura 4 ilustra a arquitetura do sistema depois da implantação.
Figura 4. Arquitetura da solução implantada no AWS
Amazon EC2
Microsserviço
HTTP
SAPOS
11 6 RESULTADO
6.1 Testes
Para a realização de testes de performance da interface, foram aplicados conjuntos de testes de carga formados por requisições assíncronas através da ferramenta JMeter, realizados através de uma máquina local. O Apache JMeter é um projeto Apache que pode ser usado como uma ferramenta de teste de carga para analisar e medir o desempenho de uma variedade de serviços, com foco em aplicativos da web.
Os testes de carga foram divididos em três tipos de chamadas HTTP: GET, CREATE e DELETE. Chamadas GET são responsáveis por ler os dados contidos na plataforma. Pela sua simplicidade, espera-se que este tipo de chama obtenha o menor tempo de requisição entre as 3. Chamadas CREATE são responsáveis por criar novos registros na plataforma, enquanto chamadas DELETE são responsáveis por excluir registros na plataforma. Pela necessidade de alteração no banco de dados, espera-se que as chamadas do tipo CREATE e DELETE obtenham um tempo de resposta maior em relação a chamadas do tipo GET. As chamadas foram divididas igualmente entre os 3 controladores da interface: Consulta SQL, Template e Imagens.
Para a realização do teste, foram realizadas 100 chamadas de cada tipo para a interface de microsserviço do SAPOS, implantada no Amazon AWS, somando um total de 300 requisições enviadas em um período de 5 segundos. Com a finalidade de analisar e comparar o efeito de múltiplos serviços acessando o mesmo banco de dados, disponibilizamos uma, duas, e enfim quatro instâncias do microsserviço para atender as requisições e comparar o tempo de resposta. As chamadas foram manualmente balanceadas para proporcionar um número igual de chamadas por instância.
12 Figura 5. Tempo de resposta por chamada (em milissegundos) X # de instâncias de microsserviços
Fonte: O AUTOR. 2018
6.2 Avaliação
Como podemos analisar na Figura 5, ao usar duas instâncias ao invés da uma para tratar as requisições, houve uma melhora significativa no tempo de resposta. Fica claro que o uso de mais uma instância neste caso ajuda a tratar mais requisições em um menor período de tempo, reduzindo a latência das requisições. Porém, ao aumentar o número de instâncias para 4, percebemos que já não houve ganho significativo no tempo de resposta, na maioria dos casos. O principal quesito que leva a essa estabilidade no tempo de resposta é o banco de dados, maior responsável pela latência das requisições, como podemos notar no maior tempo de resposta para as chamadas GET e DELETE.
Analisando as chamadas do tipo GET, nota-se principalmente que seu tempo de resposta foi pouco superior ao tempo das outras chamadas. Analisando o modelo de dados, contido na Figura 5, pode-se inferir que a relação do template com todos os outros modelos do banco faz com que o tempo de leitura do banco aumente nessas requisições, já que qualquer alteração no banco de dados irá afetar a leitura. Já as chamadas do tipo CREATE apresentaram melhoras em ambas as transições, para 2 e depois 4 instâncias. Este resultado intrigante sugere que o banco possa ser capaz de suportar uma carga maior em relação à criação de dados, porém os outros resultados não sugerem o mesmo. Por fim, as chamadas do
13 tipo DELETE apresentaram resultado melhor do que o esperado, porém o aumento do tempo de resposta ao aumentar o número de instâncias ativas, similar ao comportamento das chamadas GET, evidencia o problema que surge quando múltiplas instâncias acessam o mesmo banco relacional simultaneamente.
Como discutimos anteriormente, a estruturação no banco de dados precisa ser levada em mente na questão de decomposição de aplicações monolíticas em microsserviços. No caso do SAPOS, a simples decomposição parcial do banco de dados mostrou não ser suficiente para que a aplicação como um todo pudesse ser escalada através da criação de múltiplos serviços. Uma reestruturação do modelo de dados parece ser necessária. Bancos de dados não relacionais podem ser uma eventual solução para tal problema, mas esta arquitetura também pode trazer alguns novos desafios junto com seus benefícios. Ao final, é uma questão de avaliar se vale a pena enfrentar os desafios dessa tecnologia para aproveitar os benefícios.
7 CONCLUSÃO
Como pudemos observar neste estudo, a decomposição parcial de sistemas monolíticos em microsserviços traz consigo uma série de dúvidas e benefícios. Embora haja uma complexidade adicional que pode ser percebida desde o início do desenvolvimento, a escolha por migrar o serviço mantendo o framework Ruby on Rails, proporcionou agilidade na construção da solução, que serviu de base para o estudo.
Mostra-se que para uma decomposição completa, é necessário ter certeza que ambos os tipos de decomposição explicados por Fowler (2015) possam ser aplicados ao fim da aplicação: Decomposição por funcionalidade, Decomposição horizontal, e Particionamento dos Dados. Embora a Decomposição por funcionalidade tenha sido aplicada com sucesso no SAPOS – o que permitiu um maior desempenho inicial ao aumentar o número de instâncias -, a falta de uma reestruturação do banco de dados fez que o mesmo aparentemente se tornasse um gargalo na hora de escalar o serviço.
Ao fim deste trabalho, foi possível concluir a importância do modelo de dados para o desempenho e escalabilidade de aplicações na arquitetura de microsserviços. Apesar da implementação do microsserviço ter sido feita com sucesso, a falta de reestruturação do banco de dados acabou comprometendo a escalabilidade da solução como um todo.
A respeito de trabalhos futuros relacionados a este tema, sugere-se abordar metodologias para a decomposição do banco de dados de aplicações monolíticas em uma
14 estrutura capaz de ser facilmente escalada na arquitetura de microsserviços. A partir deste caminho, pode se procurar respostas a questões como a existência de um método ideal para a decomposição sistemas monolíticos em microsserviços. Outra alternativa também seria abordar o método de decomposição por subdomínio, analisando a performance deste método e se os mesmos problemas da decomposição por funcionalidade. Nesses trabalhos, banco de dados não relacionais podem ser usados e comparados com o tradicional modelo de dados relacional.
Outra sugestão de trabalho futuro seria a aplicação dos testes em uma estrutura mais robusta, onde seja possível instanciar um maior número de instâncias para os microsserviços. Como observamos, as requisições do tipo CREATE apresentaram um padrão diferente do esperado em relação ao banco de dados como gargalo. Em um ambiente com um número saturado de instâncias, restam poucas dúvidas de que nenhuma requisição apresentaria melhoria de desempenho com a criação de novas instâncias. Por levar em consideração os custos adicionais relacionados à criação de tal estrutura, assim como a possibilidade da criação de um ambiente sem custo para qualquer pessoa interessada, optamos por manter um número saudável de instâncias, considerando que os resultados obtidos apontaram na direção esperada.
15 REFERÊNCIAS
ABBOTT, Martin; FISHER, Michael. The art of scalability: Scalable web architecture,
processes, and organizations for the modern enterprise. Pearson Education, 2009. ALMEIDA, Adriano. Arquitetura de microsserviços ou monolítica? Disponível em: <http://blog.caelum.com.br/arquitetura-de-microservicos-ou-monolitica/>. Acessado em: 16 ago. 2018, 19:15:00.
CAMARGO, A. S. de. Uma abordagem para testes de desempenho de microservices. Disponível em:
<https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/176664/346332.pdf?sequence =1&isAllowed=y>. Acessado em: 12 nov. 2018, 14:20:00.
COMUNIDADE RUBY ON RAILS. Disponível em: <https://rubyonrails.org/>. Acessado em: Acessado em: 27 jun. 2018, 11:45:00.
DMITRY, Namiot; MANFRED, Sneps-Sneppe. On micro-services
architecture. International Journal of Open Information Technologies, International Journal of Open Information Technologies, 2014.
DRAGONI, Nicola; GIALLORENZO, Saverio; LAFUENTE, Alberto; MAZZARA, Manuel; MONTESI, Fabrizio; MUSTAFIN, Ruslan; SAFINA, Larisa. Microservices: yesterday, today, and tomorrow. Present and Ulterior Software Engineering (pp. 195-216). Springer, Cham, 2017.
FERREIRA, Rodrigo De; AMARO, Tiago. SAPOS – Sistema de Apoio à Pós-graduação. Instituto de Ciência da Computação. Universidade Federal Fluminense. Disponível em: < https://github.com/gems-uff/sapos>. Acessado em: 20 jan. 2018, 14:40:00.
FOWLER, Martin. Microservices, a definition of this new architectural term. Mars, 2014. FOWLER, Martin; LEWIS, James. Microservices. Disponível em:
<http://martinfowler.com/articles/microservices.html>. Acessado em: 11 out. 2018, 17:19:00.
GANZHA, Maria; LESZEK, Maciaszek; MARCIN, Paprzycki. Proceedings of the 2018
Federated Conference on Computer Science and Information Systems. In Federated Conference on Computer Science and Information Systems (No. 15). Warszawa; New York City, 2018.
GOUIGOUX, Jean-Philippe; TAMZALIT, Dalila. From monolith to Microservices: Lessons learned on an industrial migration to a web oriented architecture. In Software Architecture Workshops (ICSAW), 2017.
MARINS, Carlos; MENDES, Luiz. Repositório da API no GitHub. Disponível em: <https://github.com/kadu-rj/apisapos >. Acessado em: 12 dez. 2018, 14:00:00.
16 RICHARDSON, Chris. Introduction to Microservices. Disponível em:
<https://www.nginx.com/blog/introduction-to-microservices/>. Acessado em: 11 dez. 2018, 14:05:00.
RICHARDSON, Chris. Microservice architecture patterns and best practices. Disponível em: <http://microservices.io/index.Html>. Acessado em: 11 nov. 2018, 18:30:00.
17
APÊNDICE A – Lista de Figuras
Figura 1. Modelo de implantação de uma aplicação Monolítica X Microsserviços. 3
Figura 2. Arquitetura do Ruby on Rails 7
Figura 3. Estrutura da geração de relatórios. 9
Figura 4. Arquitetura da solução implantada no AWS 10 Figura 5. Tempo de resposta por chamada (em milissegundos) X # de instâncias de
