You are on page 1of 47

1

Universidade Federal de Pernambuco

Centro de Informática

Graduação em Ciência da Computação

THIAGO AQUINO DOS SANTOS

UM ESTUDO DO STACKOVERFLOW SOBRE PERGUNTAS E SOLUÇÕES


SOBRE MICROSSERVIÇOS

Recife,
2019
2

THIAGO AQUINO DOS SANTOS

UM ESTUDO DO STACKOVERFLOW SOBRE PERGUNTAS E SOLUÇÕES


SOBRE MICROSSERVIÇOS

Trabalho de conclusão de curso apresentado ao Centro de


Informática da Universidade Federal de Pernambuco,
como parte dos requisitos necessários a obtenção do título
de Bacharel em Ciência da Computação.

Orientador: Vinicius Cardoso Garcia

Recife,
2019
3

RESUMO

Com o avanço da tecnologia, a maneira de desenvolver software tem se tornado complexa e


multidisciplinar. Utilizar arquitetura monolítica como padrão de desenvolvimento corporativo
é uma abordagem comum, entretanto, esta arquitetura gera algumas complicações quando
utilizada para grandes aplicações, apresentando limitações em escala e ainda mais quando se
há necessidade de iterações e entregas frequentes. Com isso, a arquitetura de microsserviços
aparece como uma via alternativa para a construção de aplicações complexas e de demandas
que exigem flexibilidade e velocidade. O termo microsserviços é recente, mas o conceito já
existe há mais de dez anos. Apesar de não ser simples, é possível migrar de uma arquitetura
monolítica para a arquitetura de microsserviços, como têm feito algumas empresas como a
Netflix e Uber e outras, como Walmart, para revitalizar a sua presença online. Esta forma de
mudança se dá através da migração entre arquiteturas sem perder os dados existentes.- Este
trabalho de conclusão de curso tem como objetivo analisar dados do StackOverflow a fim de
identificar os principais desafios referente a microsserviços apontados e discutidos pela
comunidade de desenvolvedores de software, identificando potenciais soluções para esses
desafios. Para isso utilizamos uma metodologia baseada no mapeamento. Através dela
detectamos que os principais desafios são segurança, arquitetura, migração.

Palavras-chaves: Survey, Microsserviço, Arquitetura de Software, Stackoverflow.


4

ABSTRACT

With the advancement of technology, the way to develop software has become complex and
multidisciplinary. A common approach inside enterprises is to use a monolithic architecture as
the way of development, however, this architecture may lead to some complications when
used for large applications presenting scale limitations, mainly, when frequent iterations and
deliveries are required. Furthermore, the micro-service architecture appears as an alternative
route for the construction of complex applications and demands that require flexibility and
speed. Despite the fact that the term micro-services is recent, the concept exists for more than
ten years. One way to do it is by migrating between architectures and guaranteeing that no
existing data is lost. This course completion work aims to analyze data from the
StackOverflow website in order to identify the main challenges related to micro-services that
were pointed out and discussed by the software developer community and identifying
potential solutions to these challenges. For this purpose a mapping methodology was used,
and the main challenges detected until now were security, architecture design, migration.

Key words: Survey, Microservice; Software Architecture; StackOverflow.


5

Dedico este trabalho a minha mãe,


pois sem ela não conseguiria chegar até aqui.
6

AGRADECIMENTOS

Agradeço a aquela que é a expressão de Deus em minha vida, minha mãe. Agradeço por todo
o apoio e suporte que recebi desde os meus primeiros passos até a conclusão da minha
graduação.

Agradeço ao professor Vinicius Cardoso Garcia pela orientação e pelo acompanhamento. Seu
suporte foi fundamental para a conclusão deste trabalho.

Agradeço aos meus colegas de turma, “2012.3”, que compartilharam as lutas e as vitórias
durante todos estes anos. Por todo apoio, todo incentivo e por sempre acreditar e me
incentivar a enfrentar todas as adversidades.

Agradeço aos meus amigos, colegas, por todo suporte que me foi dado. Não poderia esquecer
aqueles que me atrapalharam e aos que disseram que eu nunca iria conseguir. Muito obrigado
por essas palavras, pois elas só fortaleceram a minha força de vontade e minha determinação.

Por fim, agradeço à UFPE, ao CIn, e a todos aqueles que contribuíram direta ou indiretamente
para a minha formação.
7

“Alguns homens vêm as coisas como são, e dizem


„Por quê?‟ Eu sonho com as coisas que nunca foram
e digo „Por que não?'”

George Bernard Shaw


8

LISTA DE SIGLAS

ACL Audit Command Language


API Application Programming Interface
ARPA Advanced Research Project Agency
ARPANET Advanced Research Projects Agency Network
CGI Common Gateway Interface
CORS Cross Origin Resource Sharing
DMZ Demilitarized Zone
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
IoT Internet das Coisas
IPTO Information Processing Techniques Office
JDBC Java Database Connectivity
JWT Json Web Token
MVC Model View Controller
MS Microsserviços
PUB / SUB Publish / Subscribe
RPC Remote Procedure Call
SOA Aplicação Orientada para Serviços
UI User Interface
XACML eXtensible Access Control Markup Language
XML eXtensible Markup Language
9

LISTA DE TABELAS

Tabela 1 - Resultados do quesito motivação ............................................................................ 24


Tabela 2 - Problemas de migração identificados pela pesquisa ............................................... 25
Tabela 3 - Lista dos Critérios de Exclusão ............................................................................... 30
Tabela 4 - Perguntas relacionadas à segurança ........................................................................ 34
Tabela 5 - Perguntas relacionadas a aplicação ......................................................................... 35
Tabela 6 - Perguntas relacionadas a arquitetura ....................................................................... 35
Tabela 7 - Perguntas relacionadas ao banco de dados .............................................................. 37
Tabela 8 - Perguntas relacionadas a migração.......................................................................... 39
Tabela 9 - Perguntas relacionadas à Spring .............................................................................. 40
10

LISTA DE QUADROS

Quadro 1 - Objetivo da Pesquisa .............................................................................................. 31


Quadro 2 - Questões ................................................................................................................. 32
Quadro 3 - Métricas .................................................................................................................. 32
11

LISTA DE FIGURAS

Figura 1 - Linha do tempo das tecnologias de microsserviços ................................................. 17


Figura 2 - Comparação entre arquitetura monolítica e de microsserviços ............................... 20
Figura 3 - Estrutura dos processos de migração identificados ................................................. 26
Figura 4 - Comando de seleção dos dados ............................................................................... 30
Figura 5 - Diagrama das Métricas GQM .................................................................................. 32
12

SUMÁRIO

1 INTRODUÇÃO .............................................................................................................. 13

1.1 OBJETIVOS .............................................................................................................. 14


1.2 ORGANIZAÇÃO DO TEXTO ................................................................................. 15
2 FUNDAMENTAÇÃO TEÓRICA ................................................................................. 15

2.1 ARQUITETURA MONOLÍTICA ............................................................................. 15


2.2 ARQUITETURA MICROSSERVIÇOS ................................................................... 16
2.3 COMPARAÇÃO ENTRE MONOLÍTICO E MICROSSERVIÇOS ........................ 19
2.4 VANTAGENS E DESVANTAGENS DOS MICROSSERVIÇOS .......................... 21
2.5 OS DESAFIOS DOS MICROSSERVIÇOS .............................................................. 22
2.6 POR QUE MIGRAR DA ARQUITETURA MONOLÍTICA PARA
MICROSSERVIÇOS? .......................................................................................................... 22
2.7 HISTÓRIA DO STACKOVERFLOW ...................................................................... 27
2.8 RESUMO ................................................................................................................... 28
3 METODOLOGIA........................................................................................................... 28

3.1 CLASSIFICAÇÃO DA PESQUISA ......................................................................... 28


3.2 SOBRE STACKOVERFLOW .................................................................................. 29
3.3 EXECUÇÃO DA PESQUISA ................................................................................... 29
3.4 RESUMO ................................................................................................................... 31
4 RESULTADOS ............................................................................................................... 31

4.1 QUADROS DO GQM ............................................................................................... 31


4.2 DESAFIOS ................................................................................................................ 33
4.3 DISCUSSÃO DOS RESULTADOS ......................................................................... 41
4.4 RESUMO ................................................................................................................... 42
5 CONSIDERAÇÕES FINAIS ......................................................................................... 43

5.1 TRABALHOS FUTUROS ........................................................................................ 43


5.2 CONCLUSÃO ........................................................................................................... 43
6 REFERENCIAS ............................................................................................................. 45
13

1 INTRODUÇÃO

Microsserviços é uma arquitetura cujos serviços podem ser implantados, escalonados e


testados de maneira independente (THÖMES, 2015). Desde que surgiu em meados de 2011
(MACHADO, 2017), por falta de uma definição oficial, microsserviços tem sido
frequentemente comparado a construção monolítica para melhor entendimento, e tem ganhado
destaque no mercado de desenvolvimento de softwares além de ser discutida em sites de
perguntas e respostas, blogs, artigos e conferências (MACHADO, 2017).
A arquitetura de microsserviços é uma aplicação distribuída em que todos os seus
módulos são serviços e seu reuso não só é permitido como também incentivado. Esses
módulos são conectados uns aos outros por meio de uma interface de rede, utilizam apenas
tecnologias leves, podem ser construídos com tecnologias completamente distintas (i.e.
linguagens de programação, frameworks, bancos de dados, etc.) e são operadas de maneira
independente (MARTIN e FOWLER, 2015).
Esta arquitetura é adequada para atender a um mercado cada vez mais competitivo e as
empresas com um crescimento na oferta de serviços e na quantidade de clientes, em busca de
agilidade e flexibilidade na mudança e/ou acréscimo de serviços. Na busca para conseguir
atender todos os clientes e continuarem competitivas, as empresas de tecnologia de
informação têm começado a usar microsserviços, se apoiando nos seus benefícios para
atender a esta demanda de forma rápida, sem falhas e com o mínimo de problemas possíveis.
A arquitetura orientada a microsserviços surgiu com o propósito de aprimorar a
implantação (deploy), velocidade dentro dos processos, os testes, a velocidade de inovação, a
escalabilidade, gestão de equipes de desenvolvimento, entre outros vindos da arquitetura
monolítica. Microsserviços possui benefícios significativos possibilitando um
desenvolvimento mais ágil, facilidades na implantação, permite o uso de múltiplas tecnologias
simultâneas e melhor adepta a computação em nuvem (LUCIO, 2017).
Microsserviços apresenta um contraste à estrutura monolítica em virtude de alguns dos
seus benefícios como agilidade de desenvolvimento, facilidade de implantação, organização
com múltiplas tecnologias e maior recurso para aplicações em nuvem (NAMIOT et al, 2014).
Algumas das principais características de microsserviços incluem flexibilidade, já que o
sistema é capaz de acomodar mudanças no ambiente de negócios e é capaz de dar suporte a
todas as modificações necessárias para que a organização mantenha sua posição competitiva
no mercado; modularidade, pois o sistema é composto de componentes isolados onde cada
componente contribui para o comportamento geral do sistema, em vez de ter um único
14

componente que oferece toda a funcionalidade; e evolução, pela sua capacidade de


manutenabilidade apesar de evoluindo constantemente e acrescentando novas características.
Apesar desses benefícios e popularidade, já adotados por muitas empresas -
notadamente Netflix, Nubank e SoundCloud, (TAIBI et al, 2017) entre outras -
microsserviços apresenta também um número de desafios que têm sido discutidos lado a lado
com os seus vários benefícios. Com o objetivo de entender os desafios e as potenciais
soluções sobre a arquitetura de microsserviços, analisamos postagens publicadas no
StackOverflow1. Este site, exclusivamente para perguntas e respostas de desenvolvedores
objetiva a aprendizagem e compartilhamento de conhecimentos. Dados do próprio site
indicam visitas de mais de 50 milhões de visitantes únicos todos os meses, sejam
desenvolvedores de software, stackeholders ou até mesmo pessoas procurando emprego.2
A motivação desse estudo está relacionada à importância de identificar os problemas
mais relevantes enfrentados por desenvolvedores em seus projetos e atividades profissionais
no contexto de microsserviços, e servir como um arcabouço de conhecimento concreto sobre
as maiores dificuldades dos desenvolvedores e/ou stakeholders, em relação a este novo estilo
arquitetural.

1.1 OBJETIVOS

Objetivo Geral
Este trabalho tem como objetivo entender quais são os desafios e as potenciais
soluções sobre a arquitetura de microsserviços por meio de um estudo aplicado em uma base
de dados colaborativa e comunitária utilizada majoritariamente por desenvolvedores de
software e/ou stakeholders envolvidos no domínio do assunto em questão.

Objetivos Específicos
 Identificar os principais desafios no uso de microsserviços
 Descrever as potenciais soluções adotadas para os desafios encontrados

1
www,stackoverflow.com/
2
https://stackoverflow.com/company acessado dia 21/06/2019.
15

1.2 ORGANIZAÇÃO DO TEXTO

Este trabalho está dividido em cinco capítulos, além da introdução. O capítulo 2


apresenta a fundamentação teórica onde apresenta a arquitetura monolítica, a arquitetura de
microsserviços, discute sobre microsserviços, a sua arquitetura, benefícios e desafio,
apresenta uma comparação entre as arquiteturas, suas vantagens e desvantagens; inclui ainda
os resultados de uma pesquisa realizada entre profissionais de TI sobre os seus problemas de
migração. O capítulo 3 conta um pouco sobre o StackOverflow e a metodologia utilizada. O
capítulo 4 apresenta o mapeamento realizado em uma base de dados colaborativa e
comunitária utilizada majoritariamente por desenvolvedores de software e/ou stakeholders
envolvidos no domínio do assunto em questão para entender quais são os desafios e as
potenciais soluções no uso e na migração para uma arquitetura de microsserviços. Por fim, no
capítulo 5 é apresentada a conclusão e a sugestão para os trabalhos futuros.

2 FUNDAMENTAÇÃO TEÓRICA

A fim de contornar os problemas gerados pelas aplicações monolíticas, desenvolvedores


construíam sistemas distribuídos, pois dessa forma era possível ter mais recursos
computacionais, visto que o sistema estava sendo executado em várias máquinas, podendo
estas serem locais ou remotas (BROWN, 2016). Este tipo de implementação apresentou
vários problemas, dentre eles a separação de métodos de uma variável, abrindo oportunidades
para correções (BROWN, 2016). Já no início da década de 90, tais correções geraram uma
nova forma de desenvolver sistemas, que foi uma arquitetura orientada a serviços – SOA, mas
devido às dificuldades técnicas apresentadas por essa arquitetura, acabou não sendo tão bem
aceita (BROWN, 2016). No início dos anos 2000 os microsserviços surgiram e, apesar de não
ser um conceito novo, os fatores tecnológicos proporcionaram a sua pronta aceitação
(BROWN, 2016; BALALAIE et al, 2015)

2.1 ARQUITETURA MONOLÍTICA

É uma arquitetura bastante utilizada devido à simplicidade de desenvolvimento, de teste


e de implantação, tudo pode ser feito com poucos passos, funciona bem para sistemas de
pequeno e médio porte (AMARAL et al, 2017). A aplicação construída nessa arquitetura é
responsável por todos os processos. Desde a sua interação com o usuário, até o acesso aos
16

dados no banco de dados. Ou seja, a aplicação é autossuficiente e independente de outras


aplicações.
Para Rodrigues (2017), a arquitetura monolítica tem as suas vantagens, como a
facilidade de implantação, pois toda a aplicação está escrita em um ou em poucos arquivos, a
simplicidade no desenvolvimento visto que muitas ferramentas utilizadas foram criadas com
arquitetura monolítica, e simplicidade para escalonar, porque basta criar várias cópias da
mesma aplicação e gerencia-las com o auxílio de um balanceador de cargas. Entre as
desvantagens estão à dificuldade em entender e modificar na medida em que a aplicação
cresce e, quando isso acontece, há a dificuldade com pessoal, no acréscimo de novas pessoas
ou substituição daquelas que estão saindo do projeto.
Outras desvantagens incluem o tamanho da codificação, que torna a produtividade mais
lenta. A qualidade cai e a modularidade original é afetada. Além disso, como os
desenvolvedores não trabalham de maneira independente, toda a equipe deve estar alinhada,
coordenando todos os esforços de desenvolvimento e de uma nova implantação (NAMIOT et
al, 2014).
A lista de desvantagens da arquitetura monolítica não para por aí. O desenvolvimento
contínuo é difícil e há obstáculos para a atualização constante porque para atualizar um
componente pequeno, é necessário reimplantar toda a aplicação. O escalonamento da
aplicação pode ser difícil também, pois uma arquitetura monolítica somente pode ser
escalonada em uma dimensão. Outra desvantagem está na pilha tecnológica que, na
arquitetura monolítica, é considerada impossível de mudar; é difícil adotar incrementalmente
uma nova tecnologia já que todos os componentes na aplicação devem ser aquela selecionada
no início do desenvolvimento (NAMIOT et al, 2014).
Apesar de todas as desvantagens citadas sobre a arquitetura monolítica, essa ainda é
bastante utilizada e em relação a outras arquiteturas, por exemplo, o microsserviço, a
construção de um monolíto pode ser feito de forma mais ágil e pode ter uma grande vantagem
em termos de processamento (LUCIO, 2017).

2.2 ARQUITETURA MICROSSERVIÇOS

Microsserviço é um novo estilo arquitetural e que visa construir software como


serviços. Este termo, que vem da palavra em inglês microservices, surgiu em uma conferência
de arquitetos de software em maio de 2011 (LEWIS, FOWLER, 2014).
17

Desde então vem tendo um crescente interesse na comunidade de engenheiros e


desenvolvedores de software. A arquitetura de microsserviços descreve projetos de software
como conjuntos de serviços que tenham implementações distintas, independentes e de
controle descentralizado em apenas um único serviço (PEREIRA et al, 2018).
Esse aperfeiçoamento no desenvolvimento de sistemas modulares e a independência dos
ciclos de vida auxiliaram na consolidação do termo “microsserviços” (LEWIS, FOWLER,
2014).
Do ponto de vista tecnológico, as primeiras aplicações de microsserviços foram
influenciadas por uma nova geração de desenvolvimento de software, implantação e
ferramentas gerenciais. À medida que os microsserviços se tornaram mais populares essas
ferramentas continuaram a evoluir dando suporte a uma base diversa de usuários cada vez
maior, levando assim, à criação de tecnologias ainda mais avançadas (JAMSHIDI et al, 2018).
A Figura 1 mostra uma linha do tempo com as 10 ondas de tecnologias de software e
algumas das suas ferramentas mais representativas que influenciaram o desenvolvimento dos
microsserviços, a sua implantação e operação na última década (JAMSHIDI et al, 2018).

Figura 1 - Linha do tempo das tecnologias de microsserviços

Fonte: Jamshidi et al, 2018

As primeiras cinco ondas tecnológicas já existiam antes que o termo “microsserviço”


fosse adotado (ver a linha pontilhada na ilustração). A primeira onda consistiu em tecnologias
de contêineres leves que permitiam que serviços individuais fossem desenvolvidos,
18

implantados e geridos com maior eficiência. A segunda onda foi composta de tecnologias de
serviços que permitia que se comunicassem uns com os outros sem interferências das suas
redes locais. Tecnologias de monitoramento fizeram parte da terceira onda permitindo o
monitoramento e a análise do comportamento dos recursos dos microsserviços em diferentes
níveis de detalhe.

A quarta onda compreendeu as tecnologias de orquestração que permitiam a alocação


automatizada de contêineres e tarefas gerenciais, já a quinta onda trouxe bibliotecas de
comunicação que permitiam que os serviços se comunicassem com mais eficiência e
confiabilidade.
As outras cinco ondas surgiram em resposta à popularidade dos microsserviços e
incluíram tecnologias de entrega contínua, a sétima automatiza a execução de confiabilidade
crítica em todo o sistema e técnicas de testes de segurança, a oitava tecnologia possui
características relacionadas à comunicação, a nona apresenta tecnologia de computação “sem
servidor” que implementa a função-como-serviço (FaaS). Este modelo permite que usuários
da nuvem desenvolvam, façam a implantação e a entrega em produção de funcionalidades de
serviço ou funções sem a complexidade de criar e gerenciar os recursos de infraestrutura
necessários para sua execução. A décima onda compreende o uso de malhas de serviços
construídas sobre uma instância auxiliar para fornecer comunicação, monitoramento e gestão
do ambiente totalmente integrado.
Segundo Brown (2016, p.1), microsserviços são uma evolução de conceitos anteriores
como Agile, DevOps e RESTful e também “uma abordagem que começou a mostrar a
promessa de eliminar problemas e facilitar o desenvolvimento de aplicativos”.
Fowler (2014) apud Pereira et al (2018), descreve a arquitetura de microsserviços como
uma abordagem para desenvolver uma única aplicação como um conjunto de pequenos
serviços, cada um executando o seu próprio processo e se comunicando com mecanismos
leves, geralmente usando API REST. Além disso, esses serviços são criados com base nos
recursos de negócios e implementados de maneira independente por mecanismo de
implantação totalmente automatizados. Além de pouco gerenciamento centralizado dos
serviços, eles podem ser escritos em diferentes linguagens de programação e usar diferentes
tecnologias de armazenamento de dados.

Existem vários exemplos de sistemas de software projetados e implementados de acordo


com o conceito de microsserviços. Empresas como Netflix, SoundCloud e Nubank usam o
19

conceito de microsserviços em sua arquitetura. A Amazon oferece serviços como S3 que pode
ser considerado como microsserviço (SAVCHENKO et al, 2015).

Várias outras empresas têm usado a arquitetura de microsserviços com sucesso. A


Netflix publicou seus resultados e deu uma visão geral do seu sistema plataforma-como-
serviço (PaaS) e os mecanismos usados na sua plataforma para os componentes que
inicialmente não foram projetados para serem usados na plataforma PaaS 3 (SAVCHENKO et
al, 2015).

Arquiteturas diversas têm sido usadas ao longo das décadas para a solução de
problemas. Segundo Lucio (2017), o objetivo de otimizar a implantação de softwares
modulares, com ciclos de vida independentes, foi o que motivou o aparecimento da
arquitetura de microsserviços. Ao longo dos anos, características relativas à descentralização
de linguagens, automação do processo de implantação, alinhamento ao negócio e organização
de projetos e equipes foram constituindo os microsserviços.

2.3 COMPARAÇÃO ENTRE MONOLÍTICO E MICROSSERVIÇOS

Fowler (2014) relata que uma explicação para entender a arquitetura de microsserviços
pede uma comparação com o estilo monolítico, que é uma aplicação construída como uma
única unidade, isto é, uma única aplicação é responsável por todos os processos. Ela apresenta
a interface para interação com o usuário, acessa os dados persistidos no banco de dados,
processa pedidos de clientes e todas as outras ações que a aplicação necessitar. A aplicação
monolítica é autossuficiente e independente de outras aplicações de computação. A filosofia
do projeto é que o aplicativo é responsável não apenas por uma determinada tarefa, mas pode
também executar todos os passos necessários para completar uma macro função.

A Figura 2, já bastante conhecida na literatura de microsserviços, explica a diferença


entre sistemas monolíticos e microsserviços. Microsserviços podem criar aplicações a partir
de muitos componentes simples, de uso único, fáceis de usar e que permitem a entrega de um
software melhor e mais rápido; mesmo as arquiteturas monolíticas existentes podem ser
transformadas usando o padrão arquitetural de microsserviços (LUCIO, 2017).

3
Ver Prana: A Sidecar for your Netflix PaaS based Applications and Services. Disponível em
<http://techblog.netflix.com/2014/11/prana-sidecar-for-yournetflix-paas.html> e Tonse S. Microservices at
Netflix. Disponível em http://www.slideshare.net/stonse/microservices-at-netflix>.
20

Figura 2 - Comparação entre arquitetura monolítica e de microsserviços

Fonte: Fowler, 2014

A arquitetura de microsserviços tem sido chamada também de variação da arquitetura


orientada a serviços (SOA). SOA surgiu porque as empresas compraram várias aplicações de
software para atender às diferentes áreas do negócio e essas aplicações foram construídas
usando tecnologias diversas. Como precisavam se comunicar umas com as outras, SOA foi a
resposta para este problema (GALDINO, 2017).

SOA e microsserviços compartilham dos mesmos princípios de design na forma de


benefícios como desenvolvimento e tempo de comercialização mais rápidos, reação rápida à
mudanças, dinamismo, redução de custos econômicos e aplicações mais robustas. Nesse
contexto, então, metodologias como desenvolvimento ágil e práticas contínuas como DevOps
pavimentam o caminho para uma evolução convergente de SOA chamada microsserviços.
Convergente, porque a indústria não possui uma definição uniforme sobre microsserviços que
se afaste completamente daquelas estabelecidas por SOA (JUSTINO, 2018).

A composição do serviço, que é uma forte área de pesquisa, oferece a capacidade para
que os serviços interajam uns com os outros e gerem funcionalidades complexas. SOA pode
realizar composições de serviço como orquestração, coreografia e coordenação.
Microsserviços foca na coreografia e evita ser dependente de outros componentes, enquanto
que SOA depende fortemente da orquestração de serviços; em microsserviços, há pouca ou
nenhuma orquestração (LEON, 2017).
21

Segundo ainda Leon (2017), SOA é apropriada para grandes aplicações com dados
pesados, complexos e processamento de mensagens. Microsserviços é apropriado para
aplicações pequenas e sistemas pequenos. Um exemplo dado está na Internet das Coisas (IoT)
onde estão envolvidos muitos microsserviços na troca de informações dos dispositivos IoT.
Além disso, microsserviços é uma melhor escola para microempresas e startups porque a
implantação dos microsserviços é feito em contêineres especializados, o uso de tecnologias da
nuvem estão amplamente disponíveis. Outros dois benefícios são custo e esforço, que são
maiores no SOA.

2.4 VANTAGENS E DESVANTAGENS DOS MICROSSERVIÇOS

São vários os benefícios associados a microsserviços, mas três benefícios têm se


destacado na literatura: Entrega mais rápida do produto, melhor escalabilidade e maior
autonomia. Esses benefícios vão de encontro às necessidades de muitas empresas,
principalmente aquelas orientadas para o cliente e que operam em ambientes altamente
competitivos (JAMSHIDI et al, 2018).

A arquitetura de microsserviço tem como objetivo uma entrega rápida para colocação
em produção assim que possível, já que muitas empresas vêm a tecnologia da informação
como a principal facilitadora para maior agilidade em termos de, por exemplo, adaptação a
mudanças no mercado e por isso uma implantação rápida dos microsserviços em múltiplos
ambientes de execução, em programações arbitrárias e um mínimo de gestão centralizada.

O segundo item nesta lista de três benefícios se refere à escalabilidade, mas de acordo
com Jamshidi et al (2018), este termo é ambíguo porque pode se referir à sua capacidade de
mudança no número de usuários que acessam o serviço ou ainda a capacidade do processo de
desenvolvimento de acomodar desenvolvedores trabalhando em paralelo.

Justamente porque trabalham em paralelo, os desenvolvedores podem tomar decisões


para cada serviço como, por exemplo, linguagem de programação, bibliotecas, ou frameworks
usados, a tecnologia da base de dados ou qualquer aspecto da estratégia de implementação,
cada equipe, portanto, tem autonomia para fazer a melhor escolha para sua área de
responsabilidade (JAMSHIDI et al, 2018).
22

2.5 OS DESAFIOS DOS MICROSSERVIÇOS

Namiot et al (2014) relatam que apesar do entusiasmo com os microsserviços, esta


arquitetura tem um número de desafios a serem superados não somente a complexidade
adicional de criar um sistema distribuído, mas também uma maior dificuldade em testar
sistemas distribuídos. Outros desafios incluem a implementação de um mecanismo de
comunicação entre serviços e alguma forma de transações distribuídas.

Ainda outro desafio é a abordagem da modularização, encontrar os módulos certos, do


tamanho certo, com a missão certa de responsabilidades e interfaces bem projetadas; em
microsserviços pode ser um grave problema porque pode levar a falta de comunicação em
rede e um sistema inapropriado para a tarefa pretendida devido a mau desempenho e
instabilidade (NAMIOT et al, 2014).
Sincronização de dados (consistência), segurança, sincronização entre serviços,
atualização de dados, dependências cíclicas e debugging, log in, testes, monitoramento e
desempenho, suporte para DevOps são mais alguns dos desafios listados por diferentes
autores sobre microsserviços.

2.6 POR QUE MIGRAR DA ARQUITETURA MONOLÍTICA PARA


MICROSSERVIÇOS?

Nos últimos anos diversas empresas têm migrado seus sistemas monolíticos para a
arquitetura de microsserviços. Algumas delas como Wix.com adotou microsserviços devido a
problemas técnicos que resultaram em sérios problemas de estabilidade e em 2010 a empresa
começou o repartir em pequenos serviços a fim de melhor lidar com a escalabilidade e a
qualidade (DOERRFELD, 2018).
Mas, a migração não aconteceu sem problemas. Wix.com teve que lidar com vários
problemas começando com comunicação entre os microsserviços a falhas diversas e, portanto,
teve que inventar um novo padrão de integração e de testes, além de uma nova cultura interna.
A arquitetura interdependente da Best Buy também se tornou um problema com
gargalos nas implantações de modo que o tempo ocioso era longo demais para sustentar a
condução de negócios online. Mas o maior problema durante a migração do sistema foi a falta
de confiança entre o pessoal de TI devido a uma resistência cultural à maneira como o
software é desenvolvido e lançado (DOERRFELD, 2018).
23

Na Cloud Elements houve uma jornada de descoberta exigindo “design e debate”


devido às diferentes opiniões e requisitos em conflito (DOELLING, 2017).
Muitas empresas, no entanto, ainda hesitam em abandonar a sua arquitetura monolítica
em favor de uma arquitetura mais ágil e independente como microsserviços. Taibi et al (2017)
conduziram uma pesquisa com profissionais experientes que migraram sua arquitetura
monolítica para microsserviços, identificando a estrutura do processo baseada em uma
comparação de três processos de migração adotados pelos entrevistados, a motivação para
migrar e os problemas que surgem durante a migração.
Dada a singularidade desta seção, que foi analisar a motivação para migrar e os prós e
os contras da migração, é importante para o escopo deste trabalho detalhar alguns dos
resultados.
Como um dos objetivos mais importantes da pesquisa foi avaliar a importância dos
motivos para migrar, os participantes classificaram a sua motivação em uma escala Likert de
5 pontos onde 0 significava “totalmente irrelevante” e 4 significava “fundamental.” Além
disso, foi explicado que os valores da escala tinham o único propósito de classificar as
motivações. Por exemplo, um valor de 5 para manutenção e 3 para separação de preocupações
indicava que a manutenção era considerada mais importante, mas que valores de 5 e de 3,
sozinhos, não tinham significado. Alguns dados sobre os entrevistados: (TAIBI et al, 2017).

 Papel dos entrevistados em suas empresas: 31.82%, arquitetos de software; 27,27%,


gerentes de projetos; 22.73%, desenvolvedores sênior; 9,09% agile coaches; e 9,09%
foram CEOs ou presidentes de companhias. Todos os entrevistados tinham pelo menos
5 anos de experiência em desenvolvimento de software, inclusive os CEOs.
 Empresas: 28,57% dos entrevistados trabalhavam em bancos; 28,57% para
companhias que produzem e vendem seu software como serviço, isto é,
desenvolvedores de websites, geradores de aplicativos, e outros; 23,81% eram
consultores especializados em migração para microsserviços; 9,52% trabalhavam em
departamento de TI da administração pública; e, 9,52% em empresas de
telecomunicação.
 Tipo de migração: A fim de tratar dos prós e contras mais comuns da migração para
microsserviços, foram consideradas migrações completadas e migrações em
andamento levando em consideração as experiências dos consultores de software que
deram suporte a várias migrações e as experiências de empresas que já tinham
migrado ou ainda estavam em processo de migração.
24

Taibi et al (2017) mostram na Tabela 1 que a manutenção do software foi classificada


como a motivação mais importante, seguida por escalabilidade, delegação de responsabilidade
a equipes independentes e o fácil suporte para o DevOps. Os autores notaram que vários
respondentes da pesquisa reportaram que adotaram as arquiteturas baseadas em serviço
porque outras companhias também estavam adotando.

Tabela 1 - Resultados do quesito motivação


Motivação Todos Consultores de Outros
migração

Total Média Total Média Total Média


Manutenabilidade 15 4 5 2 10 4

Escalonabilidade 15 2 3 3 12 2

Delegação de 11 3 1 3 10 3
responsabilidades
da equipe
Suporte DevOps 8 3 2 1 6 3

Porque todos 6 4 2 3 4 4
estão fazendo
Tolerância a 2 4 2 4 / /
falhas
Experimentar 2 3 2 3 / /
tecnologia fácil
Delegação de 1 4 1 4 / /
responsabilidades
do software

Fonte: Taibi et al, 2017

Os respondentes da pesquisa também encontraram vários problemas durante a


migração de monolítico para microsserviços. A Tabela 2 apresenta os problemas reportados
pelos respondentes onde os principais problemas reportados foram a complexidade do
25

desacoplamento do monolítico, seguido pela migração e separação de dados em bases de


dados legadas e comunicação entre serviços.

Tabela 2 - Problemas de migração identificados pela pesquisa


Problemas Todos Consultores de Outros
migração

Total Média Total Média Total Média


Desacoplamento 7 3 / / 7 3

Migração da 6 4 / / 6 4
base de dados e
separação de
dados
Comunicação 4 3.5 2 3 2 3
entre serviços
Estimativa do 2 4 2 1 2 3
esforço
Infraestrutura 2 4 / 4 / /
do DevOps
exigindo
esforço
Esforço da 2 4 / / 2 4
conversão da
biblioteca
Mente das 2 4 1 4 1 4
pessoas
Retorno 2 3 1 3 1 3
esperado no
investimento
Fonte: Taibi et al, 2017

Um ponto interessante da pesquisa foi o que pensavam as pessoas envolvidas seguidas


por um retorno no investimento em longo prazo. A pesquisa mostrou que a migração foi
26

motivo de preocupação para vários desenvolvedores principalmente porque os de mais idade


nem sempre acreditam nas tecnologias recentes. Além disso, muitos consideram o Sistema de
legado uma criação própria e tem relutância em aceitar uma mudança importante no software
que eles desenvolveram (TAIBI et al, 2017).
Os entrevistados usaram três diferentes processos para migrar de uma arquitetura
monolítica para uma arquitetura baseada em serviços, apresentados na Figura 3. As três
colunas identificam claramente os passos em comum e os diferentes nos três processos. O
objetivo dos dois primeiros processos foi migrar um sistema monolítico existente para
microsserviços reimplementando o sistema do zero. O objetivo do terceiro foi implementar
apenas novas características como microsserviços, substituir serviços externos fornecidos por
terceiros ou desenvolver características que precisavam de mudanças importantes e, portanto,
poderiam ser consideradas como características novas, e assim, gradualmente, eliminar o
sistema existente.

Figura 3 - Estrutura dos processos de migração identificados

Fonte: Taibi et al, 2017


27

Todos os participantes que trabalhavam em empresas de consultoria recomendaram as


duas primeiras abordagens (24%). O processo 2 também foi adotado por metade dos
profissionais que trabalhavam em outros tipos de empresas e o processo 3 foi adotado pela
outra metade. Todos os processos têm alguns pontos em comum, a diferença está nos detalhes
(TAIBI et al, 2017).
Alguns participantes que estavam usando o terceiro processo relataram que migrariam
seus serviços existentes para microsserviços à medida que trabalhassem na sua manutenção
(TAIBI et al, 2017).

2.7 HISTÓRIA DO STACKOVERFLOW

Não é novidade que a internet e seus componentes vivem em constantes mudanças e


evolução. Cansado da forma com que os desenvolvedores tiravam suas dúvidas, Joel Spolsky
observou o que havia de bom nos fóruns existentes, juntando todos num só lugar e com a
ajuda de Jeff Atwood resolveu criar um fórum que fosse gratuito, que englobasse todas as
linguagens de programação, que pudesse ser encontrado através dos buscadores e que fosse
divertido (SPOLSKY, 2018).
Pensando em tudo isso, eles criaram o stackoverflow. A princípio era um site de
perguntas e respostas e de anúncios de emprego. Sendo gratuito e utilizando os melhores
recursos dos primeiros fóruns, o stackoverflow foi se tornando um site muito melhor para
fazer perguntas e obter respostas sobre programação. Querendo fazer algo divertido, Joel
copiou a ideia de um sistema de reputação já vista no Slashdot e Reddit de modo que, à
medida que o usuário ganha reputação, também ganha privilégios de moderação e dessa
forma o site se auto modera (SPOLSKY, 2018).
Ele também teve a ideia de juntar os programadores de todas as linguagens no mesmo
lugar, separando as perguntas por marcadores. Foi percebido, que para cada pergunta feita, as
respostas eram vistas por milhares de pessoas. Então decidiram otimizar o sistema e
classificar as respostas de acordo com a relevância, ou seja, as mais relevantes para aquela
pergunta apareciam primeiro (SPOLSKY, 2018).
A princípio, a intenção era apenas consertar a internet, pois não era boa para os
programadores e também não havia interesse em ser lucrativo, ganhar apenas o suficiente para
manter o site na internet. Esses foram os fatores motivadores para a criação do site
(SPOLSKY, 2018).
28

2.8 RESUMO

Este capítulo descreveu toda a fundamentação teórica utilizada durante o


desenvolvimento desta pesquisa. Foram explanados os conceitos de arquitetura monolítica, e
arquitetura de microsserviços. Discorremos sobre a comparação entre as arquiteturas, as
vantagens e desvantagens de cada uma. Também foram explanados os desafios referentes a
microsserviços, foram apresentados alguns dos fatores motivacionais para a migração de
arquitetura e por fim apresentado a história e a motivação para o surgimento do
Stackoverflow.

No próximo capitulo será apresentado a metodologia utilizada no presente trabalho,


apresentando um pouco sobre o Stackoverflow, como os dados foram obtidos, os critérios de
exclusão e as perguntas que se desejam responder.

3 METODOLOGIA

O objetivo desse capítulo é apresentar metodologia utilizada na presente pesquisa,


apresentando um pouco sobre o Stackoverflow, como os dados foram obtidos, os critérios de
exclusão e as perguntas que se desejam responder.
A seção 3.1 apresenta a classificação da pesquisa diante de três aspectos; já a seção 3.2
apresenta mais um pouco da história atual do Stackoveflow; a seção 3.3 apresenta todo o
processo do trabalho.

3.1 CLASSIFICAÇÃO DA PESQUISA

A pesquisa realizada foi classificada perante três aspectos: método de procedimento,


objetivo e natureza dos dados. Quanto ao método de procedimento foi adotado uma
abordagem Goal-Question-Metric (GQM)4, que é um tipo de procedimento que representa
uma abordagem sistemática orientada para metas.

4
Disponível em: https://s3.amazonaws.com/academia.edu.documents/40605563/gqm.pdf?response-content-
disposition=inline%3B%20filename%3DThe_Goal_Question_Metric_Approach.pdf&X-Amz-
Algorithm=AWS4-HMAC-SHA256&X-Amz-
Credential=AKIAIWOWYYGZ2Y53UL3A%2F20190623%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-
Date=20190623T134515Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-
29

No que diz respeito ao objetivo, a pesquisa é classificada como descritiva, visto que os
fatos foram sistematicamente coletados, registrados, analisados e exibidos com o intuito de
apresentar os principais desafios no uso de microsserviços (BARREIROS, 2015).
Em relação à natureza dos dados e das análises adotadas, a pesquisa predomina o caráter
qualitativo, visto que apresenta análise e interpretação do contexto do objeto de pesquisa.

3.2 SOBRE STACKOVERFLOW

Atualmente o StackOverflow conta com mais de 2.5 milhões de usuários cadastrados e


recebe mais de 50 milhões de acessos por mês, conta com mais de 14 milhões de perguntas e
mais de 19 milhões de respostas, segundo o próprio site5. O stackoverflow incentiva os
usuários a participarem cada vez mais, e com respostas relevantes para os problemas; através
de um sistema de pontuação os usuários mais ativos, os usuários que criam perguntas bem
formuladas, com mais soluções relevantes, e corretas, acabam sendo reconhecidos pela
participação sendo premiados com o aumento da sua reputação, distintivos e privilégios que
recompensem suas ações dentro da comunidade. Por outro lado, existe a pontuação negativa,
que também faz parte do sistema de reconhecimentos, entretanto à medida que a pontuação
baixa, através de perguntas mal formuladas, respostas incoerentes com o problema, esses
privilégios são retirados. Esse processo de pontuação foi a forma encontrada para garantir que
fosse divertido, estimular a participação dos usuários participem e garantir conteúdo de
qualidade.

3.3 EXECUÇÃO DA PESQUISA

Os dados discutidos neste trabalho foram obtidos através de um repositório6, onde ficam
armazenados todos os dados do Stackoverflow. Após a obtenção e o tratamento dos dados, foi
percebido que o mesmo estava incompleto, pois estava apenas com as perguntas e sem as
respostas. Visto isso, foi feito uma nova coleta dos dados através do serviço online 7 onde
através da consulta, exibida na Figura 4, foram obtidos os mesmos dados referente à
microsserviços, só que dessa vez com as respostas.

Signature=a716e56ad8861ba68d86d1b2c8084b2566341b38d3f5fbe87cf86f4e9f00cba1 Acessado dia 23 de


junho de 2019.
5
Disponível em: https://stackoverflow.com/company, acessado dia 17 de junho de 2019.
6
Disponível em: https://archive.org/download/stackexchange, acessado dia 26 de fevereiro de 2019.
7
Disponível em: https://data.stackexchange.com/stackoverflow/queries, acessado dia 19 de março de 2019.
30

Figura 4 - Comando de seleção dos dados

O processo de seleção através da aplicação dos critérios de exclusão foi através da


leitura, análise e interpretação os dados realizados pelo autor. Dessa forma foram selecionadas
as perguntas e as potenciais soluções sugeridas pela comunidade. Onde inicialmente na base
havia 1084 perguntas, após a aplicação do critério de exclusão foram selecionadas 152
questões, como é mostrado na Tabela 3.

Tabela 3 - Lista dos Critérios de Exclusão

Critérios de Exclusão Quantidade Porcentagem


Perguntas não relacionada à microsserviços. 723 67%
Perguntas relacionadas à microsserviços, mas não relata um problema. 91 8%
Perguntas conceituais 81 7%
Perguntas duplicadas 37 4%
Perguntas selecionadas 152 14%
TOTAL 1084 100%

Em seguida, foi feita uma análise do conteúdo, possibilitando responder as perguntas


que motivaram essa pesquisa.
Q1 – Quais os principais desafios no uso de microsserviços?
Motivação: Identificar os maiores desafios na arquitetura de microsserviços, auxiliando
aos indivíduos na hora do seu uso.
Abordagem: Analisando as publicações coletadas no Stackoverflow e exibindo as
perguntas após a aplicação dos critérios de exclusão exibidos na Tabela 3.
Q2 – Quais as potenciais soluções sugeridas para os desafios no uso de microsserviços?
Motivação: Identificar as possíveis soluções para os desafios no uso de microsserviços
para ajudar as pessoas a evitar ou corrigir tais problemas.
31

Abordagem: A partir das publicações coletadas, foram extraídas as soluções sugeridas


pelos usuários. Esses achados são apresentados como possíveis soluções para os desafios
detectados na Q1.

3.4 RESUMO

Neste capítulo foi descrito a metodologia utilizada neste trabalho, apresentando um


pouco sobre o Stackoverflow, como os dados foram obtidos, os critérios de exclusão e as
perguntas que se desejam responder. No próximo capítulo são apresentados uma análise dos
resultados obtidos.

4 RESULTADOS

Nesse capítulo será apresentada a aplicação da abordagem GQM juntamente com os


resultados obtidos e uma discussão sobre as soluções obtidas pela comunidade. Na seção 4.1
apresenta os quadros do GQM, onde mostra o objetivo, as questões e as métricas utilizadas na
pesquisa. Na seção 4.2 são apresentados os desafios e as potenciais soluções mapeadas na
base de dados e na seção 4.3 é apresentada uma discussão sobre os desafios e suas possíveis
soluções.

4.1 QUADROS DO GQM

Para a obtenção dos resultados, foi utilizada a abordagem GQM, o Quadro 1 apresenta
os objetivos definidos de acordo com o objetivos deste trabalho.

Quadro 1 - Objetivo da Pesquisa

OBJETIVO
OBJETO Analisar Estudo sobre microsserviços
Melhorar a compreensão
FINALIDADE Com o propósito de
sobre microsserviços
FOCO Com relação aos Questionamentos
32

encontrados no
Stackoverflow
PONTO DE VISTA Sob o ponto de vista do Desenvolvedor de Software
AMBIENTE No seguinte contexto Stackoverflow

Após a definição dos objetivos, foram elaboradas as questões relacionadas a eles, sendo
elas exibidas no Quadro 2, onde foram definidos baseados nos objetivos específicos desde
trabalho.

Quadro 2 - Questões

QUESTÕES
Q1 - Quais os principais desafios referentes ao uso de microsserviços?
Q2 - Quais as potenciais soluções para os desafios detectados na questão anterior?

Em seguida, faz-se necessária a definição das métricas, pois elas devem conter
informações suficientes para responder as questões. O Quadro 3 apresenta as métricas
utilizadas para a obtenção das respostas das questões exibidas no Quadro 2.

Quadro 3 - Métricas

MÉTRICAS
M1 - Olhar no stackoverflow quais são esses desafios
M2 - Olhar no stackoverflow quais as soluções para esses desafios

A Figura 5 ilustra a relação entre o objetivo, às questões e as métricas.

Figura 5 - Diagrama das Métricas GQM


33

Depois de estabelecido o objetivo, as questões e as métricas, foi realizada a coleta e o


tratamento dos dados, explanados na seção 3.3, em seguida se deu o processo de análise dos
dados; os mesmos foram lidos um a um e classificados de acordo com o problema ao qual
estava relacionado. Por fim, detectamos que os principais desafios estão relacionados à
segurança, aplicação, arquitetura, banco de dados, migração e spring.
A seguir apresentaremos os maiores desafios e suas possíveis soluções, isso não quer
dizer que esses sejam os únicos, pode-se dizer que a partir da análise dos dados coletados, as
empresas sentem a necessidade de se tornar mais flexíveis para mudanças, mais ágeis para
atender a demanda de mercado, e para isso estão apostando em microsserviços para não
ficarem obsoletas na qualidade dos serviços prestados.

4.2 DESAFIOS

Segurança
Na base de dados foram encontradas várias perguntas relacionadas ao mesmo
problema, e com isso podemos identificar várias maneiras de se resolver esse mesmo
problema. O processo de autenticação e controle de acesso garante que o usuário só consiga
ter acesso a aquilo que lhe é permitido.
Na autenticação faz-se a primeira verificação, onde se detecta quem e que tipo de
usuário está acessando ou se é alguém tentando invadir o sistema. Após esse processo de
verificação e acesso ao sistema, toda e qualquer atividade deve ser permitida pelo controle de
acesso, restringindo o acesso apenas ao que foi pré-estabelecido na hora da criação do
usuário. Dessa forma pode-se afirmar que para garantir a segurança de um microsserviço é
necessária a junção da autenticação e o controle de acesso.
O Quadro 4 apresenta as questões relacionadas a segurança e algumas possíveis
soluções para essas questões.
34

Tabela 4 - Perguntas relacionadas à segurança

Desafio Problema Quantidade Descrição Solução


Específico
Qual método utilizar para Usar CORS /
Usar XACML /
garantir Fazer autenticação
Autenticação 18 Usar Oauth / Usar
autenticação usando com banco de
o Spring Security
Microsserviços? dados
Segurança
Como garantir controle de
Usando ACL /
Controle de acesso a
7 Usar JWT / Fazer Usar DMZ
Acesso determinadas partes do
via API Gateway
Microsserviços?

O processo de autenticação pode ser feito de várias maneiras como sugerida pela
comunidade. O spring security é utilizado apenas para aplicações java, o Oauth é bastante
utilizado quando se deseja o login único (single sign on), ou seja, permite acesso seguro a
vários sites sem compartilhar dados de senha, faz isso através do envio de tokens de
autorização. O XACML tem a mesma finalidade do Oauth, usado quando deseja o logon
único, mas faz uso de XML para garantir o acesso seguro a vários sites. O CORS é uma
política de segurança e não se aplica nesse nosso caso. Então, podemos afirmar que o Oauth e
o XACML são bastante abrangentes para a resolução do problema de autenticação, onde o
Oauth possui uma complexidade menor que o XACML. O spring security também resolve o
problema de autenticação, mas é limitado para a linguagem java.
O controle de acesso também pode ser feito por diversas formas como foi sugerida pela
comunidade. O DMZ é usado em redes, logo não atende o nosso problema. O JWT não é
propriamente um método de controle de acesso, mas é um token que pode ser usado
combinado com o Oauth para fazer o controle de acesso. Já o controle de acesso feito pela
API Gateway é específica para fazer o controle de acesso, é uma maneira tão simples quanto o
JWT. Logo, ambas resolvem o problema e a escolha de uso fica pela parte dos
desenvolvedores.

Aplicação
A aplicação é o software que é composto por vários microsserviços, e nessa base
foram detectadas algumas dificuldades em relação ao teste dos módulos e sobre a interface
vista pelo usuário, como pode ser visto no Quadro 5.
35

Tabela 5 - Perguntas relacionadas a aplicação

Desafio Problema Quantidade Descrição Solução


Específico
Colocar os testes como uma das etapas do
Testes 3 Como criar testes automáticos?
fluxo
Aplicação
Criar uma UI monolítica e conectar a
UI 2 Conectar UI com a aplicação
aplicação Microsserviço

Os testes são a garantia que o sistema chegará ao cliente livre de falhas e a solução
dada foi que os testes fosse uma etapa do fluxo de entrega do produto final, dessa forma
tornando possível a correção do mesmo. Sendo construído dessa forma, com os testes fazendo
parte do fluxo, podemos dizer que é a forma correta de realização dos testes, caso a aplicação
não passe em algum dos testes, a mesma é automaticamente reprovada alertando ao
desenvolvedor onde foi reprovada, evitando que essa versão do software chegue ao seu
destino final com problemas.
Já a construção da interface gráfica, não precisa ser criada como um microsserviço,
pois isso poderia aumentar a complexidade de sua construção, então foi sugerido que ela fosse
criada como um monolítico e conectada a aplicação. Essa solução é bastante simples e a mais
prática, pois oferece ganho de tempo e baixa complexidade.

Arquitetura

O Quadro 6 apresenta os problemas referente a arquitetura, foram encontrados vários


problemas em pontos diferentes.

Tabela 6 - Perguntas relacionadas a arquitetura

Desafio Problema Quantidade Descrição Solução


Específico
Banco de Problemas específicos de cada
4 Escolher melhor a arquitetura
Dados projeto
Manda rever a arquitetura, pois existe
Transação 1 Garantir consistência em transações
condições que ocasionam inconsistência
Arquitetura Garantir gerenciamento de
Gerenciamento 1 Usar o Ansible ou o Chef
implantação
Como melhorar o
Desempenho 2 Diz pra fazer de forma assíncrona
desempenho?(Paralelismo)
Comunicação 40 Compartilhar dados entre MS Cada MS deve ter seu próprio Banco de
36

Dados e usar o HTTP para compartilhar


os dados
Usar mensageria (PUB/SUB), RPC ou
Reduzir latência na comunicação
THRIFT
Compartilhar estados entre MS Recomenda usar mensageria (PUB/SUB)
Usar o HTTP / Usar Firewall / Usar
Comunicação entre os MS
mensageria (PUB/SUB)
Replicação de módulos Recomenda o reuso de módulos
Reduzir acoplamento na arquitetura
Refazer a arquitetura
de MS
Construção 23
Reuso de código por outro MS Tratar como dependência externa
Problemas específicos de cada
Refazer a arquitetura
projeto

Quando relacionado a banco de dados, foi detectado que as dificuldades eram muito
específicas de cada projeto, e dessa forma os usuários apenas recomendavam escolher melhor
a arquitetura do banco, pois não havia como corrigir. Sendo a melhor maneira, pois tentar
corrigir essa arquitetura pode gerar um grande esforço e tempo, onde reconstruir com uma
arquitetura bem desenhada gastaria um esforço bem menor.

Quando se referiu à transações, também foi recomendo que fosse revista a forma
como estava sendo construído, pois dessa forma havia situações que causaria inconsistência
dos dados. A inconsistência se dá através da existência de informações duplicadas em
diversos lugares. Faz-se necessário que a arquitetura seja muito bem desenhada para evitar
que durante o processo essas duplicatas sejam criadas.

Quando os problemas se referiam ao gerenciamento de aplicações para implantação,


recomendaram o uso de alguma ferramenta que fizesse essa atividade de forma automatizada.
Tanto o Ansible quanto o Chef resolvem o problema do gerenciamento na implantação, a
opção por um ou pelo outro será dada pela particularidade do projeto e dos desenvolvedores
que trabalharão com eles, entretanto podemos afirmar que ambos atendem essa necessidade
de gerenciamento.

Já quando se trata de desempenho, a fim de garantir uma melhor resposta do sistema


em si, então foi sugerido que a troca de dados, a troca de informações, deva ser feita de forma
assíncrona, pois dessa forma diminuirá o tempo ocioso de um módulo independente.
Otimizando o uso dos recursos disponíveis.
37

As dúvidas sobre comunicação se dão em como fazer os microsserviços


compartilharem informações, estados e dados entre si. Para resolver os problemas quanto aos
dados, então foi sugerido que cada microsserviço tivesse seu próprio banco de dados e que o
compartilhamento desses dados fossem via HTTP. Enquanto aos estados e as informações
pudessem ser feitas através do serviço de mensageria, que funciona da maneira unidirecional,
ou seja, um microsserviço envia, e todos os outros recebem. Para garantir que todos se
comuniquem cada microsserviço terá um canal para enviar, e vários canais para receber as
informações. Além de garantir a comunicação, esses canais é maneira mais simples de reduzir
o atraso na comunicação entre eles. Essa forma sugerida é a maneira mais prática e mais
comumente usada para o compartilhamento de dados, de estados e a mais simples de se
estabelecer comunicação entre os serviços.
As questões relacionadas à construção são problemas que surgem devido a uma
escolha parcialmente adequada quanto a melhor forma de se construir o sistema com esse tipo
de arquitetura. Então quando nesse estado, só tem duas opções a serem seguidas, corrigir um
problema bastante específico pouco comum, ou mudar completamente a arquitetura com que
os módulos do sistema estão conectados. A opção de reconstruir ou corrigir vai depender
especificamente da necessidade da empresa.

Banco de Dados

Banco de dados é um conjunto de arquivos relacionados entre si. São coleções


organizadas de dados que se relacionam de alguma maneira. São responsáveis por manter
armazenamento dos dados que são manipulados pelo sistema. O sistema precisa garantir que
os dados sigam as regras de consistência e de integridade, dessa forma evitando alguns
problemas como registros fantasmas, por exemplo. O Quadro 7 apresenta os problemas
detectados através da análise dos dados.

Tabela 7 - Perguntas relacionadas ao banco de dados

Desafio Problema Quantidade Descrição Solução


Específico
Fazer o Usar um banco de dados Usar o banco de dados
Banco de
Arquitetura 11 compartilhamento comum / Recomenda que cada no cliente, ao invés do
Dados
de dados MS tenha seu próprio banco servidor
38

Problema nos
Manda rever a arquitetura sobre
relacionamentos do
como o banco foi dividido e as
banco de dados
relações mantidas
para utilizar no MS
Garantir
Usar gerenciadores de
consistência dos
transações
dados
Onde armazenar
tabela comum para Replica a tabela
Consistência 7 todos os MS
Sincronizar o banco
de dados entre os Usando JWT
MS
Eliminar registro Criar um MS cuja função é
fantasma eliminar esses registros
Garantir múltiplo Diz que não é possível
Múltiplo
1 acesso ao Banco de Recomenda usar JDBC pois cada MS tem seu
Acesso
Dados próprio servidor

Os problemas ligados à arquitetura do banco de dados, compartilhamento dos dados,


podem ser resolvidos de maneiras diferentes, dependendo de como está a construção do
sistema como um todo. Dessa forma é possível usar um banco de dados compartilhado para
todos os microsserviços ou cada microsserviço ter um banco de dados próprio e de maneira
assíncrona ser feita a atualização desses bancos. Por outro lado, existe outra solução que é a
reconstrução do banco dados, essa solução geralmente é adotada quando há um grande erro de
construção.
Os desafios de manter os dados consistentes deve-se usar um sistema de gerenciamento
de banco de dados (SGBD) e ele mesmo vai garantir que as transações sejam feitas de
maneiras consistentes. O armazenamento das tabelas que são de uso comum deve ser
replicada para que todos os serviços tenham uma cópia, e de maneira assíncrona elas devem
ser sincronizadas, ou todos devem ter acesso a mesma tabela, entretanto pode ocorrer uma
perca de desempenho devido ao controle de acesso a essa tabela, para evitar que vários
serviços altere o mesmo dado ao mesmo tempo.
Para sincronização do banco de dados entre microsserviços foi sugerido que se usasse
JWT para isso, entretanto existem outras formas mais adequadas de se fazer, como o uso de
API REST, cria-se um serviço dedicado para isso, onde de tempos em tempos, ele sincroniza
o banco de dados, para que todos os microsserviços tenham acesso aos meus dados.
39

Migração
É o processo de mudança do software construído em uma arquitetura para outra, nesse
caso de monolítico para microsserviço. Essa migração deve ser feita em etapas e o erro ou má
formação em alguma dessas etapas impactará no resultado final. Nas pesquisas foi encontrado
um caso que é o inverso, migrando de microsserviço para monolítico. O Quadro 8 trás os
problemas relacionados a migração.

Tabela 8 - Perguntas relacionadas a migração

Problema
Desafio Quantidade Descrição Solução
Específico
Gerenciar os dados Usar cache distribuída
Fazer um MS reagir depois de receber Usar um framework para realizar
Arquitetura 14 uma mensagem essa orquestração
Migrar mas manter os mesmo Escrever o MS e redirecionar as
endpoints chamadas
Migração Banco de Como migrar todo o sistema, sem
6
Dados migrar o banco de dados?
Melhor forma para se monitorar um
Monitoramento 1
MS
Como unir os MS para gerar um
Reversa 1
Monolito?

Quando o problema da migração está relacionado a arquitetura, foi encontrado problemas com o
gerenciamento dos dados então foi sugerido que se use cache distribuída. Essa cache distribuída vai
permitir que vários microsserviços tenham acesso aos dados de maneira rápida, e evita que os
microsserviços tenham acesso direto ao banco de dados. Essa cache é sincronizada de maneira
assíncrona com o banco de dados na medida em que é utilizada.
Para fazer com que o serviço reaja após algum evento, é necessário usar um
framework/software para fazer esse tipo de orquestração. Ainda relacionada a arquitetura, para migrar
de arquitetura sem precisar mudar os endpoints, então cria-se os novos microsserviços e redireciona as
chamadas. Pois quem está chamando o recurso não sabe como está sendo executado por trás do
endpoint.
As células vazias na tabela, significam que nesses desafios em específicos não havia nenhuma
solução sugerida, dessa forma eu, como um estudante do assunto, sugeri algumas possíveis soluções
para esses problemas.
Para utilizar o mesmo banco de dados após a migração do sistema, não houve nenhuma
sugestão, mas cria-se uma interface entre o banco de dados e a aplicação e todas as requisições devem
40

ser feita através dessa interface. Com isso, independente de como a aplicação esteja construída, basta
que a requisição seja feita corretamente que os dados corretos serão retornados.
O monitoramento de microsserviços pode ser feito através de softwares, como por exemplo,
Splunk, Nagios, Loggly, entre outros. Já referente à migração reversa, não houve nenhuma possível
solução, mas acredito que o processo deve ser a reconstrução do sistema, visto que passar de uma
construção fracamente acoplada para uma fortemente acoplada não seja algo tão comum.

Spring

É um framework que tem como principal objetivo auxiliar o desenvolvedor no


desenvolvimento da parte de infraestrutura do sistema. O Spring possui vários projetos para
ajudar o desenvolvedor e assim poder oferecer um ganho de tempo e padrão no
desenvolvimento. Os problemas relacionados à Spring, em sua grande maioria, se dão na sua
configuração. Uma vez configurado corretamente, o desenvolvedor não mais precisará
trabalhar nele novamente. O Quadro 9 apresenta as publicações referentes aos problemas com
o uso de spring com microsserviços.

Tabela 9 - Perguntas relacionadas à Spring

Desafio Problema Quantidade Descrição Solução


Específico
Como obter um diagrama Instalar o plugin Spring IDE ou Spring
Integration 1 gráfico de toda a camada de Tool Suite e realizar algumas
integração configurações
Configurar o Spring MVC
MVC 2 Manda refazer a configuração
para fazer redirecionamento
Cloud 1 Compartilhamento de cache Manda usar um cache distribuído
Spring
Manda rever a configuração, pois é erro
HATEOTAS 1 Configurar o Hateotas
de configuração.

Não recebe a resposta da Manda rever a configuração, pois é erro


Security 3
autenticação de configuração.
Boot 2 Gerenciar dependências Criar a dependência no maven

Os problemas relacionados à Spring, em suma resumiu-se a problemas com o uso do


framework e suas configurações, então as sugestões dadas é que as pessoas estudassem mais
sobre o framework e revisse suas configurações.
41

4.3 DISCUSSÃO DOS RESULTADOS

Apesar de ser utilizado por grandes empresas, Netflix, Nubank, In Loco Media, entre
outras, microsserviços ainda é um conceito novo, e por sua vez apresentam bastantes desafios.
Garantir a segurança dos dados é algo imprescindível para qualquer organização, no quadro 4
observa-se que existem várias maneiras conseguir segurança em microsserviços, de maneiras
a autenticação através do Oauth, XACML ou Spring security(para aplicações java) e o
controle de acesso pode ser feito através da combinação do Oauth com o JWT, pela ACL ou
apenas pela API Gateway.
A arquitetura do microsserviço é relativamente simples de entender, porém a sua
construção não é tão simples de ser entendido, visto que uma parte das empresas e dos
desenvolvedores estão familiarizados com outro tipo de arquitetura, que possui uma
construção simples. Dessa forma, os problemas relacionados à arquitetura, como pôde ser
observado no quadro 6, o maior gargalo é como conseguir a comunicação entre esses
serviços, e uma possível solução é usar algum tipo de serviço de mensageria, que faça essa
troca de informações entre os microsserviços.
Quando se refere ao o uso de banco de dados, o desafio mais impactante é a sua
arquitetura, ou seja, como é possível usar o banco de forma que seja possível suportar vários
microsserviços acessando o tempo todo e que mantenha os dados consistentes, a solução para
esse desafio vária de problema para problema, como visto no quadro 7, mas pode ser
resolvido de duas formas basicamente, usando um banco de dados comum e usar uma política
que controle o acesso ou usar um banco de dados individual para cada microsserviço e usar
uma política para fazer a sincronização dos dados. Dessa forma é possível garantir um banco
consistente e que pode ser usado por vários microsserviços.
Já a migração envolve várias etapas, e por isso como foi visto no quadro 8, o problema é
essa mudança, desconstruir algo que já está funcionando para mudar a forma como está
construída. Então, esse problema também pode ser abordado de maneiras diferentes, a
depender da necessidade e tempo que a empresa tem disponível para a realização dessa
migração. Para um curto prazo, o sugerido foi que os novos módulos sejam criados seguindo
a nova arquitetura e conectados ao sistema antigo, e em algum momento mais oportuno mudar
gradativamente o sistema antigo, já para um longo prazo, a sugestão é criar um software em
paralelo seguindo a arquitetura de microsserviço, para evitar problemas no sistema atual, e
quando o mesmo estiver completo, fazer a substituição de softwares.
42

A tendência é que cada vez mais empresas busquem uma forma de usar microsserviços,
seja através da migração do sistema antigo, ou através da construção de um sistema nova e
substituição do antigo, mas, apesar de ser um conceito que ainda não está maduro, vem para
mudar a forma de se desenvolver software.
Os resultados desse estudo apresentam informações sobre os desafios e algumas
potenciais soluções, entretanto algumas dessas potenciais soluções realmente solucionam o
problema, outras atendem parcialmente, como por exemplo, o uso do JWT para solucionar o
problema de controle de acesso, onde apenas o ele não resolve o problema, entretanto
utilizado junto com o Oauth resolveria. Há algumas que não atendem a necessidade, como o
próprio JWT quando foi citado para resolver o problema de consistência de banco de dados.
Visto isso, esperamos que através dos dados encontrados nesse estudo através da exibição
esses desafios e das suas possíveis soluções, auxiliem os desenvolvedores de software e/ou
stakeholders a superarem tais problemas.

4.4 RESUMO

Neste capítulo foi apresentada a definição do objetivo, das questões e das métricas
utilizadas, foi apresentado os principais desafios e algumas possíveis soluções, junto com eles
uma discussão sobre essas soluções sugeridas pela comunidade. Algumas delas totalmente
válidas, algumas parcialmente corretas e algumas que estavam fora do contexto, pois
resolviam esse tipo de problema, mas em outro contexto.
43

5 CONSIDERAÇÕES FINAIS

Este capítulo apresenta as considerações finais do trabalho. Serão apresentadas as


recomendações para trabalhos futuros e as conclusões obtidas com a pesquisa.

5.1 TRABALHOS FUTUROS

A partir da realização desta pesquisa, podem-se levantar algumas oportunidades de


trabalhos futuros, bem como direcionamento para novas pesquisas, que poderão contribuir
para a melhoria de pesquisas no contexto de microsserviços.
 Estudos que acompanhem a evolução da arquitetura de microsserviços até o seu
amadurecimento.
 A migração de outras arquiteturas para microsserviços.
 Expandir essa pesquisa realizando o estudo em outras fontes que não somente o
Stackoverflow.
 Avaliar os resultados encontrados nesse trabalho de graduação através da
replicação deste estudo.

5.2 CONCLUSÃO

Este trabalho teve como objetivo principal um mapeamento de parte de uma base de
dados colaborativa e comunitária utilizada majoritariamente por desenvolvedores de software
e/ou stakeholders envolvidos no domínio do assunto em questão, para entender quais são os
desafios e as potenciais soluções no uso da arquitetura de microsserviços.

De modo bem geral, microsserviços descreve projetos de software como conjuntos de


serviços que tem implementação distinta, independente e com controle descentralizado.

A arquitetura de microsserviços ganhou popularidade nos últimos anos e, portanto, não


pode ser considerada uma arquitetura madura. Alguns autores consideram que ainda não há
um consenso sobre o que realmente seja microsserviços, o consenso tem sido apenas nos
benefícios que essa arquitetura tem sobre a arquitetura monolítica.
Todavia, como ainda não é madura há um número de desafios que precisam ser
superados. Este trabalho discute alguns desses desafios e as possíveis soluções dadas por
44

desenvolvedores de software no site StackOverflow, considerado um dos mais confiáveis para


a colocação de problemas e a busca por resposta a estes problemas – feitas e dadas por
desenvolvedores.
A motivação desse estudo está relacionada à importância de identificar os problemas
mais relevantes enfrentados por desenvolvedores em seus projetos e atividades profissionais
no contexto de microsserviços, e servir como um arcabouço de conhecimento concreto sobre
as maiores dificuldades dos desenvolvedores e/ou stakeholders, em relação a este novo estilo
arquitetural.

Durante a realização do trabalho, foi encontrada diversas dificuldades, entre elas a


mudança de tema devido a grande abrangência do assunto, e depois pela falta de conteúdo
suficiente para embasamento. Também houve dificuldades na conciliação de tempo para se
dedicar a pesquisa.
Este trabalho sofre de várias limitações, não somente devido ao pouco tempo no uso de
microsserviços, mas também porque, devido à sua novidade, talvez ainda existam perguntas
que precisam ser feitas no seu uso em aplicações diversas, dispositivos que podem usar essa
arquitetura e transição da arquitetura monolítica para a de microsserviços. Dentre as
limitações, este trabalho também sofre por ter usado todas as soluções dadas pelos usuários do
stackoverflow e não ter levado em consideração se a mesma havia sido bem votada.
45

6 REFERENCIAS

AMARAL, O. , CARVALHO, M. Arquitetura de Micro Serviços: uma Comparação com


Sistemas Monolíticos. (2017).

BALALAIE, Armin et al. Microservices Migration Patterns. Software: Practice and


Experience. 48. 10.1002/spe.2608. (2015).

BARREIROS, H. Análise da completude dos relatos de experimentos em elasticidade na


computação em nuvem: um mapeamento sistemático. 2015. 147 p. Dissertação de Mestrado –
Universidade Federal de Pernambuco, 2015.

BROWN, Kyle G. Além de palavras da moda: um breve histórico sobre padrões de


microsserviços. 2016. Disponível em <ibm.com/developerworks/br/> Acesso em 12 mai
2019.

DOERRFELD, B. From monolith to microservices: Horror stories and best practices. 2018.
Disponível em <https://techbeacon.com/app-dev-testing/monolith-microservices-horror-
stories-best-practices> Acesso em 9 jun 2019.

DOELLING, Chase. Monolith to microservices: The Cloud Elements experience. 2017.


Disponível em <https://dzone.com/articles/monolith-to-microservices-the-cloud-elements-
exper> Acesso em 16 jun 2019.

GALDINO, Fernando. SOA, API, Microsserviços: onde aplicar cada uma dessas
modalidades? 2017. Disponível em <https://www.linkedin.com/pulse/soa-api-microsserviços-
onde-aplicar-cada-uma-dessas-galdino-pmp/> Acesso em 29 mai 2019.

JAMSHIDI, Pooyan et al. Microservices: The road so far and challenges ahead. IEEE
Software, May-Jun 2018.
46

JUSTINO, Yan. Microsserviços (e/é) SOA? Medium, 2018. Disponível em


<https://medium.com/@yanlimaj/microsserviços-e-é-soa-1497b34c47ef> Acesso em 15 jun
2019.

LEON, A. F. Don’t believe the hype! SOA AND MSA are not the same. 2017. Website.
Disponível em:
<https://www.academia.edu/34828240/Dont_believe_the_hype_SOA_AND_MSA_are_not_t
he_same> Acesso em 29 mai 2019.

LEWIS, J., FOWLER, M. Microservice Resource Guide. 2014. Disponível em: <
https://www.martinfowler.com/microservices/> Acesso em 3 mar 2019

LEWIS, James; FOWLER, Martin. Microsserviços em poucas palavras.(2015). Disponível


em: <https://www.thoughtworks.com/pt/insights/blog/microservices-nutshell> Acessado em
11 de jun de 2019.
.
LUCIO, João Paulo Duarte. Análise comparativa entre arquitetura monolítica e de
microsserviços. 2017. (Monografia). 56 p. Departamento de Informática e Estatística,
Universidade Federal de Santa Catarina, 2017.

MACHADO, G. M.: Micro Serviços: Qual a diferença para arquitetura monolítica? (2017).
Disponível em: < https://www.opus-software.com.br/micro-servicos-arquietura-monolitica/

NAMIOT, Dimitry; SNEPS-SNEPPE, Manfred. On Micro-services architecture.


International J. of Open Information Technologies, v.2, n.9, 2014.

PEREIRA, Murillo de Miranda et al. Arquitetura baseada em microsserviços. The Open


Software Engineering Journal, Dec 2018.

RODRIGUES, A. B.: Uma Abordagem Gradativa de Modernização de Software Monolítico


e em Camadas para Serviços. Dissertação de Mestrado. 85 p. Universidade Federal de
Pernambuco, 2017.
47

SAVCHENKO, D.I. et al. Microservices validation: Mjolnirr platform case study. Mipro,
2015

SPOLSKY, Joel. The Stack Overflow Age. (2018) Disponível em:


<https://www.joelonsoftware.com/2018/04/06/the-stack-overflow-age/> Acesso 11 jun 2019.

TAIBI, Davide et al. Processes, motivations and issues to migrating to microservices


architecture: An empirical investigation. IEEE Cloud Computing, Set-Oct 2017.

THÖMES, J. IEEE software, 2015 – ieeexplore.ieee.org. Disponível em: <


https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7030212 >