13_Computing_Platform_Deployment

Materi ini membahas bagaimana sebuah aplikasi di-package, didistribusikan, dan di-deploy ke lingkungan produksi (computing platform). Fokusnya ada pada evolusi opsi packaging: dari binary executable klasik, bytecode JVM, Virtual Machine (VM), Container (Docker), hingga Serverless Functions — beserta trade-off masing-masing dari sisi isolasi, overhead, kecepatan startup, dan skalabilitas.

Masalah Packaging & Deployment Aplikasi

Aplikasi pada umumnya butuh lingkungan yang sangat spesifik supaya bisa berjalan:

• Application server/middleware: mis. Tomcat, Maven, Express.js
• Language interpreter: mis. Python 3.8, Java 11, Node.js
• Libraries: yang di-load lewat package manager seperti mvn, npm, pip, ld
• Command line tools: mis. openssl, imagemagick, mysql
• OS features & configs tertentu

Ketergantungan ini memunculkan isu klasik “sudah jalan kok di komputer saya…” — aplikasi berjalan normal di lingkungan development tapi gagal di lingkungan lain karena perbedaan environment. Solusi packaging yang berkembang untuk mengatasi ini: language/platform-specific packaging (Python, Java), Virtual Machine, Containers, dan Serverless functions.

Opsi Packaging #0: Binary Executable

• Umum untuk distribusi aplikasi pada OS consumer (desktop, mobile).
• Aplikasi desktop Windows/Mac didistribusikan lewat App Store atau installer khusus — keduanya menangani otomatis kebutuhan library.
• Bisa juga berupa binary executable murni, tapi hanya jalan pada sistem sejenis (arsitektur CPU & OS yang cocok).
• Aplikasi mobile (Android & iOS) lebih mudah di-package karena aksesnya sudah sandboxed (dibatasi).
• Distribusi Linux memakai package manager seperti apt dan yum.

Opsi Packaging #1: JVM Bytecode

Java bytecode adalah hasil kompilasi kode Java yang berjalan di atas Java Virtual Machine (JVM). JRE mengemulasikan JVM dan mentranslasikan JVM code ke native code — filosofi “write once, run anywhere”.

• Kode didistribusikan sebagai .jar atau .war (java bytecode archive).
• Banyak bahasa lain yang juga dikompilasi ke JVM: Scala, Kotlin, Clojure, Groovy, Jython, JRuby.
• Kelebihan: ukuran kode kecil, simplicity, performance.
• Kekurangan: pilihan bahasa terbatas, aplikasi tidak terisolasi penuh dari OS, tidak ada kontrol di luar environment JVM.

Opsi Packaging #2: Virtual Machine (VM)

Latar Belakang: Hypervisor & Sharing Resource

Biasanya satu server hanya diinstal 1 OS, dan sharing resource dilakukan dengan menjalankan berbagai aplikasi berbeda di server yang sama (web server, database server, email server, dst) — OS men-share CPU & memory ke semua aplikasi yang berjalan konkuren.

Hypervisor memungkinkan satu server fisik menjalankan multiple VM dengan OS berbeda-beda sekaligus. Tiap VM punya OS sendiri (bisa sama atau beda versi), dan antar-VM berkomunikasi lewat network. Contoh hypervisor: KVM, Xen, VMWare, Hyper-V.

Ada dua tipe hypervisor:

• Type 1 (Native/bare metal): hypervisor berjalan langsung di atas hardware.
• Type 2 (Hosted): hypervisor berjalan di atas Host OS yang sudah terinstal lebih dulu.

Kenapa Menggunakan VM

• Hypervisor menambah kompleksitas & overhead, tapi manfaatnya besar:
• Isolasi masalah: kalau satu service (mis. web server) mengalami memory leak atau security breach, VM lain (service lain) tidak terpengaruh.
• Migrasi on the fly: VM bisa dipindah ke mesin fisik lain (kalau didukung hypervisor) — berguna kalau mesin fisik perlu diperbaiki.
• Elastic vertical scaling: server berkapasitas besar tidak selalu dipakai penuh untuk 1 service — resource yang dialokasikan ke VM bisa di-scale dinamis (hypervisor menambah alokasi CPU & RAM ke VM tertentu).

Elastic Computing Cloud (EC2) / Compute Engine

AWS EC2 (sejak 2006) adalah layanan rental VM dengan skema charge per pemakaian (per menit). Consumer bisa memilih:

• Ukuran VM (CPU, RAM, network bandwidth, GPU)
• Operating System (berbagai Linux, Windows, Mac)
• Storage type (SSD, Magnetic)
• Lokasi datacenter (Jakarta, Singapore, US, dst)
• Reservation period (no contract, 1 tahun, 3 tahun)
• Networking details (public internet vs private network)
• Login credentials (SSH public key)

VM baru bisa dibuat dalam orde menit.

Concern Operasional VM

Menggunakan cloud/sewa memudahkan masalah pengadaan hardware, tapi masih ada concern software lain yang harus ditangani manual:

• Instal & konfigurasi 3rd party software (database, web server, libraries, distributed caches, message queue, coordination tools, OS updates)
• Deploy versi baru aplikasi saat release
• Monitor aplikasi & OS health (log files, CPU utilization, free memory, free disk space)
• Manage security (konfigurasi user, set/rotate password, firewall)
• Semua ini masuk ranah DevOps.

VM sebagai Unit Packaging

Bentuk ekstrim packaging: ship keseluruhan software stack, mulai dari kode boot. Kita membuat virtual disk yang cukup untuk menginstal OS, libraries, dan aplikasi. Any hypervisor yang mendukung arsitektur CPU yang sama (mis. x86-64) bisa menjalankan image ini. Pada AWS, pre-configured VM disebut AMI (Amazon Machine Image).

• Kelebihan: runtime environment konsisten & terkontrol, mengisolasi aplikasi dari aplikasi lain di luar VM.
• Kekurangan: ukuran besar, overhead performa untuk virtual/guest OS, slow startup.

Opsi Packaging #3: Docker Containers

Container serupa dengan VM secara konsep (isolasi), tapi jauh lebih kecil dan efisien — container hanya dirancang untuk menjalankan satu proses/aplikasi, bukan OS lengkap. Hypervisor menjalankan VM, sedangkan Docker/Container runtime menjalankan container.

Container didefinisikan lewat Dockerfile, yang berisi:

• Base/parent image: biasanya versi stripped-down berukuran kecil (contoh: Alpine ~5MB vs Ubuntu ~190MB). Child image bisa menambahkan software lain di atas base image.
• Instruksi untuk mengubah base image (install package, copy file, set entrypoint, dst).

Dockerfile hanyalah file teks kecil, tapi menjadi blueprint lengkap untuk membangun environment aplikasi.

Container vs Virtual Machine

Aspek	Virtual Machine	Container
Isolasi	Tiap VM punya guest OS sendiri di atas hypervisor	Semua container share host OS kernel, dikelola lewat Docker/container manager
Ukuran	Besar (menyertakan seluruh OS)	Jauh lebih kecil (hanya app + dependencies)
Overhead	Tinggi (boot OS penuh)	Rendah
Startup	Lambat (orde menit)	Cepat (orde detik)

Container juga bisa berjalan di atas VM — kombinasi ini umum di cloud, misalnya sebuah VM menjalankan Docker daemon yang mengelola banyak container di dalamnya.

Docker Layered Filesystem

Container diturunkan dari base image, sehingga banyak container yang berjalan pada satu mesin bisa berbasis parent/base image yang sama → ada potensi sharing. Sebuah docker filesystem layer adalah sekumpulan perubahan (changes) terhadap base filesystem, memakai skema copy-on-write filesystem.

Contoh: 2 container menjalankan Elasticsearch dengan konfigurasi berbeda — mayoritas data container (base image, dependencies, application binary) tetap di-share, hanya layer teratas (konfigurasi & environment variable) yang berbeda.

Linux Support untuk Container

Linux memiliki built-in support untuk mengisolasi proses satu sama lain. Docker memanfaatkan fungsionalitas Linux container ini (LXC, runc), dan menambahkan value lebih:

• Build toolchain (Dockerfile, dst)
• Layered filesystem images
• Central image repository (Docker Hub)
• Runtime environment untuk Mac & Windows (yang menjalankan Linux di dalam VM)

Catatan penting: container tidak bisa saling melihat satu sama lain, tapi tetap bisa merasakan efek dari container lain (misal memory & CPU yang dishare secara dinamis bisa saling mempengaruhi performa).

Mendeploy Container

Ada 3 opsi untuk mendeploy container:

1. Menjalankan pada VM/bare-metal memakai docker-compose.
2. Menggunakan cluster — umumnya memakai Kubernetes untuk orkestrasi container, dengan membuat node pool berisi sejumlah instance untuk meng-host cluster.
3. Managed infrastructure (AWS Fargate, GCP Cloud Run, Azure Container Instances) — container di-deploy “somewhere” tanpa kita mengurus server-nya secara eksplisit; kita hanya mendefinisikan jumlah core CPU & RAM yang direservasi, dan hanya bayar saat dipakai (scaling dinamis).

Perbandingan Cara Launch

Virtual Machine	Container
1. Copy disk image ke VMM	1. Copy Dockerfile & kode aplikasi ke host
2. Reserve CPU & RAM share	2. Download base image (skip kalau container lain sudah pakai base image yang sama)
3. Boot VM OS	3. Jalankan setup commands di Dockerfile
	4. Jalankan app command di Dockerfile

Container jelas jauh lebih ringan/cepat karena tidak perlu boot OS penuh dan bisa memanfaatkan sharing base image antar-container.

Opsi Packaging #4: Serverless Functions

Serverless functions mengabstraksikan platform lebih jauh lagi — kode kita hanya akan berjalan “somewhere” di cloud, tanpa kita mengurus server maupun container sama sekali.

Karakteristik & batasan serverless functions:

• Harus berjalan pada platform standar yang mendukung banyak tenant sekaligus secara simultan.
• Semua kode berada pada satu bahasa dan satu runtime tertentu (mis. Python 3.5). Fungsi Lambda sederhana bahkan bisa ditulis/paste langsung di AWS web console.
• Dependencies harus dimasukkan ke dalam bundle aplikasi yang dideploy (yang di-install adalah fungsi kode kita) — contoh Python: pip install --target ./package urllib3.
• Serverless function bersifat stateless (tidak ada global variable untuk menyimpan state antar invocation).
• Kode tidak bisa men-spawn command-line process lain.
• Kode hanya bisa menulis ke satu folder pada filesystem (mis. /tmp), dan folder ini sandboxed dari function lain yang berjalan pada VM yang sama.
• ✅ Overhead & startup delay jauh lebih kecil dibanding container atau VM.
• Catatan: Java .jar adalah package yang ideal untuk serverless function.

Cara Kerja Serverless

1. Ada cloud-configured event yang men-trigger/memanggil function.
2. Sebagai response, kode di-deploy ke VM (mungkin berbagi VM dengan function lain).
3. Ada delay kecil untuk menjalankan fungsi kalau belum ada instance sebelumnya di VM tersebut — disebut cold start.
4. Function di-deploy ke sebanyak mesin yang diperlukan, on demand.
5. AWS Lambda function saat ini dibatasi maksimal 15 menit runtime.
6. Asosiasi antara kode dan VM bersifat short-term.
7. Serverless function harus dibuat untuk platform vendor tertentu (mis. AWS Lambda) → muncul vendor lock-in.

AWS Lambda Function Lifecycle

• Lambda menyediakan beragam runtime environment: node.js, python, ruby, java, .NET.
• Saat request datang, Lambda mendownload kode, menginisialisasi runtime environment beserta inisialisasi yang diperlukan fungsi (mis. koneksi ke DB), lalu memanggil fungsi tersebut — proses ini adalah cold start.
  • Cold start bisa memakan waktu beberapa ratus ms (node.js, Go) hingga 1-2 detik (Java, .NET), tergantung runtime, ukuran kode, dan inisialisasi yang diperlukan.
• Request berikutnya (setelah initial request) bisa memakai runtime environment yang sudah “hangat” (warm start).
• Kalau ada burst sejumlah request bersamaan, masing-masing dijalankan pada instance berbeda → menyebabkan cold-start per request.
• Kalau tidak ada request baru untuk periode tertentu, runtime environment di-freeze, lalu akhirnya dideaktivasi. Request dalam periode freeze masih bisa memakai kembali frozen runtime tersebut.

Cara Memanggil Serverless Function

Pada AWS, sebuah Lambda function bisa di-trigger oleh:

• Admin yang mengklik tombol di Lambda console.
• Kode kita yang memanggil Lambda API secara langsung.
• Client request lewat AWS API Gateway yang dikonfigurasi memanggil Lambda.
• CloudWatch event terjadwal (periodik).
• Event pada managed service, seperti S3 (mis. menjalankan Lambda saat file baru masuk ke bucket) atau SQS (menjalankan Lambda untuk menangani message baru di queue).

Tiga pola pemanggilan berbeda:

• Synchronous (push): mis. lewat API Gateway — client menunggu response langsung dari Lambda.
• Asynchronous (event): mis. lewat SNS/S3 — event dikirim ke antrean request, Lambda diproses async.
• Stream (poll-based): mis. lewat DynamoDB Streams/Kinesis — Lambda service mem-poll perubahan data lalu memanggil function.

Use Case Serverless

Serverless cocok untuk:

• Infrequently-executed code & batch processing — tidak ada resource yang terbuang saat idle.
• Bursty workloads — function bisa jalan dalam hitungan detik (hanya butuh code copy + startup), jauh lebih cepat dibanding menjalankan VM baru (orde menit) atau container.
  • Contoh: memproses burst dadakan ribuan dokumen secara paralel di banyak mesin sekaligus — kalau pakai banyak VM yang idle akan sangat mahal, dan membuat VM baru terlalu lambat.

Use case umum: web applications (static sites, web apps kompleks, Flask/Express package), backend apps/services (mobile, IoT), data processing (real-time, MapReduce, batch), chatbots, Amazon Alexa skills, autonomous IT (policy engine, extend AWS service, infrastructure management). Berdasarkan survei komunitas serverless (2018): 32% web & API serving, 21% data processing (batch ETL), 17% integrasi 3rd party service, 16% internal tooling, 8% chatbot, 6% IoT.

Skalabilitas AWS Lambda

• Lambda punya built-in concurrency limit untuk request burst, spesifik per region.
• Default concurrency limit: 1000 (bisa dinaikkan via request ke AWS).
• Limit request per detik: maksimal 10x concurrency quota.
• Concurrency scaling rate: 1000 execution environment per 10 detik per region.
• Request yang ditolak karena limit akan menerima response error HTTP 429.
• Reserved concurrency: jumlah maksimum instance konkuren yang dijamin untuk satu function tertentu.
• Provisioned concurrency: sejumlah execution environment yang sudah di-preinitialize (menghilangkan cold start untuk sejumlah kapasitas tertentu).

Limitasi Serverless

• Stateless nature: operasi fine-grained terhadap persistent shared data memerlukan latency besar untuk akses data (karena tidak ada state lokal yang bisa dipertahankan antar-invocation).
• Fine-grained coordination antar task memerlukan latency besar kalau memakai explicit event/message (karena komunikasi antar function harus lewat layanan eksternal).
• Predictable performance: cold startup bisa menambah latency yang sulit diprediksi.

Fallacy & Pitfall Seputar Serverless

• Fallacy: karena instance Lambda dengan kapasitas memory setara AWS t3.nano (0.5 GiB) biaya per menitnya 7.5x lebih mahal, maka serverless computing selalu lebih mahal dari serverful computing. → Pitfall: biaya serverless bisa tidak terprediksi, tergantung pola pemakaian (bisa jauh lebih murah untuk beban bursty/jarang, atau lebih mahal untuk beban konstan tinggi).
• Fallacy: karena serverless ditulis dalam bahasa level tinggi seperti Python, mudah dipindah antar provider serverless. → Pitfall: vendor lock-in justru bisa lebih kuat pada serverless dibanding serverful computing (karena bergantung pada trigger/event system spesifik vendor).
• Fallacy: cloud function tidak bisa menangani aplikasi latency rendah yang butuh performa terprediksi. → Pitfall: sedikit layanan “elastic” yang benar-benar memenuhi tuntutan fleksibilitas nyata dari serverless computing.

Perbandingan Keseluruhan Computing Platform

Platform	Kelebihan	Kekurangan
Virtual Machine	Menjalankan multiple isolated OS pada 1 mesin; environment konsisten	Overhead ruang tinggi; lambat start/stop; horizontal scaling & resource management manual
Container	Runtime environment konsisten tanpa overhead full VM; automatic horizontal scaling	Kurang configurable dibanding VM
Serverless	Startup tercepat, overhead storage paling kecil; automatic horizontal scaling	Harus 1 bahasa pemrograman; harus stateless & dibatasi durasi (mis. <15 menit); vendor lock-in

Recap

• Virtual Machines memungkinkan banyak tenant men-share satu physical server; aplikasi didistribusikan sebagai VM disk image.
• Containers membuat environment yang konsisten untuk aplikasi; didistribusikan sebagai image (mirip VM disk image tapi jauh lebih ringan) atau sebagai source code + Dockerfile (blueprint image).
• Serverless functions adalah kode yang di-stage di cloud dan siap dijalankan, di-deploy ke satu atau lebih VM secara on demand.
  • Pro: scalability lebih dinamis & fine-grained dibanding container/VM; memakai sebanyak mungkin mesin yang diperlukan saat diperlukan (dari 0 ke ribuan).
  • Cons: delay “cold start” hingga beberapa detik (copy code & launch); runtime function sering dibatasi (mis. 15 menit untuk Lambda).

Flashcard

flashcards Apa perbedaan utama Virtual Machine dan Container dari sisi apa yang diisolasi? :: VM mengisolasi seluruh OS (tiap VM punya guest OS sendiri di atas hypervisor), sedangkan container hanya mengisolasi proses/aplikasi dan tetap berbagi (share) kernel host OS yang sama, sehingga container jauh lebih ringan dan cepat startup-nya. Apa itu Dockerfile dan apa isinya? :: Dockerfile adalah file teks kecil yang menjadi blueprint untuk membangun container image, berisi base/parent image (biasanya versi OS yang di-strip kecil) dan instruksi untuk memodifikasi image tersebut (install package, copy file, dst). Apa yang dimaksud dengan copy-on-write filesystem pada Docker layered filesystem? :: Mekanisme di mana container diturunkan dari base image dan setiap perubahan disimpan sebagai layer baru di atasnya, sehingga banyak container dengan base image sama bisa saling men-share sebagian besar data filesystem-nya, hanya layer perubahan (mis. konfigurasi) yang unik per container. Apa itu “cold start” pada serverless computing dan kapan itu terjadi? :: Delay tambahan yang terjadi saat sebuah serverless function dipanggil tapi belum ada runtime environment yang siap (belum pernah dijalankan sebelumnya atau sudah di-deaktivasi karena idle lama) — cloud provider harus mendownload kode, menginisialisasi runtime, baru menjalankan fungsi. Kenapa serverless function harus bersifat stateless? :: Karena asosiasi antara kode dan VM/instance bersifat short-term dan tidak ada jaminan request berikutnya akan dilayani oleh instance yang sama, sehingga tidak boleh ada global variable untuk menyimpan state antar invocation — state harus disimpan di layanan eksternal (database, cache, dst). Sebutkan 3 cara utama sebuah AWS Lambda function bisa di-trigger. :: (1) Synchronous/push lewat API Gateway, (2) Asynchronous/event lewat layanan seperti SNS atau S3, (3) Stream/poll-based lewat layanan seperti DynamoDB Streams atau Kinesis. Kenapa serverless computing sangat cocok untuk bursty workload dibanding VM atau container? :: Karena serverless function bisa dijalankan dalam hitungan detik (hanya perlu code copy dan startup time) sehingga bisa langsung di-scale ke banyak mesin sekaligus saat dibutuhkan, sedangkan membuat VM baru makan waktu orde menit dan menjaga banyak VM tetap idle sangat mahal. Apa itu vendor lock-in pada serverless computing dan kenapa pitfall-nya lebih kuat dibanding dugaan umum? :: Vendor lock-in adalah ketergantungan aplikasi pada platform/vendor cloud tertentu (mis. AWS Lambda) sehingga sulit dipindah ke provider lain; meski kode ditulis dalam bahasa umum seperti Python, integrasi erat dengan trigger/event system spesifik vendor (API Gateway, S3, SQS, dst) membuat migrasi tetap sulit — pitfall-nya justru lebih kuat dibanding anggapan bahwa bahasa level tinggi membuatnya mudah dipindah. Apa perbedaan reserved concurrency dan provisioned concurrency pada AWS Lambda? :: Reserved concurrency adalah jumlah maksimum instance konkuren yang dijamin/dibatasi untuk satu function tertentu, sedangkan provisioned concurrency adalah sejumlah execution environment yang sudah di-preinitialize (warm) sebelumnya untuk menghilangkan cold start pada kapasitas tersebut.