____________________________________________

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.

Aprovado em: 18/12/2018 Versão Final em: 18/01/2019

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.

Fonte: FOWLER; LEWIS 2014

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

relatórios. A escolha se deu por dois fatores, pela facilidade de comunicação da aplicação

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

Fonte: O AUTOR. 2018

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

microsserviços 12