Belajar k6 - Sejarah, Latar Belakang & Mengapa Membutuhkan k6

#Pendahuluan

Di episode 0 kalian telah menyiapkan environment: binary k6 terpasang, k6 version mengembalikan nomor rilis, dan editor siap menulis skrip JavaScript. Sekarang, sebelum mengetik script pertama, kita perlu menjawab pertanyaan paling fundamental: mengapa k6 ada, dan mengapa ia layak dipilih?

Setiap tool lahir sebagai jawaban atas rasa sakit tertentu. Untuk memahami k6, kita harus menelusuri rasa sakit itu: era ketika load testing identik dengan tool GUI raksasa yang berat, sulit diotomasi, dan terpisah dari dunia developer modern. Episode ini akan mengikuti garis waktu k6 dari lahirnya Load Impact tahun 2017 hingga kedudukannya sekarang sebagai proyek andalan Grafana Labs, lalu melakukan perbandingan jujur dengan para pendahulunya: JMeter, Gatling, dan Locust. Di akhir episode, kalian akan paham tidak hanya apa k6, tapi kapan dan mengapa memilihnya.

#Garis Waktu: Dari Load Impact ke Grafana k6

#2017 — Lahir sebagai Load Impact

k6 pertama kali dikembangkan pada tahun 2017 oleh tim di balik perusahaan SaaS bernama Load Impact — perusahaan yang menjual layanan load testing sebagai produk berbayar. Saat itu, kebutuhan internal mereka adalah tool yang mampu menjalankan pengujian skala besar secara efisien, terotomasi, dan bisa dikontrol melalui API. Hasilnya adalah k6, engine load testing internal yang ditulis dalam Go.

Keputusan menulis dalam Go sejak awal adalah kunci yang membedakan arah k6: Go menghasilkan binary tunggal yang ringan, cepat, dan memakai sedikit memori — sifat yang kelak menjadi keunggulan utama dibanding tool berbasis JVM yang rakus resource.

#2018 — Open Source

Pada tahun 2018, Load Impact memutuskan melepas k6 menjadi open-source dengan lisensi open-source (AGPL-3.0). Ini adalah titik balik: ribuan developer mulai berkontribusi, dan k6 dengan cepat menjadi salah satu project load testing paling populer di GitHub. Kekuatan komunitas membuat fitur berkembang pesat — bukan hanya dari vendor, tapi dari kebutuhan nyata para penggunanya di lapangan.

#2021 — Akuisisi oleh Grafana Labs

Tahun 2021, Grafana Labs mengakuisisi Load Impact dan membawa k6 ke dalam ekosistem observability-nya. Nama resminya berubah menjadi Grafana k6. Akuisisi ini bukan sekadar pergantian nama: k6 sekarang berada di posisi strategis dalam stack observability yang dimiliki Grafana — diposisikan sebagai salah satu sumber load yang menyalurkan metrik ke platform observability seperti Grafana Cloud, Prometheus, dan InfluxDB. Dari sinilah sifat observability-native k6 lahir.

2017  ->  Load Impact mengembangkan k6 (Go engine)
2018  ->  k6 open-source, komunitas mulai berkontribusi
2021  ->  Diakuisisi Grafana Labs, resmi menjadi Grafana k6
sekarang ->  Standard de-facto untuk load testing API & microservices

#Perbandingan dengan Tool Legacy

Agar pilihan kalian sadar — bukan sekadar ikut tren — mari bandingkan k6 dengan tiga tool yang mendominasi lanskap load testing sebelum dan sesudah era k6.

#Apache JMeter

JMeter (lahir 1998, berbasis Java/JVM) adalah raja load testing era 2000-an. Antarmuka GUI, ratusan sampler, dan ekosistem plugin yang luas membuatnya sangat populer di kalangan QA. Kelebihannya: sudah terbukti puluhan tahun, banyak dokumentasi, dan cocok untuk pengujian multi-protokol (HTTP, JDBC, FTP, JMS, dan lain-lain).

Kelemahan terbesarnya justru berasal dari kelebihan itu: GUI membuat skenario sulit dimasukkan ke dalam version control dan CI, konfigurasi menjadi sangat kompleks seiring bertambahnya test plan, dan basis JVM menghabiskan banyak memori — menjalankan 1000 virtual users sering butuh resource yang besar. Untuk kebutuhan modern yang serba scriptable dan pipeline-ready, JMeter terasa kuno.

#Gatling

Gatling (lahir 2011, Scala/Akka) adalah kandidat yang lebih modern. Skrip ditulis dalam Scala DSL (dan kemudian juga Java), berbasis scenario-as-code, dan terkenal dengan efisiensi resource yang baik serta laporan HTML yang indah. Ia memaksa pengguna menulis skenario sebagai kode, bukan klik-klik GUI — langkah maju yang besar dari paradigma JMeter.

Kelemahannya: untuk developer non-JVM, kurva belajar Scala/Java terasa berat. Integrasi observability juga kurang native dibanding k6, dan ekosistemnya jauh lebih kecil. Jika tim kalian sudah berbahasa JVM, Gatling pantas dipertimbangkan; jika tidak, k6 jauh lebih mudah diadopsi.

#Locust

Locust (lahir 2011, Python) adalah pesaing paling dekat secara filosofi: load testing berbasis kode, ditulis dalam Python, dengan arsitektur yang memungkinkan distributed testing secara alami melalui master-worker. Sangat populer di kalangan data engineer dan tim yang nyaman dengan Python.

Kelemahannya: pengujian HTTP di Locust dijalankan lewat library requests berbasis Python yang lambat — untuk beban sangat tinggi, tiap virtual user memakai lebih banyak resource, dan throughput puncak bisa lebih rendah dibanding engine Go. Selain itu, model eksekusi worker-nya memerlukan lebih banyak usaha operasional saat skalanya membesar.

#Mengapa Memilih k6

#Scripting dengan JavaScript

Ini perbedaan paling transenden. JavaScript adalah bahasa yang dipelajari hampir semua developer modern, terlepas dari stack backend mereka. Sebuah tim yang berisi developer Go, PHP, dan TypeScript bisa langsung menulis skrip k6 tanpa belajar bahasa baru. Lebih penting lagi, skrip k6 adalah kode sungguhan: bisa masuk ke version control, bisa di-review di pull request, bisa dipakai teknik refactoring dan modularisasi — bukan test plan biner yang hanya terbaca di GUI.

import http from "k6/http";
 
export default function () {
  const res = http.get("https://test.k6.io");
  console.log(res.status);
}

#Ramah CI/CD

Karena k6 adalah binary CLI tanpa server dan tanpa GUI, ia drop-in di pipeline apa pun: GitHub Actions, GitLab CI, Jenkins, atau runner lokal. Satu perintah k6 run script.js bisa dijalankan di container yang baru lahir tanpa konfigurasi tambahan, dan exit code 99 menandakan threshold gagal — bahasa sukses-gagal yang dipahami semua pipeline.

#Observability-Native

Karena kini berada di bawah Grafana Labs, k6 dirancang untuk mengalirkan metrik keluar (output ke JSON, Prometheus remote write, InfluxDB, Grafana Cloud) dan menampilkan hasilnya dalam dashboard real-time. Metrik k6 lahir dengan nama yang stabil dan terdokumentasi — bukan sekadar log teks yang harus diparse manual. Episode 15 akan membahas ini menyeluruh.

#Efisien dalam Resource

Engine k6 berjalan di atas Go, dan script JavaScript dieksekusi oleh goja — mesin ECMAScript dalam bahasa Go. Hasilnya, satu virtual user k6 memakai memori yang jauh lebih kecil dibanding user JMeter berbasis JVM. Sebuah laptop biasa bisa membangkitkan ribuan virtual users. Ini bukan detail teknis — ini menentukan apakah load test bisa dijalankan dari laptop pengembang atau wajib menyewa server mahal.

#Kapan Memilih k6

k6 paling unggul ketika kebutuhan kalian berbentuk API, web, dan microservices dengan karakter:

1. Skenario berbasis kode. Jika tim kalian sudah code-first dan CI-driven, k6 adalah pilihan alami.
2. Beban yang bisa dibangkitkan dari laptop. Untuk prototipe dan testing harian, efisiensi resource k6 adalah keunggulan besar.
3. Integrasi observability. Jika sudah memakai Grafana/Prometheus, metrik k6 langsung bergabung dengan dashboard yang sama.
4. Banyak virtual user. Distributed testing k6 (episode 18) memakai mekanisme yang lebih ringan dibanding worker Python.

Sebaliknya, pertimbangkan tool lain jika kalian butuh pengujian protokol yang tidak didukung k6 inti (misalnya SIP atau protokol legacy eksotik), atau jika skenario membutuhkan eksekusi di dalam browser penuh — kasus yang kini dilayani k6 Browser (episode-isode lanjutan akan menyentuhnya).

#Penutup

Di episode 1 ini kalian memahami bahwa k6 bukan tool yang muncul dari ruang kosong, melainkan jawaban atas keterbatasan tool era sebelumnya:

• k6 lahir dari kebutuhan Load Impact (2017), di-open-source (2018), dan kini menjadi bagian dari ekosistem observability Grafana Labs (2021).
• Dibanding JMeter, Gatling, dan Locust, k6 unggul dalam tiga hal: scripting JavaScript, kemudahan integrasi CI, dan efisiensi resource karena engine Go.
• k6 paling tepat untuk pengujian API/web/microservices yang bersifat code-first dan observability-native.

Fondasi konseptual sudah lengkap. Di episode 2 kita masuk ke mesinnya: memahami konsep dasar dan arsitektur utama k6 — bagaimana virtual users dieksekusi, lifecycle test dari init sampai teardown, komponen seperti http module, checks, thresholds, dan metrics, serta opsi eksekusi seperti vus, duration, stages, dan ramping. Dari sejarah, kita pindah ke cara kerja. Sampai jumpa di episode 2!