Вы находитесь на странице: 1из 17

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

____________________________________________
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
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

2
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

3
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.

4
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.

5
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

6
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

7
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

8
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

9
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

HTTP
Microsserviço

SAPOS 10

Amazon EC2
Fonte: O AUTOR. 2018
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.

11
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

12
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

13
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.

14
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.

15
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.

16
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

17