Kevin Webber palestrou na Conferência Reactive Summit 2017 mês passado sobre a migração de aplicações Java empresariais para a nuvem utilizando técnicas como Event Storming, Domain Driven Design e Cloud Native.
Ele começou a apresentação afirmando que o software empresarial possui integrações complexas e continua a ser construído fragmentadamente como aplicações, em vez de sistemas. As infra-estruturas tradicionais são ativas/passivas com uma tolerância a falhas imperfeita e oferecem suporte a uma replicação de estado complexa entre sistemas ativos e passivos.
As primeiras decisões que um arquiteto deve tomar ("A primeira milha") em um projeto de modernização são críticas. Ele expôs decisões importantes de arquitetura e apresentou como tomar essas decisões guiadas pelos princípios do Domain-Driven Design. Ele explicou que o Event Storming tem a função de reunir os principais stakeholders em um ambiente colaborativo para definir os processos de negócios envolvidos e apresentou como traduzir esses processos em sistemas orientados a eventos. As equipes devem se concentrar nos eventos mais interessantes que ocorrem atualmente no negócio.
Outros conceitos como a camada anti-corrupção (ACL) e o padrão Strangler também são úteis na migração de sistemas legados para sistemas reativos.
A arquitetura-cebola se encaixa perfeitamente nos conceitos do Domain Driven Design. Nesta arquitetura, as seguintes camadas podem ajudar na implementação de diferentes aspectos:
- Infraestrutura: podemos utilizar essa camada para implementar requisitos transversais como health check, rastreamento e autenticação.
- API: útil para roteamento e validações de dados
- Domínio: responsável por gerenciar o contexto limitado de uma camada
- Núcleo: é aqui onde gerenciamos os Aggregates
Webber discutiu o que significa ser uma aplicação Cloud Native. As aplicações precisam ser empacotadas em containers, gerenciados dinamicamente e orientadas a microserviços.
Webber também falou sobre a arquitetura de microserviços e recomendou que as equipes comecem com os modelos monolíticos e utilizem microserviços como uma técnica de refatoração para decompor os sistemas em várias partes. O modelo de microserviços ajuda não apenas sistemas distribuídos, como também equipes distribuídas.
Muitas equipes se concentram em decompor os sistemas no nível de serviço, mas deixam a camada de dados acoplada. Com esta arquitetura, qualquer mudança no modelo de dados causa impacto em vários serviços.
A InfoQ falou com Kevin após a conferência para saber mais sobre a migração de aplicações Java para infra-estruturas em nuvem.
Ele disse que se microserviços tiverem alguma interação ponto a ponto, seria caótico em termos de governança de serviços. É importante ter em mente que se um microserviço muda e outro é afetado, então eles não são microserviços e ambos devem ser combinados em um único serviço.
A composição de microserviços pode ser conseguida com o modelo PubSub usando um servidor como o Kafka para publicar eventos na fila e depois armazenar no Event Log Store usando um banco de dados NoSQL como Cassandra.
Para mais detalhes sobre esses tópicos, os leitores podem efetuar o check-out do mini-livro do Webber da O'Reilly, Migrando Java para a Nuvem.