"galho"E isso que estou falando! Cada Microsservico e um modulo COMPLETAMENTE independente. E podem haver diversas instancias de cada microsservico, dependendo da CARGA que cada um esta suportando. Isso se chama: "Curadoria de Microsservicos".Os consumidores dos microsservicos podem criar servicos especiais, que agregam ou criam fluxo de conversacao, baseados nos recursos, e estes "agregadores" podem ser executados diretamente pelos Clientes, nao requisitando tempo de processamento do "backend".Microsservicos podem ser "coreografados"Em vez de usar "Orquestradores" caros e "Componentes Transacionais" consumidores de recursos, podemos criar um sistema baseado em Eventos! Cada instancia de microsservico pode ser configurada para consumir e postar eventos, executando suas atividades quando demandada. Isto se chama de "Coreografia" de servicos.E os criticos dirao: "Mas e como controlar uma transacao distribuida?" Cara, 2-phase commit e coisa do passado! Se voce "cultua" essa porcaria, entao va visitar um museu! Os Eventos podem ser encadeados em fila e desfeitos em fila. Um Microsservico pode manter log de suas transacoes e desfaze-las sob demanda. E ninguem garante que transacoes distribuidas, entre EJBs rodando em diferentes nos, sao uma boa solucao.Microsservicos sao baseados em REST e, portanto, "Stateless". Manter varios componentes "aguardando" um sinal verde para "comitar" os dados, e coisa dos anos 70! Voce precisa repensar sua arquitetura. Este Artigo apresenta solucoes mais leves e compativeis com os novos tempos.Utilizar EJB por que tem que ter "componentes transacionais" e desculpa de quem nao estuda, quem nao se atualiza, e de quem quer manter o "status quo", acima da real necessidade dos Clientes.Nao e so programar diferente! Sua aplicacao tem que ser entregue em um fluxo continuo, dentro de "Containers" imutaveis, desta forma, toda a infraestrutura de TI que voce necessita, e virtualizada, e entregue como parte do seu produto, evitando "configuration drift" e problemas causados por intervencoes manuais.Nao basta construir o software de maneira moderna, e preciso entrega-lo de acordo com os padroes do Seculo XXI.E voce deve empregar algum tipo de servico de Curaroria, para ter elasticidade nos seus servicos, reduzindo custo (quando necessario) e melhorando a experiencia do usuario, atraves da escalabilidade elastica.Solucoes como o Eureka, da Netflix, ou o ServKeeper, permitem esse tipo de Entrega continua. E assim que fazemos e nao vemos razao para mudarInfelizmente, e assim que as pessoas agem, mesmo os profissionais mais novos de idade, que deveriam ser mais flexiveis, ja saem "agarrados" nas "tetas" de certos frameworks e padroes, e, talvez por medo, empregarao as mesmas tecnologias em seus projetos, resistindo fortemente a qualquer sugestao diferente.Cabe aos Empresarios e Gestores, ou seja, os que "metem a mao no bolso", rejeitarem tecnologias, frameworks e ferramentas com quase 20 anos de uso (ou mais). E preciso exigir oxigenacao, e nao confiar cegamente no "pessoal de TI".Entao, quando o software, finalmente, estiver pronto, depois de uns 30 Sprints, varios meses de espera e milhoes de dolares gastos, voce constatara que seus concorrentes ja estao trabalhando de forma diferente, se adaptando melhor as constantes mudancas no Mercado, e voce, que mal acabou de implantar seu carissimo Software, ainda esta discutindo com o pessoal de TI por conta de bugs e