Microservices - o que se ganha e o que se perde

Nos últimos 2 anos me incomodou a forma como a buzzword microservice foi usada em tantos lugares. Falta uma definição clara e falta um entendimento de microservice como estilo arquitetural. Falta ainda entender os tradeoffs envolvidos (nas formas mais usuais de microservices).

Esse incômodo me levou a escrever dois blog posts que compartilho com vocês. Comentários e questões aqui ou no blog SATURN são bem-vindos! 

Microservices Beyond the Hype: What You Gain and What You Lose

Defining Microservices

Exibições: 703

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Thiago Moreira em 11 abril 2016 às 18:22

O fato de termos poucos materiais que citam a definição de microserviços é que essa é uma estratégia arquitetural que veio do mercado e não das academias. Por isso não se tem muita coisa.

Há uma outra definição, não citados neste artigo. Trata-se do fato de que microservices é opção de um estilo mais barato do que SOA. Isso é o fundamental que eu tenho lido sobre na internet. Startups precisavam de uma solução mais barata para trabalhar com serviços e Microservice virou essa opção. Uma das principais diferenças entre esse dois tipos de estilos é que SOA tem inteligência em comunicação e Microservices tem uma comunicação muda resumindo-se apenas a roteamento das mensagens. Obrigado pelo seu artigo. Realmente muito bom!

Comentário de Victor Fonseca em 3 dezembro 2015 às 19:28
Comentário de Victor Fonseca em 3 dezembro 2015 às 18:29

Eu criei uma apresentação para ajudar na definição de micro-serviços. Na verdade ela me ajuda na fala, claro, não é tão informativa sozinha. Mas enfim, segue: http://pt.slideshare.net/VictorFonseca4/caminho-para-definir-micros...

Eu vou apresentar ela em Curitiba amanhã, e pretendo se der fazer mais algumas apresentações ainda esse ano sobre o tema.

Comentário de Leonardo Cruz em 8 novembro 2015 às 23:00

Ótima serie de artigos, acho que abre caminho para uma discussão com vies arquitetural como todas deveriam ser. Gostei muito da distinção entre autonomia de design e de execução, pois muitas vezes vejo generalizações sobre as vantagens dos microservices que não levam em consideração estas duas perspectivas.

Em relação à SOA, tenho a impressão que foi muito baseada em produtos comerciais, trazendo soluções pesadas e complexas que, para a maioria dos casos, eram desnecessárias. Microservies, no contexto do pensamento lean, acabam sendo um contraponto a esta visão. Mas por mais que queiramos ser "ágeis" e "enxutos", os desafios do desenvolvimento baseados em serviços continuam lá e precisam ser tratados de forma adequada. Talvez o ESB não mereça morrer.

Comentário de Paulo Marcio Brandi Rezende em 7 novembro 2015 às 21:38

Continuando, e agora vou tentar me ater aos artigos. O texto "Defining Microservices" me fez reavaliar meu pré-conceito de que microserviços é SOA com outro nome. Talvez microserviço seja algo realmente bem diferente de SOA. E talvez seja realmente um estilo arquitetural completamente novo, diferente de quase tudo que estamos acostumados. Ou pelo menos do que eu estou. 

Como você bem disse, Paulo Merson, é preciso avaliar o tradeoff de aplicar esse novo estilo arquitetural. Acho que a avaliação deve começar pelo seguinte: se uma aplicação monolítica conseguiu sobreviver por muito tempo mesmo sendo monolítica, então pode ser que seja vantajoso fazer a decomposição da mesma usando qualquer outra técnica, menos micro-serviço. Digo isso porque se essa aplicação pertencesse ao mundo micro-serviços são realmente necessários, ela não teria sobrevivido sendo uma aplicação monolítica. 

Fica muito difícil imaginar o Facebook gerando um .war quando alguém criou o botão de "like" ou a Amazon gerando um .war para poder disponibilizar uma nova forma de pagamento.

Mas também fica difícil imaginar decompor um sistema como uma SAP da vida em microserviços com 100 linhas de código, com base de dados própria, que não participam em composição de serviços mais complexos, que são desenvolvidos por times cada um usando uma linguagem de programação diferente, sem realizar comunicação síncrona, e que além disso tudo ainda pode ser jogado fora e rescrito em duas semanas.

Comentário de Paulo Marcio Brandi Rezende em 7 novembro 2015 às 21:16

Toda minha vida eu trabalhei com sistemas de uso corporativo, softwares acessados apenas por usuário internos para dar suporte ao negócio da empresa de alguma forma. Sendo assim meu "mind set" arquitetural acabou sendo fortemente influenciado por esse contexto, por esse mundo. Eu não faço ideia de quais são os estilos arquiteturais mais adequados para sistemas de automação industrial ou software embarcado, por exemplo. E estou apenas começando a caminhar no mundo das aplicações mobile.

Onde eu quero chegar com tudo isso é que também não faz parte do meu mundo pensar em soluções de arquitetura para aplicações como Facebook, Instragram, Twitter, Amazon, eBay, etc.

Eu sou aberto a mudanças, acho que a forma de "fazer software" evolui e tem que continuar evoluindo. Mas ao mesmo tempo eu vejo micro-serviços como algo mundo bom para ser aplicado num tipo de software que não faz parte do meu mundo. A aplicação de técnicas ágeis no mundo corporativo causou mais resultados positivos do negativos. Eu não estou falando de nada especifico como Scrum, XP, etc. Eu me refiro ao fato de que hoje vemos os usuários de negócio recebendo funcionalidades importantes num espaço de tempo menor, em comparação com projetos que duravam meses, as vezes anos, e não somavam nenhum valor ao dia-a-dia da empresa. Isso só foi possível aprendendo com gente que fazia software para outras finalidades. 

Mas dito tudo isso, a verdade é: eu não faço aplicação que é acessada por milhões de usuários, e que precisa estar preparada para ser acessada por bilhões. Eu não faço aplicação que precisa ser deployada várias vezes ao dia. Eu não faço aplicação que precisa estar distribuída em nível global. 

O fato de eu poder aprender muito com a experiência de empresas como Google, Amazon, Facebook não significa que eu tenha que fazer as coisas do jeito que eles fazem.

Acabou que não falei muito sobre os artigos do Paulo Merson, então acho que haverá uma segunda parte dos meus comentários.

Comentário de Henrique Lobo Weissmann em 7 novembro 2015 às 10:56
Parabéns pelo post: sem sombra de duvidas uma das melhores coisas que já li a respeito! Precisamos de mais material assim.

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço