Java på molnens villkor – best practise för AWS, Azure och GCP
Java på molnens villkor – best practise för AWS, Azure och GCP
Java har länge varit en tungviktare i enterprisevärlden – stabilt, typstarkt, bakåtkompatibelt. Men under molnets första stora våg stod Java ofta vid sidan av. Det gick att köra – men det var inte alltid praktiskt. Lång starttid, hög minnesförbrukning och svår containerisering gjorde att många utvecklare valde snabbare alternativ som Node.js, Go eller Python.
Men nu har något förändrats.
Med virtuella trådar, GraalVM native builds, SnapStart, strukturerad samtidighet och ramverk som Quarkus och Micronaut har Java blivit ett av de mest molnkapabla språken där ute.
I den här artikeln delar vi med oss av våra bästa erfarenheter från att köra Java i AWS, Azure och GCP – och hur vi på HiQ bygger lösningar som både utvecklare och driftmiljöer älskar.
Java i molnet – vad har förändrats?
Det korta svaret: nästan allt.
För några år sen:
- Du kunde inte använda Spring Boot i en Lambda utan att vänta flera sekunder på kallstart.
- En mikrotjänst med JVM kunde behöva 1–2 GB RAM bara för att komma igång.
- Java-appar var svåra att skala horisontellt utan att tweaka GC, heap och OS-gränssnitt.
Idag:
- Virtuella trådar i Java 21 gör det möjligt att hantera tusentals samtidiga förfrågningar med enkel, blockerande kod.
- GraalVM låter dig kompilera Java till native binaries med starttid på under 100 ms.
- Ramverk som Quarkus och Micronaut är byggda från grunden för containers, Kubernetes och serverless.
Och viktigast av allt – molnplattformarna själva har gått all in på Java. Alla tre stora aktörer erbjuder nu förstklassigt stöd, egna SDK:er, optimerade build tools och färdiga deploytjänster för JVM-baserade applikationer.
Amazon Web Services – när varje millisekund räknas
AWS har länge haft Java-stöd, men det var först med SnapStart som vi började se verklig förändring i serverless-scenarier.
Vad är SnapStart?
En ny funktion i AWS Lambda som snapshottar JVM:ens tillstånd efter initialisering – och återanvänder det vid kallstart. Det betyder att även ”tunga” Java-funktioner med Spring Boot kan starta på under en halv sekund.
När vi använder det:
I API-tjänster där latency spelar roll, men där vi samtidigt vill ha tillgång till Spring-ekosystemets fulla kraft. Vi har exempel där ett REST-API i Spring Boot, med 100+ konfigurationer, kallstartar på <400 ms med SnapStart – helt utan kodändring.
Tips från fältet:
- Använd Spring Cloud Function eller AWS Serverless Java Container för att slippa binda dig till ett specifikt moln.
- Vill du ännu längre ner i latency? Kör Quarkus med native build i en container på Fargate eller via Lambda Runtime Interface Emulator.
Utanför serverless:
När vi kör containrar använder vi ofta Corretto (Amazons egen OpenJDK-distribution) tillsammans med EKS eller ECS. Vi kombinerar det med autoscaling och binpackning via Karpenter för att få ut maximal kapacitet per vCPU.
Microsoft Azure – Spring Boot i kostym och tofflor
Microsofts relation till Java har förändrats snabbt. Från att vara ett .NET-hus till att nu aktivt sponsra Spring-teamet, släppa en egen OpenJDK (Microsoft Build of OpenJDK), och tillhandahålla Azure Spring Apps – en hanterad plattform för Spring Boot-appar.
Varför Azure Spring Apps är intressant:
- Du får autoscaling, loggning, metrics, secrets-hantering och service discovery utan att sätta upp något själv.
- Spring Boot-appar deployas som de är – utan behov av Docker, Kubernetes eller någon cloud-specific wiring.
- Särskilt värdefullt i större organisationer där det finns en ”plattformsteam kontra appteam”-uppdelning.
När vi använder det:
I projekt där affärsteamen själva driver applikationsutveckling, och där vi vill låta dem fokusera på kod – inte på infrastruktur. Azure Spring Apps blir då ett perfekt mellanting mellan plattformskontroll och utvecklarfrihet.
Serverless då?
Azure Functions stödjer Java 11 och 17. Men till skillnad från AWS finns här ingen SnapStart – vilket gör att vi rekommenderar Quarkus eller Micronaut med native builds för att hålla kallstartstiden nere.
Tips från fältet:
- Koppla på Azure Monitor och Application Insights direkt – du får gratis tracing, loggar och metrics som gör skillnad i driftfasen.
- Använd Spring Cloud Azure för smidig integration med Cosmos DB, Key Vault, Blob Storage etc.
Google Cloud Platform – containers first, Spring second
Google har ett starkt Java-arv, men deras plattform är Kubernetes-first. Om du kör Spring Boot på App Engine så funkar det – men den verkliga styrkan ligger i GKE och Cloud Run.
Cloud Run = serverless containers
Här är det Quarkus i native-läge som verkligen briljerar. Starttider på 30–80 ms, låg minnesanvändning och möjlighet att skala till noll – perfekt för burstiga workloads eller lågtrafiktjänster.
När vi använder det:
I lösningar där vi vill bygga ett kluster av små tjänster, varav vissa bara aktiveras vid behov. Vi har bland annat byggt ett system som triggas av Pub/Sub-events, processar händelser i batchar, och sen går tillbaka till vila – allt på Cloud Run med Java native images.
Tips från fältet:
- Jib (Google-verktyg) gör det busenkelt att skapa container-images direkt från Maven/Gradle – ingen Dockerfile behövs.
- Använd Spring Cloud GCP för auto-konfiguration mot Pub/Sub, Spanner, Secret Manager etc.
- Cloud Functions för Java finns – men vår erfarenhet är att Cloud Run oftare ger bättre kontroll och prestanda.
Gemensamma lärdomar från alla plattformar
- Native builds gör skillnad:
Det är inte bara hajp – GraalVM-native builds reducerar både starttid och minnesanvändning. Men de kräver förarbete: du måste anpassa reflection, använda rätt ramverk (Spring Native är bättre men ännu inte helt smärtfritt), och konfigurera rätt flaggor för din GC och image size. - Observability är ett måste:
Att logga System.out.println() fungerar inte längre. Vi jobbar alltid med OpenTelemetry (spans, traces, metrics) och pushar till Prometheus, Azure Monitor, Cloud Logging eller Datadog – beroende på kundens stack. - JVM-valet påverkar mer än du tror:
Corretto, Temurin, Zulu och andra OpenJDK-distributioner har olika GC-prestanda, olika standardflaggor och ibland subtila skillnader. Vi benchmarkar alltid våra val under last innan vi sätter något i produktion.
Java i molnet: mer relevant än någonsin
Java har gått från “går att köra i molnet” till “byggd för molnet”. Vi ser det i varje ny release – språkfunktioner som virtuella trådar och strukturerad samtidighet, plattformsstöd som SnapStart, och ett ekosystem som omfamnar containers, serverless och automatisering.
Och vi ser det i hur vi bygger lösningar:
- Vi rullar ut Spring Boot i Azure Spring Apps för snabb enterpriseutveckling.
- Vi sätter upp Quarkus-native containers i Cloud Run för att optimera burst workloads.
- Vi använder SnapStart på AWS Lambda för att kombinera skala och latency i API-förfrågningar.
Java är inte bara kvar – det är relevantare än någonsin.
Vill du veta hur vi på HiQ använder Java i molnet för att bygga skalbara, kostnadseffektiva och moderna lösningar? Eller vill du rent av bli en i gänget som utvecklar dom vassaste lösningarna? Hör av dig – vi delar gärna insikter, kod och erfarenhet.
Kontakta oss!
Kontakta oss!
Välj kontor eller kontakta HiQ International i Stockholm om du är tveksam.