Java #

Dalam dunia containerized application, ukuran Docker image bukan sekadar angka. Ia berdampak langsung pada kecepatan build CI/CD, waktu pull di Kubernetes, cold start, serta attack surface keamanan. Salah satu pendekatan paling populer untuk mengecilkan image Java adalah menggunakan distroless.

Artikel ini akan membahas secara mendetail dan realistis:

Rata-rata ukuran image Spring Boot dengan distroless
Faktor apa saja yang mempengaruhi ukurannya
Perbandingan dengan base image lain
Trade-off teknis yang sering diabaikan
Rekomendasi praktis untuk production

Artikel ini ditulis dari sudut pandang engineering pragmatis, bukan sekadar teori.

Apa Itu Distroless? #

Distroless adalah base image Docker yang:

Tidak menyertakan shell (/bin/sh, bash)
Tidak memiliki package manager (apt, apk, dll)
Tidak memiliki utilitas OS umum (curl, ps, ls)

Yang tersisa hanyalah:

Runtime (Java)
Library OS minimum (glibc)
CA certificates

Tujuan utamanya: menjalankan aplikasi, bukan mengelola OS.

Ukuran Base Image Distroless Java #

Sebagai baseline:

Base Image	Ukuran	Catatan
distroless java17 (debian12)	~45–50 MB	Runtime only

Artinya: semua ukuran di atas angka ini adalah murni aplikasi kamu.

Rata-rata Ukuran Image Spring Boot + Distroless #

Berikut adalah ukuran yang paling sering ditemui di dunia nyata:

Tipe Aplikasi	Dependency Umum	Ukuran Final
Sederhana	Web, Actuator	70–90 MB
Menengah	JPA, Security, Validation	90–130 MB
Kompleks	Kafka, Cloud SDK, ORM berat	130–160 MB

⚠️ Jika image distroless kamu melewati 160 MB, hampir pasti ada dependency yang terlalu berat atau tidak perlu.

Perbandingan dengan Base Image Lain #

Base Image	Ukuran Rata-rata
openjdk:17	300–350 MB
eclipse-temurin:17-jre	180–220 MB
eclipse-temurin:17-jre-alpine	110–150 MB
distroless	70–130 MB ⭐

Secara kasar:

Distroless bisa 2–4x lebih kecil dibanding image Java klasik

Kenapa Distroless Bisa Jauh Lebih Kecil? #

1. Tidak Ada OS Layer #

Tidak ada:

Shell
Package manager
System utilities

2. Runtime-Only #

Distroless tidak menyertakan JDK, hanya runtime Java.

3. Dependency Benar-benar Terkontrol #

Semua yang ada di image adalah:

JVM
Aplikasi kamu
Dependency aplikasi

Tidak ada “bonus” layer tersembunyi.

Faktor yang Paling Mempengaruhi Ukuran Image #

1. Dependency Spring Boot #

Beberapa dependency yang sangat cepat membengkakkan ukuran:

spring-boot-starter-data-jpa
Hibernate + driver database
SDK cloud (AWS, GCP, Azure)
Kafka client

2. Logging Library #

Logback + encoder tambahan
JSON logging (Jackson tambahan)

3. Native Library #

Netty native
Database native driver

4. Fat JAR Tanpa Layering #

Tanpa Spring Boot layered JAR, semua perubahan kecil akan memicu rebuild layer besar.

Distroless vs Alpine: Jangan Salah Kaprah #

Banyak engineer mengira alpine selalu lebih kecil. Untuk Java, ini sering tidak benar.

Aspek	Alpine	Distroless
libc	musl	glibc
Java compatibility	kadang bermasalah	sangat stabil
Debugging	mudah	sulit
Ukuran final	kadang lebih besar	konsisten kecil

Distroless sering lebih kecil dan lebih stabil untuk Java modern.

Trade-off Teknis yang Harus Disadari #

Kelebihan #

Attack surface sangat kecil
Image lebih cepat di-pull
Cocok untuk zero-trust & production

Kekurangan #

Tidak bisa docker exec -it sh
Debugging harus via log & metrics
Healthcheck harus berbasis HTTP

Distroless memaksa disiplin engineering.

Best Practice #

1. Gunakan Multi-stage Build #

Builder image gemuk, runtime image ramping.

2. Aktifkan Spring Boot Layered JAR #

Agar dependency dan kode terpisah di layer berbeda.

3. Audit Dependency Secara Berkala #

Hapus starter yang tidak dipakai
Hindari “sekalian tambah” dependency

4. JVM Memory Awareness #

Gunakan flag container-aware:

-XX:+UseContainerSupport
-XX:MaxRAMPercentage

5. Jangan Pakai Distroless untuk Development #

Gunakan untuk production only.

Kapan Distroless Paling Tepat Digunakan? #

Distroless sangat ideal jika:

Aplikasi sudah stabil
Observability sudah matang
Deployment di Kubernetes
Keamanan dan startup time penting

Kurang cocok jika:

Masih sering debugging manual
Aplikasi masih eksploratif

Penutup #

Distroless bukan sekadar tren, tapi konsekuensi logis dari container-first mindset: aplikasi adalah citizen utama, OS hanyalah detail.

Untuk Spring Boot, distroless menawarkan:

Ukuran image 70–130 MB yang realistis
Keamanan lebih baik
Konsistensi runtime

Namun ia juga menuntut kedewasaan engineering: logging, metrics, dan observability tidak bisa setengah-setengah.

Jika kamu melihat distroless sebagai “ribet”, bisa jadi masalahnya bukan di image—tapi di disiplin sistem yang belum siap.

“Distroless tidak membuat sistemmu lebih rumit. Ia hanya memperlihatkan kerumitan yang selama ini kamu sembunyikan.”