WebLogic, JBoss e o Java legado: o deserto de quem quer manter o que paga as contas

Enquanto conferências celebram microsserviços e Kubernetes, boa parte da receita de bancos, governo e indústria ainda roda em Oracle WebLogic, JBoss / WildFly, IBM WebSphere ou pilhas equivalentes, com servidores web na frente (Apache, IIS, HTTP Server embutido) e integrações que foram escritas há quinze ou vinte anos.

O problema humano

Recrutar quem domina deployment descriptors, filas JMS, datasources XA e o ciclo de vida de EJB não é só caro — é raríssimo. Muitos desenvolvedores associam “legado” a carreira estagnada; gestores temem parar features para “só manter o que funciona”. O resultado é concentração de conhecimento em poucas pessoas e risco operacional alto.

Problemas técnicos recorrentes

Versões de Java e do servidor de aplicação fora de suporte, patches de segurança acumulados, heap e GC mal dimensionados, thread pools esgotados sob pico, e integrações com mainframe ou SAP que ninguém mapeou por completo. Em WebLogic, clusters mal configurados geram sessão inconsistente; em JBoss, módulos e classloader ainda confundem quem veio só do Spring Boot.

Caminhos realistas

Documentar o mínimo viável (fluxos críticos, dependências, janelas de deploy), estabilizar com correções pequenas e mensuráveis, e alinhar um plano de estrangulamento do monólito (anti-corruption layer, extração de serviços por domínio) sem “big bang”. Alocação de perfis híbridos — quem conhece legado e quem traz práticas modernas — costuma ser o meio-termo que sustenta o negócio até a próxima geração de sistema.