Um dia o gerente de desenvolvimento chega a sua mesa e reporta que a era do seu Oracle Application Server (OAS) 10g chegou ao fim. Ele valoriza um relatório objetivo e visualmente agradável com análise de impacto de negócio bem enumerada e suficiente para que a renovação ou atualização de licenciamento seja uma necessidade imediata.
E se é você que precisa entregar este relatório bem fundamentado, quais os pontos para chegar a tal conclusão? Além disso, como através de diferenças técnicas você poderá apoiar o relatório para que sejam correlacionadas ao negócio? Essa publicação citará algumas diferenças e evoluções técnicas entre o OCJ4 e o Weblogic, de forma a gerar insumos que lhe darão motivações técnicas para impactar o negócio.
Resumidamente a história é a seguinte, a Oracle, até a versão 10gR3 de sua suíte de middleware, tinha, dentre os componentes que formam o OAS como contêiner JavaEE, o OCJ4. Com a aquisição da BEA em 2008, o contêiner foi substituído pelo Weblogic na versão 11g.
Isto pode parecer uma alteração simples, mas não é, e por se tratar de outro contêiner JavaEE, mudam, além de a atualização de versão dos componentes, o que já é algo preocupante, também a administração e interação das aplicações com o servidor de aplicação. Para o time de desenvolvimento, isso significa mais do que atualizar seu projeto dos frameworks utilizados, mas também identificar e estudar os métodos com que este novo contêiner irá interagir, seu plano e funcionamento de publicação e a estruturação diferenciada do processo. Em uma organização que utiliza as demais soluções da suíte, tais como, Forms & Reports, BI ou SOA a complexidade aumenta exponencialmente.
Em um comparativo técnico simples, o principal valor agregado na migração e que por si só já a justifica, ainda que não demonstre a relação de urgência, somente de importância, é a atualização da especificação JavaEE suportada, a última versão do OC4J tem compatibilidade completa com as especificações do JavaEE 1.4, enquanto o Weblogic12cR2 tem compatibilidade com as especificações JavaEE 7. Ou seja, isto permite ao desenvolvedor trabalhar com novas abordagens da linguagem, em uma versão com o Java mais recente e com novas features e correções de bugs que darão maior agilidade ao time e um aumento de performance significativo com relação as versões anteriores. Assim, ao não proceder com a migração, suas aplicações estão fadadas a descontinuidade ou legado.
Demais recursos do Weblogic com relação ao OC4J podem ser evidenciados na arquitetura, administração e configuração de recursos, managedservers e planos de implantação, ou seja, uma lista que pode ser obtida de acordo com o negócio da sua organização. Para tal, sugerimos realizar um comparativo baseado nas documentações dos produtos, pois as features que poderão ser relevantes a sua organização serão indiferentes a outras, cabe ao gestor responsável pelo processo de avaliação da migração julgar o que será aderente a seu time de desenvolvimento e operação.
Para motivações de negócios, consideramos s razões técnicas que consistem no uso de uma especificação atual que entrega performance, gestão e desenvolvimento de aplicações em um menor tempo, tais razões são de forma geral:
- Uma maior capacidade da equipe em desenvolvimento de novos recursos ou versões da sua aplicação;
- Possibilitar com o ganho de performance inclusive a revisão de recursos físicos ocupados pela sua camada de middleware de sua organização;
- Sem adicionarmos as relevantes alterações que a atualização traz ao seu negócio em específico.
Custo e método de migração
Vamos ao que viabiliza ou não uma migração: o custo. Apesar de os resultados positivos de uma atualização serem facilmente percebidos , o método de migração e a importância ao processo dado pela organização darão a variação do retorno sobre investimento (ROI), valor presente líquido (VPL), ou payback. Por este motivo, um plano de migração adequado, bem estruturado e planejado afetará os resultados diretamente.
A escolha do método...
A organização, ao contratar o Sustaining Support do Lifetime Support da Oracle, terá direito a atualização dos produtos de middleware sem custo adicional. Caso o mesmo não possua o Lifetime, terá duas opções:
- Pagar o retroativo do serviço de suporte/atualização e realizar a migração;
- Comprar uma nova licença.
Com um processo de migração orientado corretamente, com ferramentas do de apoio do fabricante e foco bem dimensionado do time de desenvolvimento e operação, reduzimos os riscos do projeto, mas também contribuímos para ele ser percebido positivamente na cultura da organização.
Referências:
Como última consideração ficam meus agradecimentos ao colega Joel Corrêa (joel.correa@ilegra.com), arquiteto de software na ilegra, que apoiou-me nas dúvidas relacionadas ao desenvolvimento. Ao colega Felipe Lindenmeyer (felipe.lindenmeyer@ilegra.com), executivo de contas na ilegra, que me amparou nas questões de licenciamento e custos.
Nenhum comentário:
Postar um comentário