A Red Hat lançou recentemente o Quarkus, um framework Java nativo para o Kubernetes, feito sob medida para o GraalVM e OpenJDK HotSpot.
Na era do cloud, no qual containers, Kubernetes, microservices, functions-as-a-service (Faas), e aplicações nativas para o cloud estão apresentando altos níveis de produtividade e eficiência, o Quarkus surge com uma alternativa muito interessante.
O InfoQ conversou com John Clingan, gerente sênior de produtos na Red Hat, e Mark Little, vice presidente de engenharia na Red Hat.
InfoQ: O Quarkus visa tornar o Java uma plataforma líder em ambientes Kubernetes e serverless. Como essa ideia surgiu? Quantos anos a Red Hat tem trabalhado nisso?
Red Hat: Red Hat é uma das organizações que identificou uma série de limitações ao usar a JVM em um container, e contribuímos continuamente para resolver algumas dessas limitações. Discutimos isso recentemente em um post no blog Red Hat Developer. Hoje em dia aplicações Java na JVM podem ser executadas sem problemas em containers, o que é visto por nossos clientes que estão usando essa combinação em produção. Entretanto, algumas limitações que podem ser difíceis de resolver em produção ainda permanecem. Um exemplo de problema de tais limitações é o tempo de startup inicial e consumo de memória requeridos para executar uma aplicação Java EE na JVM. Na Red Hat, estamos procurando por soluções similares como o compilador GNU para o Java, porém quando o GraalVM foi anunciado como parte da comunidade Java, vimos muito potencial para trabalharmos junto com a comunidade.
InfoQ: Qual foi a inspiração para a Red Hat criar o Quarkus?
Red Hat: Quando vimos a maneira como o GraalVM trabalha, percebemos que para aproveitar todos os benefícios, teríamos que adotar uma abordagem holística e pensar no problema não apenas no nível da VM, mas também no nível do framework. Ao construir aplicativos nativos em Java para o GraalVM, existem algumas limitações das quais o GraalVM se beneficia, principalmente em torno dos recursos mais dinâmicos do Java, como reflection. O problema não é tão difícil de resolver para aplicações com poucas ou sem dependências, mas rapidamente se torna esmagador quando se constrói uma aplicação Java EE. Os desenvolvedores tendem a usar vários diferentes frameworks. Um destes popular é o Hibernate, que é o framework de mapeamento objeto-relacional mais usado para facilitar o acesso ao conteúdo do banco de dados. Fazer o Hibernate executar de maneira ideal no GraalVM requer um profundo conhecimento sobre o Hibernate, e para fazê-lo efetivamente, também é necessário um conhecimento profundo da JVM e de como o GraalVM funciona. Durante um trabalho experimental, vimos a oportunidade de criar uma arquitetura comum na qual outros frameworks poderiam adotar o GraalVM mais facilmente. Usamos o sistema de extensão do Quarkus para suportar projetos como a implementação do Eclipse Microprofile (SmallRye) and RESTEasy. Essa lista atualmente contém cerca de 4 extensões e continua crescendo. O Quarkus acabou de receber sua primeira extensão do da comunidade, do swagger-ui. Isso resultou em um stack Java que é fácil de usar e muito familiar para desenvolvedores que estão usando o Java EE, MicroProfile, ou Spring.
InfoQ: Logo após o lançamento do Quarkus, foi anunciado que o desenvolvimento do Thorntail 4.x vai parar e que o Thorntail 2.x será suportado até novembro de 2020. Que tipo de impacto o Quarkus pode ter em outros fornecedores de middleware Java como o Payara e Tomitribe?
Red Hat: O Quarkus criou alguns recursos bastante inovadores, como a API de extensão, extensão do ecossistema, e unificou o modelo de programação imperativo e reativo. O maior impacto para os outros fornecedores ocorrerá no contexto do Eclipse MicroProfile, no qual colaboramos com a próxima versão das especificações Java EE. O MicroProfile está direcionando o Java nativo para o cloud. O Quarkus é um exemplo de como começar a direcionar cenários mais modernos de implantação nativa cloud com um modelo unificado de programação imperativa e reativa. Podemos combinar o que aprendemos com essas ideias no Quarkus com o que outras implementações (como Payara e Tomitribe) aprenderam para mover a indústria adiante através do MicroProfile e do Jakarta EE. É importante observar que precisamos ser inovativos antes de tentar criar especificações. Isso pode levar meses, se não anos, antes de uma ideia ser adotada em uma especificação, logo isso levará um tempo.
InfoQ: O que os desenvolvedores podem experar do Quarkus?
- Uma experiência voltada para containers, ideal para o Kubernetes
- Tempo de inicialização incrivelmente rápido, em milissegundos, que permite o uso do Java em ambientes serverless, suportando um ambiente mais responsivo e escalável.
- Até um décimo do tamanho de um processo Java padrão, o que permite que você tenha densidade muito maior, melhorando a elasticidade geral do sistema.
- Uma arquitetura que aplicações de 12 fatores, permitindo o desenvolvimento mais robusto e aplicações confiáveis.
- Diversão real para o desenvolvedor.
- Uma plataforma opinativa, bem integrada, suportando os modelos de programação reativo e imperativo.
- Baseado nos melhores padrões.
InfoQ: Linguagens que atualmente são suportadas no GraalVM, como o Scala e Python, podem ser usadas com o Quarkus? Se sim, poderia nos dar alguns exemplos? Se não, serão suportadas eventualmente?
Red Hat: O Java continua a ser linguagem principal em uso pelas empresas e clientes da Red Hat, e é aí que estamos concentrado a maior parte da nossa atenção hoje em dia. Incluímos o Kotlin além do Java, e observar o que a comunidade faz.
InfoQ: Poderiam nos dar mais detalhes sobre as métricas do Quarkus?
Red Hat: O Quarkus permite o monitoramento das aplicações através da implementação de métricas do SmallRye da especificação de métricas do Eclipse MicroProfile. Isso expõe um conjunto de métricas padrão para a aplicação, e ao mesmo tempo permite que o desenvolvedor adicione métricas customizadas. Todas as métricas estão acessíveis do endpoint /metrics. O Quarkus também vem com suporte a health-check .
InfoQ: O que está planejado com relação ao ciclo de lançamento do Quarkus?
Red Hat: Houve um tremendo interesse em Quarkus, por isso queremos ser o mais responsivos possível. Estamos entregando funcionalidades e correções de bugs aproximadamente a cada poucas semanas e continuaremos a fazê-lo até sentirmos que há feedback suficiente e o uso prático do desenvolvedor.
Um dos nossos principais objetivos é ajudar a comunidade com extensões. O Quarkus para nós é um ecossistema.
InfoQ: Vocês planejam manter a compatibilidade com as versões iniciais?
Red Hat: Retrocompatibilidade é muito importante para nós na Red Hat e para nossas comunidades, mas sendo um novo projeto com inovações acontecendo a todo momento, é muito cedo para garantir isso. Entretanto, estaremos trabalhando com a comunidade para determinar quando, por que e como.
A boa notícia entretanto é que o Quarkus se baseia nos ombros de gigantes: Hibernate, Vert.x, Camel, Netty, RESTEasy, etc. Todos esses frameworks são maduros com histórico de retrocompatibilidade. O Quarkus simplesmente expõe as APIS destes frameworks. Temos visto alguns membros da comunidade migrando aplicações Java EE para o Quarkus e tempo recorde.
InfoQ: Qual é o roadmap do Quarkus?
Red Hat: Em primeiro lugar, a comunidade é muito jovem e queremos ouvir o que as pessoas fazem e precisam do Quarkus.
Queremos que o ecossistema Java aceite essa nova mudança de paradigma, conforme o vemos como o futuro. Portanto, muito do nosso esforço está focado em garantir que estamos construindo extensões para os frameworks que os desenvolvedores usam.
Aqui que as coisas ficam difíceis. Lançamos o Quarkus em um estado em que ele tem uma visão e há muito a fazer para alcançá-la. Vamos listar os principais assuntos, mas vamos ter em mente que a comunidade e suas necessidades irão orientar o roteiro mais do que qualquer outra coisa:
- Serverless: baixo uso de memória e rápida inicialização torna o Quarkus um candidato perfeito para FaaS;
- Imperativo e reativo: Reativo é crítico em aplicações nativas cloud. Demonstramos onde queremos chegar com a unificação do paradigma dos modelos de programação. Agora é hora de aperfeiçoar. Por exemplo, estamos explorando maneiras de lidar com a persistência de maneira reativa non-blocking;
- Segurança: como lidar com os vários desafios de segurança que as empresas estão tendo que se acostumar? Aprendemos muito com o Wildfly e experamos boas coisas para o Quarkus em um futuro próximo;
- Containers e Kubernetes: uma aplicação não tem utilidade se não for implantada. Há muito valor que pode ser adicionado para suavizar a implementação de aplicações Quarkus em plataformas de containers e o Kubernetes em particular.
InfoQ: O que é a técnica compile time boot usada no Quakus?
Red Hat: Existem alguns truques, mas vamos explorar o que achamos serem os aspectos mais interessantes. Um ponto-chave do Quarkus é mudar muito do que os frameworks tradicionalmente fazem durante a inicialização e fazer isso acontecer no momento da criação: escaneamento do classpath, reflection, parse de configurações, obter metadados e construir os modelos, etc. Isso é incrível por alguns motivos:
- Esse trabalho é executado somente uma vez durante o tempo de compilação, e não toda vez que a aplicação inicia;
- Todo o código necessário para inicializar os frameworks que normalmente consumiria memória na JVM simplesmente não estão presentes no tempo de execução..
É dessa maneira que fazemos as aplicações Quarkus iniciarem e aceitarem requisições tão rápido, e como podemos espremer o máximo de sobrecarga de memória possível.
Outro aspecto interessante das extensões do Quarkus é que elas foram projetadas para ajudar o algoritmo de eliminação de código morto do GraalVM. o GraalVM está fazendo um trabalho fantástico na determinação de chamadas desnecessárias.
InfoQ: Qual é a melhor maneira para os desenvolvedores obterem o Quarkus? Existem formas preferidas de os desenvolvedores se envolverem com a comunidade e fazerem perguntas?
Para obter o Quarkus: Veja Getting Started Guide
Twitter: @QuarkusIO
Chat: Zulip Chat Room
Q/A: StackOverflow