Quarkus chega na versão 1.0: Um bate papo com Thomas Qvarnstrom

O Quarkus, um framework Java nativo Kubernetes feito para o GraalVM e OpenJDK HotSpot, chegou na versão 1.0. O Quarkus visa trazer o Java para a era do desenvolvimento cloud native e fazer com que o Java se torne uma plataforma líder para ambientes serverless, cloud e Kubernetes, oferecendo aos desenvolvedores um modelo de programação reativo e imperativo unificados.

O Quarkus traz um framework full-stack que usa uma série de bibliotecas usadas pelos desenvolvedores Java, tais como o Eclipse MicroProfile, e Vert.x. A injeção de dependência do Quarkus é baseada no CDI, permitindo que os desenvolvedores usem JPA/Hibernate, JAX-RS/RESTEasy, e mais. Além disso, o Quarkus inclui um framework de extensões que permite que desenvolvedores de frameworks terceiros possam estender o Quarkus, o framework de extensões também compila para binário nativo do GraalVM.

Na era do cloud, na qual containers, Kubernetes, microservices, functions-as-a-service (Faas) e aplicações cloud native estão entregando altos níveis de produtividade e eficiência, o Quarkus surge como uma alternativa muito interessante.

O InfoQ conversou com Thomas Qvarnstrom, gerente de produtos sênior na Red Hat, para aprender sobre a jornada do Quarkus, compatibilidade com versões anteriores, extensões e a direção futura do projeto.

InfoQ: O Quarkus, liberado pela primeira vez em março, é um framework muito jovem. Poderia compartilhar a jornada da primeira versão até a versão 1.0?

Thomas Qvarnstrom: Por vários anos, a Red Hat vem pesquisando como é possível melhorar o Java em containers, impulsionado por nosso grande investimento e adoção do Kubernetes e Red Hat OpenShift pelos clientes. Inicialmente, nos concentramos em melhorar o próprio Java Runtime (JVM) e nossas bibliotecas middleware, e a maior parte desse trabalho foi disponibilizada no OpenJDK e em outras comunidades. No caso do OpenJDK, a Red Hat iniciou com o Java 11 e depois implementou tais melhorias no Java 8, melhorando o desempenho e diminuindo o uso de memória. Entretanto, algumas das funcionalidades mais importantes da JVM, como executar uma vez e implantar em qualquer lugar, não fazem sentido para uma aplicação que é implantada dentro de um container imutável.

Ao executar fora de um container e com acesso quase ilimitado à memória, a sobrecarga

da descoberta dinâmica de classes nunca foi um problema, e essas funcionalidades são usadas frequentemente em frameworks como o CDI e o Spring DI. Entretanto, as tendências dos últimos anos de containers e arquiteturas distribuídas fez com que essa sobrecarga se tornasse um problema. Houveram novos frameworks e runtimes nos últimos anos, mas a maioria simplesmente foi colocada em cima do stack existente (JVM, frameworks). Tivemos que repensar completamente a stack para tornar o Java um cidadão de primeira classe no Kubernetes. Na Red Hat, estávamos experimentando com técnicas diferentes, como compilação AOT e compilando byte code para um executável nativo. Em 2018 iniciamos um projeto de pesquisa interna para ver como poderíamos combinar esses esforços. Um dos requisitos mais importantes para isso era não exigir uma reescrita total dos frameworks existentes.

O sistema de extensão do Quarkus foi projetado para permitir que os frameworks existentes otimizem o runtime JVM assim como resolver limitações de compilação do código Java para um executável nativo linkado estaticamente. Ao mesmo tempo, outro projeto open source, o GraalVM, começou a ganhar atenção, e parte dessa atenção foi devido ao compilador nativo. Entretanto, uma das desvantagens com um executável nativo criado com o GraalVM era que o comportamento dinâmico em runtime da JVM usado pelos os frameworks mais populares não era suportado. Com o uso do sistema de extensão do Quarkus para otimizar frameworks, foi possível portar rapidamente frameworks como o Hibernate (JPA), RESTEasy, CDI, Camel, Narayana (Transaction), Undertow (Servlet e Web), Vert.x, e o Eclipse MicroProfile. Com base no sucesso do projeto de pesquisa, a Red Hat criou o projeto open source Quarkus. O baixo uso de memória e a inicialização rápida foram somente alguns dos benefícios obtidos com o Quarkus. Outros benefícios também foram incluídos desde o ínicio com o Quarkus, como o live coding, no qual os desenvolvedores podem continuar trabalhando sem ter que esperar o redeploy, e a combinação dos estilos de programação reativo e imperativo.

Nos últimos oito meses o Quarkus têm tido um tremendo sucesso, e as 8-10 extensões iniciais cresceram para 80 diferente extensões, incluindo coisas como clientes Kafka, OpenID Connect, MicroProfile APIs, Spring APIs, etc.

InfoQ: Agora que o Quarkus chegou à versão 1.0, os desenvolvedores podem esperar compatibilidade com versões anteriores? Existem planos para manter a compatibilidade com versões anteriores em lançamentos futuros?

Qvarnstrom: Queremos equilibrar entre inovação e compatibilidade com versões anteriores. Ambos são importantes para os usuários, mas as vezes não é possível introduzir novas funcionalidades sem substituir o legado. Antes da versão 1.0, nunca separamos mudanças que sabíamos que poderiam quebrar a compatibilidade das que não quebrariam. Com a versão 1.0 teremos mais cuidado em não adicionar mudanças que sabemos que quebrarão a compatibilidade e assim vamos esperar até tem um release significante. Entretanto, o foco da comunidade do Quarkus continua sendo a inovação, e esperamos a mesma cadência de versões como antes da versão 1.0. Para ajudar o ecossistema a ficar maduro, introduzimos a noção do status da extensão: preview ou stable. Uma extensão marcada como preview estará livre para quebrar a compatibilidade de acordo com sua necessidade, enquanto as extensões estáveis manterão a compatibilidade com versões anteriores.

Da perspectiva do usuário, versões com quebra de compatibilidade serão comunicadas de maneira mais clara e serão mais raras.

InfoQ: No início deste ano, na QCon SP 2019, Sanne Grinovero fez uma apresentação sobre o Quarkus e falou sobre algumas restrições relacionadas a Reflection e I/O. Você pode explicar com mais detalhes algumas dessas restrições no Quarkus? Quais são seus planos para resolvê-los no futuro?

Qvarnstrom: Sanne falou sobre restrições ao produzir um executável nativo usando por exemplo o GraalVM, especialmente ao compilar um framework que confia na descoberta dinâmica de classes, configuração e etc, da JVM. Sanne também mostrou como é complicado e complexo superar alguns desses problemas sem o Quarkus. O Quarkus não só ajuda a superar as limitações de executar o Java como uma imagem nativa, como também abraça essas limitações, facilitando a solução de maneira a produzir um aplicativo ultra eficiente, independentemente se você o executa em Java ou como um executável nativo.

InfoQ: Existem mais de 80 extensões Java otimizadas que suportam compilar uma aplicação para um binário nativo. Em sua opinião, quais extensões os desenvolvedores precisam conhecer?

Qvarnstrom: Um dos maiores benefícios com o Quarkus é que os desenvolvedores não precisam aprender novas APIS uma vez que a maioria das APIs que os mesmos têm usado podem ser utilizadas sem mudanças. Por essa razão, os desenvolvedores podem ser produtivos imediatamente. O Quarkus, no entanto, adotou e inovou além das APIs conhecidas anteriormente, incluindo itens como Panache, uma melhoria no JPA que permite o uso do pattern active record.

Outra inovação é o MicroProfile Reactive Streams que foi inicialmente implementado no Quarkus/SmallRye e então implementado na comunidade MicroProfile. O próprio recurso de extensão também é interessante e permite que os usuários criem suas próprias extensões, o que é útil para organizações com desenvolvimentos maiores, nas quais padrões comuns baseados em código e configuração podem ser compartilhados entre equipes como extensões.

InfoQ: Em particular falando sobre extensões, o Hibernate é um framework ORM bem conhecido, e sabemos que foi necessário bastante trabalho para que o Hibernate estivesse pronto para o Quarkus. Você poderia compartilhar que tipo de mudanças foram necessárias?

Qvarnstrom: Além de usar o sistema de extensões para solucionar os problemas discutidos acima, a equipe do Hibernate também dedicou muito tempo movendo a maior parte do trabalho que era realizado anteriormente na inicialização da aplicação para o momento da construção da aplicação, resultando em um tempo de inicialização muito mais rápido e no baixo uso de memória.

InfoQ: Quais são os principais desafios na constante evolução do Quarkus? Vocês tem recebido muitas submissões de extensões?

Qvarnstrom: Existem várias extensões para as quais os desenvolvedores externos têm contribuído, mas que foram otimizadas pelos desenvolvedores da Red Hat. Como em várias comunidades, o direito de aprovar alterações no código (pull requests) do Quarkus tem como base um modelo de confiança, baseado no histórico de contribuições, antes de uma pessoa receber acesso para aceitar as mudanças de código. Durante os últimos meses, "promovemos" contribuidores externos para poderem revisar e aprovar mudanças. Este é um marco importante e, para nós, um sinal da maturidade da comunidade.

Um desafio da expansão do ecossistema de extensões é verificar a qualidade das extensões. Para isso, estamos analisando um sistema de classificação para que os usuários finais possam ver a qualidade antes de adicioná-la às suas aplicações.

 

InfoQ: O que há no horizonte para o Quarkus? Existe um roadmap que você pode compartilhar?

Qvarnstrom: Estamos pensando em adicionar mais extensões, como Spring Security, Spring Config, gRPC client/server, clientes JDBC e NoSQL adicionais, um template para views, melhorias nas APIs de programação reativa, Panache reativo, observabilidade aprimorada, ferramentas CLI, etc. Também estamos buscando fornecer uma experiência aprimorada ao desenvolvedor para o desenvolvimento orquestrado por container, no qual estamos investigando como expandir a funcionalidade de live coding para fornecer uma maneira de fazer codificação ao vivo remota diretamente em um container. Mas tudo isso está sendo discutido pela comunidade enquanto falamos.

InfoQ: Tem algo mais que você gostaria de dizer para os leitores do InfoQ?

Qvarnstrom: Se você ainda não o fez, por favor visite Quarkus.io e teste você mesmo. Vários usuários iniciam construindo aplicações usando frameworks que são familiares, como MicroProfile, Vert.x, e Spring Boot. Então ficam surpresos em como ficam produtivos com o live coding, o quão rápido a aplicação inicia, a pouca memória utilizada, e a riqueza do ecossistema de extensões. E claro, por favor compartilhe sua experiência, boa ou má em quarkusio.zulipchat.com.

Sobre o entrevistado

Thomas Qvarnstrom é gerente de produtos sênior para Runtimes Middleware na Red Hat. Está com a Red Hat desde 2007, ocupando uma série de cargos dentro do grupo Red Hat JBoss Middleware. Thomas está baseado na Suécia. Encontre-o no twitter em @t_millstream.