Universidade Federal de Pernambuco Centro de …tg/2019-1/TG_CC/tg_tas4.pdfA arquitetura de...
47
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
Transcript of Universidade Federal de Pernambuco Centro de …tg/2019-1/TG_CC/tg_tas4.pdfA arquitetura de...
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).
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,
Figura 1 - Linha do tempo das tecnologias de microsserviços
Fonte: Jamshidi et al, 2018
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 PaaS3 (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
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).
Figura 2 - Comparação entre arquitetura monolítica e de microsserviços
Fonte: Fowler, 2014
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
migração
Outros
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
responsabilidades
da equipe
11 3 1 3 10 3
Suporte DevOps 8 3 2 1 6 3
Porque todos
estão fazendo
6 4 2 3 4 4
Tolerância a
falhas
2 4 2 4 / /
Experimentar
tecnologia fácil
2 3 2 3 / /
Delegação de
responsabilidades
do software
1 4 1 4 / /
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
Fonte: Taibi et al, 2017
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
migração
Outros
Total Média Total Média Total Média
Desacoplamento 7 3 / / 7 3
Migração da
base de dados e
separação de
dados
6 4 / / 6 4
Comunicação
entre serviços
4 3.5 2 3 2 3
Estimativa do
esforço
2 4 2 1 2 3
Infraestrutura
do DevOps
exigindo
esforço
2 4 / 4 / /
Esforço da
conversão da
biblioteca
2 4 / / 2 4
Mente das
pessoas
2 4 1 4 1 4
Retorno
esperado no
investimento
2 3 1 3 1 3
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
Fonte: Taibi et al, 2017
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.
Fonte: Taibi et al, 2017
Figura 3 - Estrutura dos processos de migração identificados
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 online7 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
FINALIDADE Com o propósito de Melhorar a compreensão
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
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.
Desafio Problema
Específico
Quantidade Descrição Solução
Segurança
Autenticação 18
Qual método utilizar para
garantir
autenticação usando
Microsserviços?
Usar XACML /
Usar Oauth / Usar
o Spring Security
Usar CORS /
Fazer autenticação
com banco de
dados
Controle de
Acesso 7
Como garantir controle de
acesso a
determinadas partes do
Microsserviços?
Usando ACL /
Usar JWT / Fazer
via API Gateway
Usar DMZ
35
Tabela 5 - Perguntas relacionadas a aplicaçã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
Específico
Quantidade Descrição Solução
Arquitetura
Banco de
Dados 4
Problemas específicos de cada
projeto Escolher melhor a arquitetura
Transação 1 Garantir consistência em transações Manda rever a arquitetura, pois existe
condições que ocasionam inconsistência
Gerenciamento 1 Garantir gerenciamento de
implantação Usar o Ansible ou o Chef
Desempenho 2 Como melhorar o
desempenho?(Paralelismo) Diz pra fazer de forma assíncrona
Comunicação 40 Compartilhar dados entre MS Cada MS deve ter seu próprio Banco de
Desafio Problema
Específico
Quantidade Descrição Solução
Aplicação
Testes 3 Como criar testes automáticos? Colocar os testes como uma das etapas do
fluxo
UI 2 Conectar UI com a aplicação Criar uma UI monolítica e conectar a
aplicação Microsserviço
36
Dados e usar o HTTP para compartilhar
os dados
Reduzir latência na comunicação Usar mensageria (PUB/SUB), RPC ou
THRIFT
Compartilhar estados entre MS Recomenda usar mensageria (PUB/SUB)
Comunicação entre os MS Usar o HTTP / Usar Firewall / Usar
mensageria (PUB/SUB)
Construção 23
Replicação de módulos Recomenda o reuso de módulos
Reduzir acoplamento na arquitetura
de MS Refazer a arquitetura
Reuso de código por outro MS Tratar como dependência externa
Problemas específicos de cada
projeto Refazer a arquitetura
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
Específico
Quantidade Descrição Solução
Banco de
Dados Arquitetura 11
Fazer o
compartilhamento
de dados
Usar um banco de dados
comum / Recomenda que cada
MS tenha seu próprio banco
Usar o banco de dados
no cliente, ao invés do
servidor
38
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.
Problema nos
relacionamentos do
banco de dados
para utilizar no MS
Manda rever a arquitetura sobre
como o banco foi dividido e as
relações mantidas
Consistência 7
Garantir
consistência dos
dados
Usar gerenciadores de
transações
Onde armazenar
tabela comum para
todos os MS
Replica a tabela
Sincronizar o banco
de dados entre os
MS
Usando JWT
Eliminar registro
fantasma
Criar um MS cuja função é
eliminar esses registros
Múltiplo
Acesso 1
Garantir múltiplo
acesso ao Banco de
Dados
Recomenda usar JDBC
Diz que não é possível
pois cada MS tem seu
próprio servidor
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
Desafio Problema
Específico Quantidade Descrição Solução
Migração
Arquitetura 14
Gerenciar os dados Usar cache distribuída
Fazer um MS reagir depois de receber
uma mensagem
Usar um framework para realizar
essa orquestração
Migrar mas manter os mesmo
endpoints
Escrever o MS e redirecionar as
chamadas
Banco de
Dados 6
Como migrar todo o sistema, sem
migrar o banco de dados?
Monitoramento 1 Melhor forma para se monitorar um
MS
Reversa 1 Como unir os MS para gerar um
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
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.
Desafio Problema
Específico
Quantidade Descrição Solução
Spring
Integration 1
Como obter um diagrama
gráfico de toda a camada de
integração
Instalar o plugin Spring IDE ou Spring
Tool Suite e realizar algumas
configurações
MVC 2 Configurar o Spring MVC
para fazer redirecionamento Manda refazer a configuração
Cloud 1 Compartilhamento de cache Manda usar um cache distribuído
HATEOTAS 1 Configurar o Hateotas Manda rever a configuração, pois é erro
de configuração.
Security 3 Não recebe a resposta da
autenticação
Manda rever a configuração, pois é erro
de configuração.
Boot 2 Gerenciar dependências Criar a dependência no maven
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 >
