Learn Quarkus - Cloud-Native Deployment

#Introduction

An application that's been tested and secured is useless if it can't be deployed. In this episode, you'll take your Quarkus application to production: wrapping it in a container, deploying to Kubernetes, understanding Helm charts and OpenShift, and exploring serverless and cloud platform integration.

Episode 20 covers cloud-native deployment thoroughly: Dockerizing Quarkus, Kubernetes deployment and Helm, Knative and serverless concepts, as well as integration with AWS, GCP, Azure, and Kubernetes.

#Dockerizing Quarkus for Container-Ready Deployment

#Container Images

Quarkus provides an extension to build container images directly from the build:

./mvnw quarkus:add-extension -Dextensions=container-image-docker

#Building the Image

./mvnw package -Dquarkus.container-image.build=true
docker images | grep belajar-quarkus

-Dquarkus.container-image.build=true builds the Docker image during packaging. For JVM mode, a JRE base image is enough; for native, a minimal base image can use ubi-micro or distroless — a much smaller image.

#A Manual Dockerfile

If you prefer full control, write your own Dockerfile:

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /work/
COPY target/*-runner /work/application
RUN chmod 775 /work/application
EXPOSE 8080
CMD ["./application"]

A native image can be very small (around 60-90MB). The command docker build -t belajar-quarkus . builds the image from this Dockerfile.

#Kubernetes Deployment, Helm Charts, and OpenShift Support

#Kubernetes Manifests

Quarkus can generate Kubernetes manifests automatically:

./mvnw quarkus:add-extension -Dextensions=kubernetes
./mvnw package

Manifests are generated in target/kubernetes/. An example of the generated deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: belajar-quarkus
spec:
  replicas: 3
  selector:
    matchLabels:
      app: belajar-quarkus
  template:
    metadata:
      labels:
        app: belajar-quarkus
    spec:
      containers:
      - name: belajar-quarkus
        image: quay.io/example/belajar-quarkus:1.0.0
        ports:
        - containerPort: 8080

#Deploying to Kubernetes

kubectl apply -f target/kubernetes/kubernetes.yml
kubectl rollout status deployment/belajar-quarkus
kubectl port-forward svc/belajar-quarkus 8080:8080

kubectl apply -f target/kubernetes/kubernetes.yml applies the deployment to the cluster. OpenShift is supported via the quarkus-openshift extension, which generates a DeploymentConfig and Route.

#Helm Charts

For better release management, wrap the manifests in a Helm chart:

helm create belajar-quarkus
helm install quarkus-app belajar-quarkus \
    --set image.repository=quay.io/example/belajar-quarkus

Helm allows different values per environment (dev, staging, prod) without changing templates.

#Knative and Serverless Concepts

#Serverless on Kubernetes

Knative Serving enables scale-to-zero applications: pods are only active when there's traffic. Quarkus native is a great fit here because the fast startup eliminates cold start latency.

./mvnw quarkus:add-extension -Dextensions=knative
./mvnw package
kubectl apply -f target/kubernetes/knative.yml

With quarkus-knative, the Knative Service manifest is generated automatically. When there's no traffic, replicas drop to zero; when a request arrives, the pod starts back up in milliseconds thanks to the native image.

#Platform Integration: AWS, GCP, Azure, and Kubernetes

#AWS Lambda

Quarkus has native serverless integration for AWS Lambda:

./mvnw quarkus:add-extension -Dextensions=amazon-lambda

Plus handlers for amazon-lambda-http so your REST endpoints run behind the API Gateway. Quarkus Lambda functions can be compiled natively, making the Java runtime lightweight and low cost.

#Google Cloud Functions and Azure Functions

• quarkus-google-cloud-functions-http runs your application on Google Cloud Functions.
• quarkus-azure-functions-http for Azure Functions.

Both support HTTP functions that expose your REST application. The common pattern: use a native image to minimize cold start and memory costs.

#Kubernetes as the Primary Target

Even with per-platform serverless integrations, Kubernetes remains the most portable target. A containerized Quarkus application can run on EKS (AWS), GKE (GCP), AKS (Azure), OpenShift, or an on-premise cluster without code changes.

#Wrap-Up

Episode 20 brings your application into the real world: understanding Dockerizing Quarkus for JVM and native images, Kubernetes deployment with automatic manifests and Helm charts, Knative for serverless scale-to-zero, as well as integration with AWS, GCP, Azure, and Kubernetes.

Key takeaways:

• The container-image-docker extension builds images during packaging.
• Native images are much smaller and suitable for lightweight deployments.
• The kubernetes extension generates deployment manifests automatically.
• Helm charts separate configuration values per environment.
• Knative enables scale-to-zero with minimal cold starts.
• AWS Lambda, GCP Functions, and Azure Functions are supported natively.
• Kubernetes remains the most portable deployment target.

In episode 21 we'll cover CI/CD and GitOps — CI/CD pipelines for Quarkus with GitHub Actions or GitLab CI, build, test, scan, and deploy automation, GitOps integration with Argo CD or Flux, as well as canary releases, blue-green deployments, and rollbacks.