[deprecated]

Para quem trabalhou comigo no BTG Pactual viu no Oragon Architecture o início do Oragon Architecture Services, que consistia em uma camada de abstração para a criação de serviços baseados em WCF, ainda configurado side-by-side com a configuração de WCF do .Net Framrwork.

Para atender às demandas da B2W Viagens, não tivemos muita evolução, mas para atender à BRQ, o host WCF do Spring foi estendido para no Oragon Architecture Services, e nesse ponto, não era mais necessário usar configurações padrão do .Net Framework para hospedar serviços WCF. Migrei a solução toda para do framework 3.5 para o framework 4.0 e criei uma infraestrutura de hospedagem dinâmica de processos, para que você não tenha de ficar criando diversos projetos, um para cada deploy. Agora você construía uma única biblioteca de serviços e um executável padrão, externo, era capaz de interagir com sua biblioteca, hospedando seus Service Facades em diversos protocolos. O deploy passava a ser apenas uma escolha entre configurações.

Sempre nessa linha de viabilizar a tomada de decisão mais tardia possível, seguimos com novas features. Cada empresa demandou algum esforço nesse projeto, visto que já faz algum tempo que aposto na visão de serviços como chave para o sucesso no quesito design.

No iMusica esse modelo atendeu muito bem, estamos usando muito toda essa infraestrutura, mas não foram só flores. Estamos hospedando aplicações gigantescas, com uma quantidade de processamento substancial. Muitas threads, muitos serviços, muitas operações simultâneas. Estamos consumindo muitos recursos de infraestrutura e aplicação, embora ainda não estejamos no máximo, vamos em alguns meses ou mesmo anos, chegar ao nível de processamento em que poucas máquinas não suportarão a necessidade de processamento demandada pelo parque.

Chegou o momento de pensar em escalar ainda mais, pensando em grid de máquinas, pensar em alocar máquinas dinamicamente, e escalar ao infinito! #SQN Claro que temos limitações, na prática se reduzirmos a quase Zero os recursos compartilhados, sim, seria possível sim.

Pensar em suprir essa demanda é algo extremamente excitante e divertido. A paixão pelo que se faz não vem por acaso, a conclusão de uma tarefa dessa magnitude é realmente um grande feito pessoal e profissional. Lado-a-lado com essa infraestrutura um marco importante para o meu trabalho no iMusica: Pensando exclusivamente em ingestão de conteúdo, estas features melhoram muito nossa perspectiva de futuro.

Fato é que estou muito excitado com o rumo do projeto e já estou desenhando um modelo de federação de processamento baseado em Worker Process distribuídos em máquinas. Não pensei com carinho suficiente, mas talvez possa até ser cross domain (para que possamos usar o melhor dos mundos, ambiente cloud local, side-by-side com cloud pública).

O modelo atual, embora tenha ajudado muito, é eficiente e eficaz quando pensamos em poucas instâncias, com gerenciamento manual. Quando pensamos em grid, e cross domain, pensamos em escalar inclusive o deploy. Por esse prisma, vejo hoje pontos de atenção quanto à utilização do modelo atual.

Hoje por exemplo precisamos nos preocupar com:

• Cuidar de cada deploy, máquina-a-máquina
• Gerenciar quantas instâncias do mesmo processos vamos rodar em cada uma dessas máquinas
• Existem processos que não podem rodar em mais de uma instância, pois ou duplicam processamento ou agridem a performance do parque
• Gerenciamento de dependência de serviços entre máquinas

Todas essas preocupações não existem quando pensamos em deploys em uma ou duas máquinas, mas quando pensamos em um parque com dez, ou vinte máquinas executando processamento pesado, esses cuidados de gestão passam a ser algo crítico. Levando em consideração que estamos consumindo muitos recursos para conseguir entregar uma solução robusta e escalável, gerenciamento não poderia em momento algum ser algo negligenciado. E admito, desde o JBoss 5, tenho o interesse em construir um servidor de aplicação, acredito que ao final desse projeto, tenha no Oragon Architecture, algo bem parecido com um Applciation Server.

Esse é um projeto que deve demandar alguns muitos meses, e muitas noites mal dormidas, e não poderia faltar, contratempos! Bom, terei muito esforço pela frente, mas é necessário, pois quero entregar com esse projeto:

• Hospedagem e gerenciamento dinâmico de serviços, com aumento e redução de Workers dinamicamente (entre máquinas)
• Hospedagem e gerenciamento dinâmico de escutas de filas (entre máquinas)
• Hospedagem e gerenciamento dinâmico de agendamentos
• Permitir deploy centralizado e distribuição automatizada entre os diversos servidores
• Permitir fácil gerenciamento entre ambientes (Quais máquinas processam quais ambientes)
• Gerenciamento facilitado de informações de log e debug.

A primeira tarefa a ser realizada é mapear os requisitos e analisar as possibilidades. Já esbocei um target, mas ainda não tracei um caminho. Ainda assim, algumas promessas já podem ser feitas:

• Continuaremos usando Spring.Net
• O código do Oragon Architecture continuirá no GitHub, open source.
• Vai possuir uma bonita e funcional interface gráfica
• Só será entregue quando estiver realmente funcional
• Continuaremos usando muito AOP

Aos que tiverem a intenção de participar da concepção e/ou desenvolvimento, as portas estão abertas!

Grande abraço!