Belajar IoT Engineer - IoT + Cloud-Native

#Pendahuluan

Di episode 8 kita membangun pipeline dengan server biasa, dan di episode 21 kita membahas skala besar. Episode ini memperkenalkan pola modern yang semakin standar: cloud-native — serverless, event-driven, dan Kubernetes — diterapkan ke sistem IoT.

Mengapa cloud-native penting untuk IoT? Karena IoT adalah beban event: perangkat mengirim pesan terus-menerus dengan volume yang sangat fluktuatif. Arsitektur klasik yang selalu menjalankan server membuang uang saat idle dan kepanikan saat lonjakan. Cloud-native menyesuaikan kapasitas secara otomatis — bayar sesuai pemakaian, bukan bayar untuk "yang terburuk".

#Serverless IoT: Lambda dan Konsepnya

Serverless berarti kalian tidak mengelola server — kode berjalan sebagai respons terhadap event, dan platform menangani scaling.

Serverless processing

Device → IoT platform → Event (rule) → Function (serverless)
                                       → storage → dashboard

Contoh AWS: rule engine (episode 8) memicu Lambda untuk setiap event penting — bukan menjalankan server 24/7:

lambda_handler.py - proses event IoT

import json
import boto3
 
def lambda_handler(event, context):
    payload = json.loads(event["body"])
 
    if payload["temperature"] > 40.0:
        # kirim alert hanya saat penting
        sns = boto3.client("sns")
        sns.publish(
            TopicArn="arn:aws:sns:ap-southeast-1:ACCOUNT:iot-alerts",
            Message=json.dumps(payload),
        )
    return {"statusCode": 200}

Keuntungan serverless untuk IoT:

Aspek	Server biasa	Serverless
Scaling	Manual/tingkatkan	Otomatis, per-event
Biaya idle	Tetap jalan	Nol saat tidak ada event
Operasional	Kelola OS/server	Fokus pada kode
Cold start	Tidak ada	Ada (latensi awal)

Kelemahannya: cold start (fungsi yang menganggur butuh waktu memuat) dan timeout (Lambda maksimal 15 menit). Untuk pemrosesan event singkat ini sempurna; untuk job panjang gunakan container.

#Pola Event-Driven

Event-driven architecture (EDA) membuat komponen saling berkomunikasi lewat event, bukan panggilan langsung:

100%

Pola	Deskripsi	Keuntungan
Pub/Sub	Publisher tidak tahu subscriber	Decoupling total (MQTT sudah begini)
Event sourcing	Event adalah sumber kebenaran	Bisa replay & audit
Outbox pattern	Tulis event ke DB dulu, lalu publish	Konsistensi dan anti-hilang

Karena MQTT sudah pub/sub (episode 5), sistem IoT secara alami event-driven. Prinsipnya: setiap komponen baru menempel ke event bus, tanpa mengubah yang lain — inilah kenapa sistem IoT mudah diperluas.

#Kubernetes di Edge

Kubernetes (K8s) biasanya diasosiasikan dengan server cloud besar. Tapi ia juga dipakai di edge — mengelola gateway industri sebagai workload terkelola:

Approach	Cara Kerja	Cocok Untuk
K3s (lightweight K8s)	Kubernetes lengkap tapi ringan	Gateway edge Raspberry Pi, industrial PC
KubeEdge	K8s dioptimalkan untuk edge	Cloud-edge terintegrasi
K8s standar	Cluster besar	Pusat data cloud

Contoh: gateway pabrik menjalankan K3s yang mengelola beberapa container — MQTT broker lokal, OPC UA translator (episode 15), dan model TinyML inference (episode 13) — semuanya dijadwalkan dan diperbarui seperti aplikasi cloud biasa.

Install K3s di gateway edge

curl -sfL https://get.k3s.io | sh -
kubectl get nodes

Keuntungan K8s di edge: deployment & rollback terstandar (sama seperti cloud), observability bawaan, dan resilience (restart otomatis saat crash). Kelemahannya: kompleksitas — hanya layak untuk gateway yang cukup powerful dan sistem yang besar.

Note

Jangan langsung pasang Kubernetes karena "modern". Aturan: 1 gateway, beberapa container, kebutuhan sederhana → Docker Compose cukup. Banyak gateway, pembaruan terkoordinasi, tim besar → K3s. Skala organisasi dan jumlah gateway yang menentukan, bukan tren.

#Praktik: Cloud-Native End-to-End

Arsitektur cloud-native untuk sistem IoT kalian:

Arsitektur cloud-native IoT

Device → MQTT → IoT Platform (managed)
    → Rule → Event Bus (serverless)
        ├→ Lambda alerting (threshold)
        ├→ Lambda → InfluxDB (storage)
        └→ Lambda → analytics/ML (episode 23)
Dashboard → read dari storage + event bus

Uji konsepnya dengan emulasi di lokal:

Simulasikan event-driven flow

python3 virtual-device.py &     # device virtual (episode 16)
mosquitto_sub -t "alert/#" -v   # konsumen event

#Kesalahan Umum

Serverless untuk job panjang — Lambda punya timeout; gunakan container/queue worker untuk job besar.
Cold start diabaikan — latency tambahan saat fungsi dingin; pertimbangkan untuk alerting kritis.
K8s di edge yang tidak perlu — kompleksitas membebani gateway kecil; pilih sesuai kebutuhan.
Tanpa idempotensi — event bisa terkirim lebih dari sekali (QoS 1, episode 5); consumer harus aman terhadap duplikat.
Event tanpa schema versioning — schema berubah, consumer lama rusak; versioning event wajib.

#Penutup

Inti yang harus dibawa pulang:

Serverless cocok untuk beban event IoT: scaling otomatis, biaya sesuai pemakaian, minim operasional.
Event-driven: MQTT sudah pub/sub; perlakukan semua komponen sebagai subscriber event bus.
Kubernetes di edge (K3s/KubeEdge) untuk gateway terkelola — pilih sesuai skala, bukan tren.
Pola wajib: idempotent consumer dan schema versioning.
Cloud-native = bayar sesuai pemakaian dan scaling otomatis; cloud-server = bayar untuk kapasitas terburuk.

Di episode 25 selanjutnya, kita akan melihat perjalanan sebuah produk IoT dari lahir sampai pensiun: IoT product lifecycle — dari desain, prototyping, mass production, sampai end-of-life — plus praktik menyusun rencana produk kalian. Karena engineer hebat tidak hanya membuat yang berfungsi, tapi yang bisa diproduksi!