Oportunidades na modernização das aplicações

A Situação

A modernização de aplicações é a palavra da moda, assim como Devops, SRE ou Cloud Native. O termo significa coisas diferentes para pessoas diferente, pergunte a um engenheiro de plataforma e ouvirá dele que a modernização é como a mudança de VMs de nuvem privada para nuvem pública.

Já um desenvolvedor explicará a modernização como conteinerização para aplicações legadas. Um arquiteto de software pode definir modernização como a refatoração de uma aplicação para microsserviços utilizando a abordagem 12 factor/15 factor.

Todos os principais fornecedores corporativos estão com pressa para ajudar as empresas a modernizar as cargas de trabalho em todas as camadas da pilha IaaS, CaaS e PaaS. Como decompor essa oportunidade de mercado?

Existem várias condições de mercado em jogo que acionam a refatoração e a atualização de aplicações para a nuvem e para o cloud-native.

1. Middleware Legado

Uma porcentagem significativa das aplicações dos clientes são legadas não nativos da nuvem, executados sob frameworks sem microsserviços em servidores proprietários. Essas aplicações podem ser monolitos em Struts com lógica de backend rodando em um WebSphere ou um WebLogic.

A pesquisa Jakarta EE Developer indicou que 85% dos usuários padrões utilizam paradigmas de programação de mais de 3 anos atrás e quase 50% de 7 anos atrás para mais. Aplicações monolíticas em servidores legados retardam o lançamento de novas funcionalidades e aumentam significativamente o tempo de espera.

Os desenvolvedores estão cansados de esperar de 1 a 5 minutos para que uma aplicação inicie, e frustrados por executar os testes de laços de repetição que os vincula a estruturas JavaEE e bibliotecas de servidor de aplicações antigas. O problema de inicialização das aplicações foi amplamente resolvido nas variantes modernas de todos os servidores, no entanto, leva tempo para migrar as aplicações existentes para estruturas mais recentes como o Eclipse Glassfish ou o OpenLiberty.

Fonte: Jakarta EE Developer Survey 2020

Os servidores proprietários de aplicações representam um custo e são os sistemas vitais de uma empresa. Os especialistas em servidores de aplicações migraram para as áreas de infraestrutura e desenvolvimento e encontrar uma equipe de TI para manter esses sistemas está se tornando custoso. Os sistemas e o servidor de aplicações e as versões do JDK não são atualizados, levando a desafios de auditoria e governança. Aplicações Java construídas baseadas nos frameworks J2EE mais antigos, como Struts, EJBs, JAX-RPC, entre outros, são de difícil atualização e têm débitos técnicos acumuladoss, bem como as que usam serviços não conhecidos ou frameworks personalizados, desenvolvidos internamente para integrar essas aplicações.

2. Legados do Java

A maioria dos projetos corporativas em produção ainda estão em Java 8, Java 7 e Java 6 e estão sendo migrados para Java 11/14. Os clientes precisam de ajuda nessa migração para aproveitar as oportunidades de conteinerização fornecidos por versões posteriores do Java. Versões mais antigas impedem atualizações de plataforma e geralmente não são compatíveis com a perspectiva de memória dos containers, além do mais, são uma fonte de vulnerabilidades de segurança.

Fonte: Jakarta EE Developer Survey 2020

3. Legado do Spring

O Spring Framework e o Spring Boot são os frameworks de microsserviços Java preferidos das empresas. A falta de práticas de CI/CD e de governança de arquitetura de aplicações levaram as empresas a utilizar nas aplicações as versões mais antigas do Spring Framework (<5) e do Spring Boot (<2). As empresas precisam de ajuda para atualizar e corrigir as versões do Spring e este é um problema que ocorrerá quando o Spring Boot 2.1.x terminar o EOL em 1º de novembro de 2020 e o Spring Boot 1.x já tiver EOL em 1º de agosto de 2019, fatos que farão com que as empresas que possuem segurança rigorosa precisem atualizar o mais rápido possível as aplicações para as versões mais compatíveis do Spring e do Spring Boot. Versões mais antigas de ambos os frameworks impedem que as empresas usem os mais recentes, como spring-cloud e outros projetos spring downstream que aceleram o desenvolvimento dos microsserviços.

Fonte: Stack Overflow Trends

Existe uma oportunidade para automatizar o trabalho na migração do framework e dos componentes Spring Boot para as aplicações Spring existentes. Ao invés de ler e implementar um guia de várias páginas, os desenvolvedores podem executar um linter spring para atualizar os componentes.

4. De Monolitos a Microserviços e De Microserviços para monolitos modulares

Pesquisas recentes de desenvolvedores da Jetbrains e Jakarta EE confirmam que os microsserviços são a arquitetura líder para implementação de sistemas Java na nuvem. As empresas ainda estão tirando água de pedra dos monólitos. Domain Driven Design e técnicas de modelagem, como SWIFT, Wardley Maps e Bounded Context Canvas forneceram técnicas heurísticas e de negócios para criar microsserviços. Porém, há uma reação emergente da complexidade dos microsserviços e um ímpeto de avançar para arquiteturas de implantação mais simples, como os monólitos modulares. Para maiores detalhes, veja o artigo "De microservices para monólitos - Por que a Segment retrocedeu".

Existem lacunas significativas que as bibliotecas e os frameworks podem preencher, isso se a implementação levar em consideração as histórias de usuário de um backlog, implementações originadas de um event storming ou da decomposição de um monólito. Gerar um backlog de histórias de usuários à partir de event storming é uma obra de arte e requer muita ajuda através da facilitação, porque o DDD estará quebrado. É difícil dividir os frameworks de negócios em recursos de sub negócios e os microsserviços candidatos precisam de opinião especializada antes da implementação. As ferramentas e os frameworks de observação que ajudam a entender os metadados de tempo de execução de aplicações existentes emparelhados com um criador de perfil, teoricamente, têm as informações necessárias para fazer recomendações sobre os pontos de partida para a decomposição de monólitos. Uma ferramenta que começou a olhar para esse problema foi a vFunction.

Fontes: JetBrains Developer Survey, Jakarta EE Developer Survey 2020

A combinação da instrumentação de criação de perfil, métricas de CI/CD e medições de SLO pode orientar a racionalização de microsserviços, analisando métricas como taxa de falha de alteração. Este é um processo pesado para o facilitador e conduzido por workshops como o "Should That Be A Microservice?" (Isso deveria ser um microserviço?).

5. Fragmentação no Java EE, Jakarta EE e Eclipse MicroProfile Microverse

O Eclipse e a Oracle não chegaram a um acordo sobre os termos do namespace e das marcas registradas do pacote javax. Como resultado, todas as aplicações JavaEE agora devem migrar para o Jakarta EE e os fornecedores dos servidores estão correndo para adicionar suporte desta tecnologia nos servidores. O Jakarta EE está decolando. As aplicações desenvolvidas no namespace javax podem ser executados sem alterações no TomEE, OpenLiberty e em outros com transformador eclipse que reescreve referências de Jakarta EE 8 para a versão 9 e inclui patch plug-ins que fornecem transformação de bytecode suplementar baseada em ASM para lidar com os casos extremos. A outra opção é recodificar as aplicações usando as APIs Jakarta EE usando ferramentas como tomcat-Jakarta EE-migration.

Para empresas mais conservadoras, a transição de Java EE para Jakarta EE requer um esforço de teste de regressão, implantação em servidores de aplicações de fornecedores mais novos, reescrita de bytecode OU reescrita de todo o código para resolver a confusão criada pela Oracle. As empresas têm outras frentes para investir, ao invés de ficar se preocupando com a compatibilidade funcional ou a regressão para uma nova versão do Jakarta EE e isso representa uma oportunidade para ferramentas e/ou produtos adicionais neste espaço.

Fonte: Transition from Java EE to Jakarta EE

O Eclipse MicroProfile está evoluindo a um ritmo mais rápido do que o Jakarta EE. Seis releases principais do MicroProfile com dezesseis releases de componentes em menos de dois anos, enquanto JavaEE/Jakarta EE está evoluindo a uma taxa de consenso entre os organismos padrões. Parece que a maior parte da inovação no espaço de padrões ocorrerá primeiro no montante do MicroProfile e, em seguida, chegará ao Jakarta EE. Em um futuro previsível, o Eclipse MicroProfile será separado e construído sobre o Jakarta EE, é o que Kevin Sutter, co-líder Eclipse MicroProfile e membro EE4J PMC aborda no artigo "What's next for MicroProfile and Jakarta EE?".

Até que o Jakarta EE tenha demonstrado um processo de especificação que permite os aspectos rápidos e inovadores do projeto MicroProfile, ele manterá a própria dinâmica de projeto distinta dos projetos EE4J.

Fonte: What's next for MicroProfile and Jakarta EE? (Eclipse Newsletter)

A fragmentação da API entre as estruturas Jakarta EE e Eclipse MicroProfile com diferentes taxas de mudança oferecem uma oportunidade de simplificação.

6. VMs para containers / Kubernetes (V2C/V2K)

Este é o Santo Graal dos fornecedores de Kubernetes. Uma ferramenta que cria containers de forma "automágica" a partir de VMs. Não apenas containers de sistema, mas de nível de aplicação que têm conhecimento do middleware interno. Uma ferramenta que pode descobrir, analisar e reempacotar aplicações existentes para aproveitar a elasticidade, tolerância a falhas, densidade e atualizações/correções oferecidas pela nuvem. Uma ferramenta que entende as aplicações e as estruturas específicas de linguagem para container e constrói as imagens eficientes conteinerizadas em cache da camada de OCI certa. Essa ferramenta é semelhante a um unicórnio mágico.

Há uma variedade de ferramentas que auxiliam na construção de imagens de forma segura a partir das fontes como S2I, Cloud Native Buildpacks e plugins maven como jib e maven/gradle build-image. Porém, isso requer algum tipo de intervenção manual. A modernização de bottom up impulsionada pela infraestrutura adora lidar com a produção sem falar com os desenvolvedores, preferencialmente com zero alterações no código e com o mínimo de risco. Os engenheiros de plataforma sonham com um VM2containers ou um produto VM2kubernetes que atenda às necessidades da equipe de infraestrutura, permitindo-lhes atualizar a produção de forma massiva e com mínima intervenção do desenvolvedor. O Google Anthos Migrate e o Docker se esforçaram muito para resolver esse problema. A Amazon também se juntou recentemente à festa e introduziu uma série de ferramentas neste espaço como AWS app2container, docker2aws e o co-pilot que ajudam na conteinerização de aplicações para colocá-las no ECS e EKS.

Captação de Valor

Como os fornecedores podem aproveitar essas vantagens, criando um conjunto de produtos que atendem às necessidades ainda não atendidas e aos desafios enfrentados pelos desenvolvedores que buscam, hoje, a modernização das aplicações. Quais produtos podem permitir que os desenvolvedores migrem as aplicações para a arquitetura cloud-native e para os microsserviços mais rapidamente aliviando a dor descrita acima.

1. Cookbooks

1. Livros de receitas

Livros de receitas como "Modernização de Aplicações" e "AWS bem projetada", unidos à experiência e lições aprendidas de migração anteriores podem servir como um multiplicador de força quando se trata de adoção de um determinado framework e da produtividade do desenvolvedor. A documentação de padrões, que ajude os arquitetos, com uma abordagem bem estruturada para a modernização da aplicação, como um livro de receitas bem conceituado, fará com que os desenvolvedores não fiquem vagando pelo stack overflow, aumentando a produtividade na migração. O investimento no App Transformation Cookbook por um escritor dedicado alinhado a experiência de domínio da equipe de modernização de aplicações levará a uma aceleração da qualidade e quantidade de transformações, tornando mais fácil para os desenvolvedores comuns migrarem as aplicações para o cloud-native sem grande esforço de consultoria. Um conjunto de receitas de alta qualidade, catalogando a migração do framework dos componentes legados também servirá como projeto para ferramentas de transformação.

2. Super (reescrita) Linters

Falamos aqui de uma ferramenta de linha de comando empacotada como um linter ou um executável de linha de comando que fornece um mecanismo de reescrita e uma DSL para transformação de código. A ferramenta de reescrita atua como um super linter que automatiza a reformulação de aplicações legadas e reduz o débito técnico. O Rewrite Linter modifica diretamente os arquivos de origem, incluindo Java, XML e YAML usando uma biblioteca JavaParser para analisar arquivos Java de origem. As modificações são feitas diretamente na árvore sintática abstrata, de forma que o resultado seja sempre sintaticamente correto e serializado para persistência e compatibilidade. A intenção é automatizar o trabalho de reformulação para frameworks de microsserviços modernos deixando a aplicação em um estado compilável. Uma ferramenta que começa a implementar esse conceito é a OpenRewrite.

3. Interoperabilidade adversa

Esta é uma abordagem aproveitada por provedores de nuvem em hiperescala para oferecer APIs específicas de domínio ou produto, como Cassandra ou Mongo, mas tem a implementação interna fornecida por produtos nativos. Por exemplo, o Azure Cosmos DB fornece uma API para MongoDB aproveitando a compatibilidade do protocolo do MongoDB, todavia os frameworks como Upstart podem atacar os titulares desta jogada. Por exemplo, o Quarkus fornece uma camada de compatibilidade para injeção de dependência Spring na forma da extensão spring-di. A compatibilidade da API Quarkus Spring inclui Spring DI, Spring Web e Spring Data JPA, o que abre pontos de vulnerabilidade no processo principal. Para resolver esse problema, APIs Spring adicionais, como Spring Security e Spring Config, estão sendo projetadas e desenvolvidas. Para maiores detalhes, consulte Quarkus para desenvolvedores Spring.

Resumo

O desenvolvedor médio gasta 13,5 horas por semana resolvendo os problemas mais comuns. [Fonte - Pesquisa Stripe]. A manutenção das aplicações em produção e a modernização para a nuvem estão pressionando duplamente as equipes de desenvolvimento e plataforma. A modernização precisa ser escalonada de forma eficiente por meio de documentação, produtos e frameworks. É hora dos fornecedores intensificarem e as empresas investirem em "Migração e Transformação como Serviço" para acelerar a modernização parcial ou total das cargas de trabalho de aplicações para a nuvem. As empresas que se concentram na integração de cargas de trabalho para a nuvem enfrentarão as ameaças competitivas, melhorando a produtividade do desenvolvedor, reduzindo o débito técnico e utilizando a eficiência de custos e a flexibilidade da nuvem.

Sobre o Autor

Rohit Kelapure é especialista em migração de aplicações para a nuvem e modernização de sistemas de missão crítica. Rohit formulou o GTM, estratégias de marketing e produtos para a modernização de aplicações. Está melhorando continuamente as ofertas e sistemas para oferecer suporte a vendas, entrega e comunidades open source com o objetivo de gerar os resultados certos para o cliente. Contribui ativamente em blogs sobre cloud foundry, kubernetes, refatoração de monólitos e estratégias de modernização de aplicações. Seus webinars recentes incluem tópicos tão diversos como modernização de middleware, migração de mainframe e ferramentas e receitas para refatorar aplicações monolíticas em nuvem moderna. É especialista em tecnologias Spring e Java EE e cobriu ambos os tópicos extensivamente nos blogs WebSphere e All Things Cloud. Todas as opiniões são do autor e não do seu empregador.