Mark Little, vice president of engineering in Red Hat, ci racconta l’evoluzione di app e servizi Java grazie al supporto del framework Quarkus.
La struttura favorisce la migrazione di risorse codificate in Java verso un futuro che sfrutta i vantaggi derivanti dalla scelta di ambienti serverless, cloud e Kubernetes.
Se si dovesse spiegare in due parole cosa è Quarkus, si direbbe che è uno stack Java nativo di Kubernetes oppure, in maniera più estesa, potreste dire che è uno stack Java nativo di Kubernetes su misura per OpenJDK HotSpot e GraalVM, realizzato con le migliori librerie e standard Java per portare le applicazioni Java moderne verso il cloud container-centrico.
Oggi parte integrante di Red Hat Runtimes e con una prima versione stabile rilasciata a luglio 2020, Quarkus è palesemente open source e funzionalmente semplice in termini di costruzione e implementazione, in quanto offre un footprint e un tempo di avvio ridotti.
Quarkus e Kubernetes
Come tecnologia full-stack, Quarkus funziona sia a livello server-side che di applicazione client. È un framework Java nativo di Kubernetes per macchine virtuali Java (JVM), quindi fornisce un mezzo per programmare componenti applicativi virtualizzati in Java che utilizzeranno i vantaggi del sistema di orchestrazione dei container open source Kubernetes.
Come indicato, Quarkus si trova all’interno di Red Hat Runtimes, un insieme di prodotti, strumenti e componenti per lo sviluppo e la manutenzione di applicazioni cloud-native che offre runtime e framework per architetture cloud altamente distribuite, come i microservizi.
In termini di funzionalità di base, Quarkus compila nativamente e ottimizza il codice Java specificamente per i container, ecco perché è una piattaforma efficace per il mondo del computing astratto degli ambienti serverless, cloud e Kubernetes.
Ma ad un altro livello, Quarkus ottimizza anche gli stack Java non compilati, il che significa che gli sviluppatori otterranno ulteriori miglioramenti nelle prestazioni, anche quando si usa con OpenJDK cioè non compilato, che – essenzialmente – è il modo principale in cui Java è stato scritto per molti anni.
Quarkus deconstructed e Java – Facile configurazione per il divertimento degli sviluppatori
Se non proprio plug-and-play, Quarkus è ready-to-go. Progettato per operare con poca o nessuna configurazione, è pensato per coinvolgere gli sviluppatori e include funzionalità per eseguire il live coding in modo che sia possibile controllare immediatamente l’effetto delle modifiche al codice e risolverne rapidamente i problemi.
Gli sviluppatori possono scegliere i framework Java che vogliono per le loro applicazioni, che possono essere eseguite in modalità JVM o compilate ed eseguite in modalità nativa. Con Java che ha ormai un quarto di secolo di storia, Quarkus è un mezzo per attraversare l’abisso verso ambienti cloud-nativi, molti dei quali includeranno Kubernetes per l’orchestrazione dei container.
Ricordiamoci anche che Quarkus è realizzato a partire da librerie e standard Java ben noti, il che è una spinta positiva per l’adozione da parte degli sviluppatori a diversi livelli. I developer Java esperti sono abituati a lavorare con queste librerie, standard e metodologie di programmazione da oltre due decenni, quindi è importante che si sentano a loro agio con Quarkus, che sperimentino una curva di apprendimento minima e che ottengano il massimo dalla tecnologia stessa.
Java è stato così popolare per così tanto tempo che negli anni sono stati creati molti framework e utility familiari e ampiamente utilizzati. Essere in grado di assicurare che questi siano disponibili anche per gli sviluppatori di Quarkus è molto importante.
Modelli di programmazione reattivi vs. imperativi – Quarkus deconstructed e Java
Il co-fondatore di Quarkus, Jason Greene, è un ingegnere e manager di rilievo presso Red Hat. Greene ha detto che l’obiettivo di Quarkus è quello di rendere Java una piattaforma leader negli ambienti Kubernetes e serverless, offrendo agli sviluppatori un modello di programmazione reattivo e imperativo unificato per affrontare in modo ottimale una gamma più ampia di architetture applicative distribuite.
Questo equilibrio reattivo vs imperativo è importante, perché la programmazione reattiva ha molteplici vantaggi potenziali in termini di scalabilità rispetto alla tradizionale programmazione imperativa. Anche se quest’ultima rimarrà un elemento importante nella programmazione per il prossimo futuro, la capacità di lavorare con eventi di dati asincroni non sequenziali ha una forte applicabilità per il moderno sviluppo di applicazioni software cloud.
Un buon esempio qui sarebbe NodeJS e l’uso di serverless, che AWS ha reso popolare con la sua implementazione Lambda. È una questione di logica di business per il modello reattivo che è disponibile e pronto all’uso. Una logica di business che potrebbe anche non essere tenuta in memoria; ma la sua istanza può essere portata in produzione quando necessario.
Con l’uso crescente di microservizi applicativi che si spostano verso un approccio molto più reattivo, il team di Quarkus voleva offrire agli sviluppatori entrambe le capacità. Ma, allo stesso tempo, desiderava che Quarkus facesse appello agli sviluppatori che realizzano ambienti imperativi, dove il modello è appropriato al caso d’uso.
Quarkus deconstructed e Java
Il modello imperativo è – in un certo senso – uno strato superiore che si trova sopra qualsiasi modello reattivo, una relazione strutturale che possiamo vedere in Internet stesso, che è sempre stato molto reattivo nella sua natura.
Quarkus si trova nella piattaforma di applicazioni container open source Red Hat OpenShift 4.6. Red Hat ha reso Quarkus disponibile a tutti i clienti OpenShift da novembre 2020. Sappiamo che il 20% degli sviluppatori Java cloud sta cercando di impiegare Quarkus, che – essendo Kube-native – ha senso utilizzare fin dall’inizio.
Red Hat ha aggiornato il suo Migration Toolkit for Applications in linea con l’arrivo di Quarkus. Lo stesso Migration Toolkit è disponibile da molti anni e aiuta a migrare applicazioni diverse su piattaforme differenti (WebLogic da Oracle a Red Hat EAP per esempio).
Quello che Red Hat ha fatto negli ultimi tempi è puntare il Migration Toolkit verso Quarkus, il che significa che se uno sviluppatore indirizza le sue applicazioni al Toolkit, quest’ultimo può suggerire cosa cambiare senza impegnarsi in un processo completo di refactoring del codice.
Quindi, nel complesso, il viaggio verso Quarkus dovrebbe essere indolore, familiare, operativamente flessibile e altamente funzionale in termini di uso quotidiano. Red Hat sta incoraggiando e guidando gli sviluppatori nel loro percorso verso Quarkus in ambienti che si estendono dal datacenter verso l’edge, su tutti i dispositivi e l’Internet on Things, oltre che il cloud pubblico.
