Red Hat-cloud-native Java-toekomst met Quarkus
Het nieuwste initiatief van Red Hat, Quarkus, heeft tot doel een cloud-native Java-toekomst in te luiden – en de kern van innovatie in enterprise Java te verleggen. Talloze pogingen in de loop van de jaren hebben geprobeerd Java meer cloud-native te maken, zoals de Dalvik virtuele machine van Google die in Android wordt gebruikt. Niemand heeft zoveel belofte getoond als Red Hat Quarkus, dat is gebaseerd op twee door Oracle geleide projecten, GraalVM en Substrate VM, om cloud-native Java-applicaties te bouwen die veel sneller en kleiner zijn, in een Linux-container als onderdeel van een Kubernetes-implementatie .
GraalVM is een universele virtuele machine die wordt gebruikt voor het uitvoeren van toepassingen die zijn geschreven in op JavaScript, Python, Ruby, R en Java Virtual Machine (JVM) gebaseerde talen, waaronder Java, Scala, Clojure, Kotlin en ook virtuele machines op laag niveau. op basis van talen, zoals C en C ++. Graal maakt een agressieve ATS-compilatie mogelijk, zodat ontwikkelaars hun apps in eigen binaire afbeeldingen kunnen compileren en de beperkingen van de JVM kunnen vermijden.
Substrate VM, een subsysteem van Graal, concentreert zich op AOT-compilatie om Java te verzamelen voor een native binary image, zegt Mark Little, vice-president van engineering en CTO van JBoss Middleware bij Red Hat.
Met Quarkus – in eerste instantie bekend als Protean binnen Red Hat – wil Red Hat van Java een toonaangevend platform maken in Kubernetes en serverloze omgevingen, en ontwikkelaars een uniform programmeermodel bieden om een breder scala aan gedistribueerde applicatiearchitecturen aan te pakken, aldus Little.
Oracle heeft in 2017 het beheer van enterprise Java EE aan de Eclipse Foundation afgestaan. Red Hat, IBM en enkele andere bedrijven hebben innovatie op het platform overgenomen, terwijl Oracle zich richtte op de standaard Java-editie. Hoewel verschillende Oracle-technici nog steeds bijdragen aan de inspanningen van Graal en Substrate – en dus aan Quarkus – leidt Red Hat deze kosten.
De Java-community voor bedrijven blijft werken om Java een goede burger in de cloud te maken, inclusief de inspanningen om OpenJDK voor Linux-containers en Kubernetes te optimaliseren. Ontwikkelaars maken zich echter nog steeds zorgen over hoe goed de JVM- en Linux-containers samenwerken, van de hoeveelheid geheugen die door de JVM wordt verbruikt tot opstarttijd en algemene prestatieproblemen.
De standaard HotSpot JVM, die Oracle nog steeds onderhoudt en ondersteunt, is geëvolueerd naar meer een eersteklas burger voor cloud-native applicaties, maar het is nog niet helemaal klaar om de feitelijke VM van keuze te zijn in die omgeving, zei Martijn Verburg, CEO van jClarity en co-lead van de London Java User Group.
“Red Hat en anderen proberen naar een stop-gap-maatregel te kijken totdat het VM-onderzoek en de implementatie bij OpenJDK voltooid zijn,” zei hij. “Graal, dat experimenteel is in OpenJDK als een optie, is zeker een technologie die het waard is om naar te kijken.”
Schrijf één keer, ren overal
Het verkoopargument van Java sinds het begin is dat een ontwikkelaar een programma één keer kan schrijven en het overal kan uitvoeren. Dat werkte omdat ontwikkelaars Java compileerden tot bytecode om te draaien op de JVM, die de app isoleert van het onderliggende besturingssysteem. Dit kost echter veel opstarttijden voor het geheugen.
Graal, dat experimenteel is in OpenJDK als een optie, is zeker een technologie die het waard is om naar te kijken.
Als u de JVM in cloudomgevingen uitvoert, met name die op basis van Kubernetes, is deze vaak minder optimaal dan wanneer u sommige van de nieuwe niet-JVM-programmeertalen zoals Go en JavaScript gebruikt, zei Little. Maar Graal en Substrate zorgen ervoor dat Java-ontwikkelaars de JVM effectief uit beeld kunnen halen en kunnen compileren naar een native uitvoerbaar bestand en het native besturingssysteem kunnen gebruiken.
Het nadeel is echter dat de native binary niet zomaar op een willekeurig besturingssysteem kan draaien. Maar in de cloud maken ontwikkelaars gewoonlijk geen zorgen dat ze een binary op verschillende besturingssystemen uitvoeren, omdat ze meestal alleen op Linux-containers zijn gericht.
In de meeste gevallen winnen ontwikkelaars die afweging: een uitvoerbaar bestand dat veel kleiner is dan de footprint die ze zouden hebben met de JVM en hun originele Java-applicatie zal veel sneller opstarten, weinig gezegd.
“We hebben het over opstarttijden in de volgorde van seconden voordat iets als Substrate wordt gebruikt, [wat opstarttijden kan leveren in de orde van één tot vijf milliseconden,” merkte hij op.
De cloud-native Java-push van Red Hat heeft een stuk zonder server
Naast Graal en Substrate blijft Red Hat verder bouwen aan zijn werk in de serverloze computerkamer en biedt het een Kubernetes-native omgeving voor zakelijke Java-ontwikkelaars om apps en services te bouwen voor het Red Hat OpenShift-containerplatform.
In een serverloze omgeving willen ontwikkelaars hun app of service snel laten draaien in reactie op een gebeurtenis, zoals een inkomend bericht of een melding. Het vermogen om snel servi te laten draaien en af te breken
