Duvidas sobre microservices

Voce pode ter um projeto com vários microservices, cada microservice é um endpoint. Pra ter autenticacao, dependendo do requisito, pode usar basic auth mesmo, aí na chamada ele precisa passar um usuario e senha (Ex: curl -u user:user -X GET localhost:8080/bla/bla?q=1)
O Spring Boot é apenas um framework facilitador pra trabalhar com o Spring framework, nele vc pode usar Spring MVC pra criar seus microservicos, ou Jersey, ou qualquer outra coisa.

Seguinte:

Item 1 : nada impede que você tenha microserviços públicos. O requisito de autenticação ou não é uma decisão de negócio (ou sua).

Item 2: conceitualmente, um micrososerviço deveria ser auto suficiente, para ser escalável, etc. Neste caso, sim, o ideal é ser SOLID (S = Simple Responsability).

Item 3: a implantação fica a seu critério, na sua arquitetura.

Item 4: sim, caso contrário poderá ter conflitos.

Espero ter ajudado.

concordo com você FabioQB, no login eu vejoque o melhor seria utilizar SSO(Single Sign-on), já deve ter alguma implementação boa no mercado, tem uma ferramenta que a muito quero testar para microservices OAUTH-2.0 . Eu penso que microservices se encaixa melhor em um contexto distribuido, com cluster, utilizando um container javaEE full como jboss configurarando o AJP com load balancing, estilo um Netflix, agora montar tudo isso para rodar em um servlet-container não vejo com bons olhos, para um tomcat da vida prefiro apps monolíticas.

JBoss EAP ou IBM WAS ou Weblogic. Não fuja destes.

Com certeza não, só não curto o fato de o porque não implementam JavaEE7

Porque existem os famosos early adopters, como Wildfly, Glassfish e IBM Liberty Profile, que lançam versões FREE para comunidade mundial testar (gratuitamente), eles corrigirem bugs e posteriormente lançaram suas versões Enterprise ($$).

Versões Enterprise requerem maturidade do produto, pois as empresas vendem seus softwares com suporte.

É algo que venho pesquisando, e cheguei a ver alguns casos de uso com o Spring Boot, que sinceramente fico até espantado de como é aplicado coreografia e orquestração em tudo isso. Alguns casos onde são utilizados tomcats embedded, com vários JARs com responsabilidades únicas (clientes, produtos, pedidos, relatórios e etc), bancos de dados únicos e expondo diferentes endpoints e cada JAR dentro de um container Docker.

Utilização de replicação assíncrona baseada em eventos usando message broker, de API Gateway e por ai vai.

Alguém já chegou a trabalhar, ou estudar que seja um cenário parecido?

Como manter a integridade das informações em um cenário distruído assim?

@fabioqb , o nome do conceito é S.O.L.I.D, pois cada letra é outro conceito. O S é Single Responsability, que diz respeito a responsabilidade única. Segue um artigo bacana sobre SOLID: http://www.itexto.net/devkico/?p=1105

Oi @fabioebner, tudo bem ?
Antes de pensar em como fazer, é entender o conceito por trás dos microserviços e sua real necessidade. Já vi pessoas caminhando por esta estrada sem qualquer necessidade, apenas porque virou “moda”. Então uma anális sucinta do negócio deve ser feita antes de pensar nesta arquitetura, que não é perfeita.

Leia este artigo do Martin Fowler sobre microserviços, é ótimo: http://martinfowler.com/articles/microservices.html
Respondendo de forma superficial suas dúvidas:

1. Depende do seu negócio. Será uma URL pública ? Que tipo de dados estarão expostos ? São duas perguntas simples, mas para tu ter ideia de como vai buscar a resposta;

2. Não. Se você tem que replicar dados você não tem microserviços. Cada microserviço deve ter uma única responsabilidade, deve executar uma única tarefa. Então se tu tem um microserviço que gerencia seus usuários, qualquer outro serviço que precisar de informações de usuários vai consultar este microserviço, mas não para ficar replicando dados. Óbvio que você pode salvar informações em comum, mas não uma replicação por inteira;

3. A disponibilização vai depender de sua necessidade. Eu ouvi boatos que a Netflix disponibilizava/disponibiliza todos os seus microserviços no mesmo servidor, agora, se era no mesmo container eu não sei. De qualquer forma, tu tem que avaliar. Se tu concentra todos os microserviços em um únio container, tu tem um único ponto de falha. Se precisar parar e subir ele, você derruba todos os microserviços, por exemplo. Eu sempre sou a favor de ter tudo separado, servidor, container e etc, isolar por completo um microserviço, porém, já passei pela experiência do custo que estava cada dia mais elevado, principalmente porque era pago em dólar. Cada instância era mais dinheiro e assim sucessivamente. Portanto, é mais uma análise que você deve fazer, analisando os prós e contras;

4. Sem dúvidas. Como vai subir 3 containers na porta 8080 no mesmo computador ? Eu não consigo visualizar como. E óbvio, quanto mais microserviços na mesma máquina, mas do hardware será exigido;

5. Não sei te responder pois nunca usei e trabalho com os mesmo, apenas com o Wildfly pois usava JEE full.

Abraços e espero ter ajudado.

3. Acredito que colocar tudo em uma máquina só elimina grande parte das supostas vantagens de uma arquitetura de micro-serviços, como a escalabilidade horizontal de serviços específicos.

No geral, o hype em torno de micro-serviços me parece exagerado demais. Tudo o que li a respeito me parece apenas uma roupagem nova para um assunto velho: componentização.

@esmiralha eu penso que um problema clássico, que não vale apenas para microservices, é a famosa “bala de prata”. Quando surgiu o conceito de REST, eu li muito sobre “matem o SOAP e migrem para REST!”. Não funciona assim, não mesmo.

O microservice nasceu principalmente devido as arquiteturas SaaS, mas e as empresas que vendem produtos on premise ? Sim, aqueles que instalamos na “casa do cliente” ? O que eu já vi são pessoas ou times que implementam conceitos simplesmente pelo fato de ser novo e acharem “legal”, sem antes executar todo um levantamento, com POCs e afins para avaliar os reais ganhos, os prós e contras. É por estas e outras que lá no futuro (que pode ser curto, diga-se de passagem), encontram problemas sérios ao invés de soluções.

O artigo que citei acima do Martin Fowler é bem bacana e fala sobre isso. Tem um do Robert Martin que fala sobre isso também, bem interessante.

@nel Se o artigo do Uncle Bob for o mesmo que eu li (sobre um compilador FORTRAN na década de 60), achei uma postura muito sóbria com relação a mais uma “grande novidade do verão”.

Partilho da mesma idéia que você, ainda tem outras questões que devem ser analisadas antes de decidir por este modelo de arquitetura , ex: a view, se você tem mais de uma app web servindo a serviços diferentes não escapa de uma replicação de código na parte da view. Outro ponto são as conexões com o database, um SSO é necessário para gerenciar os usuários e seus diferentes papéis na aplicação como um todo. Hoje em dia o pessoal sai divindo a aplicação em várias partes e acredita estarem utilizando microserviços mas não é assim, no próprio post do Fowler ele diz em outras palavras que: se você não tem o negócio bem definido, que se você não tem uma equipe de seniors onde você possa expor suas idéias, onde todos compartilhem conhecimento e principalmente por no papel é um projeto destinado ao fracasso.

Valeu @nel pela explicação.

Concordo com vcs, sempre antes de um projeto tem que levantar todos requisitos e analisar sempre a melhor solução. Nunca vai existir uma tecnologia que seja uma “bala de prata”. Meu caso foi mais pesquisas sobre e achei bastante interessante o conceito.

Por exemplo, sei que o padrão de integração “Shared Database”, não é um dos mais recomendados, muita gente fala que hoje não se utiliza mais devido a ‘n’ problemas. Porém, teve uma situação em uma aplicação onde este padrão me resolveu um problema de um cliente. E esta funcionando a anos já sem problemas.

Então tudo é questão de analisar.

Oi @esmiralha, o artigo é este aqui: http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html
O que gostei foi o final dele: “Don’t leap into microservices just because it sounds cool. Segregate the system into jars using a plugin architecture first. If that’s not sufficient, then consider introducing service boundaries at strategic point.”

Em particular “sounds cool”. Que é exatamente o que comentei anteriormente.

Vale a pena ler esse aqui também: https://blog.8thlight.com/uncle-bob/2015/05/28/TheFirstMicroserviceArchitecture.html

Tava vendo um tiozinho da programação funcional explicando o que é um micro-serviço. Segundo ele, é um serviço com “micro” na frente. Achei honesta a explicação.

Então, sem me estender, um forma bacana de análise é o DDD (Domain Driven Design), no qual tu defini por regiões teu software. Estas regiões/fronteiras devem estar absolutamente bem definidas antes de pensar em seguir para microservices.

Quanto mais sólida sua base estiver, maiores as chances de sucesso e menores as chances de dores de cabeça.

Quem tem máquinas pra operar in-house, ou em um datacenter, e quer usar microservice, provavelmente está aderindo ao conceito só por modismo. Microservices é para aplicações que rodam em instâncias efêmeras na nuvem.

Hmmm, para mim essa “nuvem” pode ser privada e nada mudaria. O ponto dos “micro-serviços” é poder implantar e escalar partes da solução de forma independente. Você pode fazer isso em uma infra interna sem maiores problemas, se tiver virtualização e automação.

O ponto dos microservices é facilitar o gerenciamento e escalabilidade de aplicações na nuvem. Se você desenvolve sua própria nuvem, certamente não tem problema nenhum o fato dela ser privada, apesar que não é realista esperar que desenvolvedores de soluções tenham knowhow pra criar sua própria infraestrutura de rede e servidores virtuais (nuvem). Isso é trabalho para gigantes como Amazon, MS e IBM.

Um container JavaEE full é uma aplicação monolítica, seus componentes não escalam de maneira independente. Por esse motivo imagino que devem ser péssimas opções para microservices.

O mesmo vale para SGBD tradicionais, e de fato, banco de dados NoSQL são mais populares neste segmento microservice/nuvem.

Existem muitas empresas no setor financeiro que trabalham com virtualização há muito tempo, inclusive em plataforma mainframe. A própria IBM tem seu foco em soluções de cloud híbridas, porque grandes empresas de diversos setores não estão preparadas ou interessadas em mover seus workloads para infraestruturas públicas de terceiros. Cloud privada é e continuará a ser uma opção para grandes corporações por muito tempo.

Mas isso já é desvio do assunto original…

Não tem nada de errado em compartilhar banco de dados. Eu faço isso direto para queries, ao invés de ter que fazer um serviço depender de outro, só pra ter acesso a alguma informação.

O problema é que na maioria dos sistemas, não existe separação entre queries e comandos, e o banco de dados é visto como um repositório de dados. Nesse modelo, quando diferentes serviços tentam atualizar o mesmo banco, existe a possibilidade de introduzir dados inconsistentes sob o ponto de vista de um serviço específico, e isso causar bugs na sua aplicação. No caso, a solução é você adotar um modelo diferente, onde queries e operações que podem alterar o estado do sistema são separados. Existem várias técnicas e tecnologias que te ajudam a reforçar essa separação na sua arquitetura. Ex: CQRS, Datomic.

Concordo com vc @pfk66

Para informação: