[deprecated]

Olá, como vai você. O novo período de hibernação se deu pela necessidade de esperar os novos direcionamentos da Microsoft se solidificarem e agora com o RC do ASP.NET vNext, há muito a rever e repensar no Oragon Architecture.

Oragon Architecture em 2014

A versão 7 do Oragon Architecture está em produção desde Junho desse ano quando concluí um grande refactoring. Infelizmente não tive apoio para implantar a versão 7 do projeto no iMusica por questões políticas. Atualmente a iMusica usa um fork da versão 6 do projeto, que oferece muitos recursos interessantes. Por conta das novidades da plataforma .Net, resolvi não fazer nenhuma outra evolução no projeto nesse ano. Agora, no finalzinho do ano, temos uma visão clara de como irão ficar as coisas em 2015, portanto podemos partir para uma nova corrida para a entrega de novas features.

Application Hosting

Uma das principais features da versão 7 é a hospedagem dinâmica de aplicações. Um host process que tem a capacidade de hospedar diversas aplicações, cada uma em um AppDomain isolado, gerenciado. Quando construí o hosting me preocupei com algumas reclamações recorrentes da comunidade, principalmente relacionado ao Spring.Net. Ao invés de remover o projeto, resolvi permitir a hospedagem de aplicações que não são baseadas em outros containers.

Olhando por um ponto de vista macro, a intenção era que você, no setup do Oragon Architecture Application Hosting, definisse um feed NuGet ou Chocolatey como repositório de aplicações do seu parque de produção. Você escolheria 1 dos servidores de produção para implantar o Management Console, geraria um par de chaves e com base nesse par de chaves, você faria a instalação de diversos AppHosts em outros servidores de produção. Cada AppHost (windows service) se comunicaria com o Management Console, que basicamente é um windows service com um WebApp de gerenciamento self hosted. Com ele você faria a gestão dos seus AppHosts espalhados pelos diversos servidores do seu parque, ou ainda externos a ele, como na núvem, por exemplo.  Do Management Console você inicializaria, e instalaria aplicações dinamicamente em qualquer um dos AppHosts registrados no Management Console.

O processo de instalação usaria o bom e velho NuGet, configurado para trabalhar com o padrão do Oragon Achitecture (apenas paths de setup). Seu time de desenvolvimento precisaria apenas, ao final do desenvolvimento, publicar um pacote NuGet no feed NuGet de produção, que poderia ser um MyGet público ou privado, ou mesmo um ProGet, ou qualquer outro host NuGet que o servidores possuíssem conectividade, inclusive File System. Uma possibilidade, que estudei na época era hospedar um NuGet Host no Oragon Architecture, mas achei demasiado, ter de cuidar sozinho, dessa implementação também. Resolvi evitar a criação de um monstro, me restringindo a trabalhar com um feeds NuGet, sem me preocupar com algum novo modelo de empacotamento.

O que está pronto?

O Application Host está pronto, suportando qualquer container. A extensibilidade dele ficou muito legal. É muito simples suportar um novo container aqui estão os exemplos para Ninject, SimpleInjector e Spring.Net. O Management Host também está pronto, mas precisa de retoques na interface gráfica, em suma, acabamento. A comunicação entre o Management Console e o AppHost está funcionando, mas ainda falta criar um canal de publicação de configurações (atualizações em dinâmicas) e troca de dados de monitoramento. A intenção é criar um protocolo aberto para a troca de mensagens, para que além das mensagens nativas e dados de monitoramento nativo do Oragon, tenhamos dados customizados de acordo com o cliente ou processo hospedado. Por exemplo, se você está hospedando uma aplicação que faz leitura de dados de uma fila, nada mais justo que mostrar a taxa de processamento dessa aplicação. Esse seria um dado exclusivamente do cliente, o Oragon deve fornecer a infraestrutura para a troca e exibição dos dados mas a coleta e a exibição devem ser configurados na aplicação hospedada e no Management Console.

Spring.Net

Esse assunto é sempre polêmico, mas vamos ao que interessa: Não está certa a estratégia do Spring Source e Pivotal a respeito do Spring.Net. Tentei falar com alguns dos desenvolvedores mais ativos do projeto e não tenho tido resposta. A princípio é estratégico pensar em outra alternativa. O problema é encontrar um bom substituto. Embora usemos quase que exclusivamente IoC/DI, AOP e Services, a maior diferença está na forma de trabalhar, e na flexibilidade de uso e configuração. A maturidade do projeto é herdada do projeto Java, e esse é o real ganho para a comunidade .Net. A maturidade de um framework que é standard na maior plataforma concorrente. Até a transição é bem simplificada.

Alternativas ao Spring.Net

Bom, ainda não fiz as avaliações necessárias para saber se há viabilidade no port do Spring.Net para o ASP.NET vNext Runtime ou não. De qualquer forma, seria muito interessante poder usar o Spring.Net em aplicações .Net Cross Platform, essa feature ainda daria fôlego ao projeto.

Eu tenho interesse em criar um fork do Spring.Net para implementar o suporte ao vNext, mas depende diretamente do entendimento do esforço e viabilidade da tarefa. Isso ainda não ficou claro para mim. Ainda tenho outros pontos no Oragon que são dependentes do Common Language Runtime, como os AppDomains. Preciso entender como isso funciona no Linux.

A história do Spring.Net mostra que nesse momento o projeto está quase que parado. Apenas a correção de alguns bugs, mas não há um roadmap definido, nem novas features, nada. Por esse aspecto, fica bem difícil pensar na longevidade da parceria, portanto é viável e quase que saudável substituir o Spring.Net. Com as inúmeras variáveis, é necessário determinar os requisitos mínimos e escolher um container bem aceito pela comunidade, ou ainda, escolher tornar o projeto independente de implementações específicas, ou com suporte a diversas implementações. Ainda não está claro o caminho que trilharei, mas está claro que o momento é de apreensão.

O que esperar de 2015

O ano que chega representa um marco para o projeto. As últimas implantações demandaram features bem interessantes, e essas estão sendo incorporadas, aos poucos, ao projeto. O suporte ao MongoDB, Redis, RabbitMQ são novas, mas são extremamente robustas, e dão novas capacidades de escalabilidade nas aplicações que desenvolvemos com o Oragon Architecture. Essas features estão no hype da evolução da plataforma .Net no sentido do Open Source e na criação e suporte a ambientes híbridos, onde mesclamos as melhores soluções do mercado para criarmos uma rica infraestrutura de serviços. Para 2015 a intenção é investir na comunidade, no site do projeto, em documentação. Até março teremos a versão final do vNext saindo e com isso poderemos ter uma visão clara, se investiremos na utilização do novo runtime do vNext.

Para 2015, espere também, uma aproximação com Azure e Amazon AWS, quero trabalhar com o suporte a hospedagem de apps em cloud e quero suportar ambos.

Agradecimentos

Esse ano muita gente viu o projeto, muita gente opinou. Alguns usuários internacionais aderiram ao projeto e estou muito orgulhoso dos resultados obtidos no iMusica. Não há uma comunidade, apenas usuários isolados, soltos pelo mundo. Mesmo assim é extremamente gratificante, principalmente por não possuir nenhum nenhum material em língua estrangeira.

Obrigado a todos os que recorrentemente aparecem aqui, em breve vou fazer um post dedicado aos agradecimentos de 2014.

Enquanto isso, um grande abraço a todos!