Sejarah Serverless #

Serverless sering dianggap sebagai inovasi dadakan yang muncul bersama cloud generasi baru. Faktanya, paradigma ini adalah hasil evolusi panjang dari cara manusia membangun, menjalankan, dan mengelola sistem komputasi. Memahami sejarahnya membantumu melihat mengapa serverless muncul, masalah apa yang sebenarnya diselesaikan, dan ke arah mana tren ini akan bergerak.

Artikel ini menelusuri perjalanan infrastruktur dari server fisik di rak data center, melalui virtualisasi dan cloud, hingga akhirnya melahirkan Function as a Service. Di akhir, kita akan punya gambaran utuh tentang posisi serverless dalam sejarah infrastruktur — bukan sekadar daftar fitur, tapi konteks di baliknya.

Timeline Evolusi Infrastruktur #

Sebelum masuk ke detail, mari kita lihat peta besar perjalanannya. Setiap fase membangun fondasi untuk fase berikutnya, dan setiap fase meninggalkan masalah yang belum terpecahkan.

flowchart TD
    A["1990-an: Server Fisik (Bare Metal)<br/>- Developer merangkap Sysadmin<br/>- Kapasitas statis, provision lambat"] --> B["2000-an: Virtualisasi (VMware)<br/>- Satu hardware fisik dibagi ke beberapa VM<br/>- Mulai memisahkan OS dari hardware"]
    B --> C["2006: AWS EC2 (IaaS)<br/>- Penyediaan server on-demand via API<br/>- Lahirnya Cloud Computing komersial"]
    C --> D["2008: Google App Engine (PaaS)<br/>- Deploy kode aplikasi langsung tanpa kelola OS<br/>- Abstraksi runtime pertama"]
    D --> E["2010-an: Arsitektur Microservices<br/>- Aplikasi monolith dipecah menjadi unit kecil<br/>- Kebutuhan unit deployment yang lebih efisien"]
    E --> F["2014: AWS Lambda (FaaS)<br/>- Komputasi event-driven berbasis request<br/>- Kelahiran era Serverless modern"]
    F --> G["2015+: Ekosistem Serverless Meluas<br/>- Database, Storage, Messaging, dan Auth Serverless<br/>- Cloud provider mengelola seluruh infrastruktur"]

Garis waktunya terlihat bertahap, tetapi setiap lompatan selalu dipicu oleh satu masalah yang sama: beban operasional infrastruktur yang terlalu berat bagi developer.

Era Awal: Server Fisik dan Pengelolaan Manual #

Pada fase paling awal, aplikasi dijalankan langsung di server fisik (bare metal). Satu aplikasi — atau satu sistem — biasanya menempati satu unit server utuh. Tidak ada pembagian resource secara logis, tidak ada abstraksi.

Karakteristik utama era ini dapat dirangkum sebagai berikut:

Server Fisik (Bare Metal):
  ✓ Aplikasi terisolasi secara fisik dan penuh
  ✓ Performa sangat stabil dan dapat diprediksi
  ✗ Kapasitas harus diperkirakan dan dipesan jauh-jauh hari
  ✗ Scaling hanya bisa dilakukan dengan menambah hardware fisik
  ✗ Deployment lambat dan sering kali diiringi downtime
  ✗ Satu server hanya untuk satu fungsi utama — sangat tidak efisien

Pada masa ini, developer merangkap sysadmin. Tanggung jawab mereka tidak berhenti pada penulisan kode, melainkan juga mencakup:

• Memilih spesifikasi hardware, memesannya, dan memasangnya di rak pusat data.
• Instalasi sistem operasi (OS) dan dependency secara manual.
• Mengonfigurasi jaringan fisik, aturan firewall, dan server DNS.
• Menerapkan patch keamanan sistem operasi secara berkala.
• Melakukan monitoring server secara manual selama 24/7.
• Mengelola backup data, pemulihan sistem (restore), dan disaster recovery.

Model ini memiliki satu masalah fundamental: infrastruktur bersifat statis, sedangkan beban kerja aplikasi bersifat sangat dinamis. Jika aplikasi tiba-tiba mengalami lonjakan pengguna hingga 10x lipat pada hari peluncuran, satu-satunya solusi adalah memesan server baru yang proses pengadaannya memakan waktu berminggu-minggu atau bahkan berbulan-bulan.

Masalah klasik era bare metal: kapasitas disiapkan untuk mengantisipasi beban puncak tertinggi, padahal rata-rata penggunaan sehari-hari hanya berkisar antara 10–20%. Sisa 80% resource hardware menganggur tetapi biaya perawatannya tetap harus dibayar penuh. Inilah yang disebut over-provisioning — inefisiensi finansial terbesar di era server fisik.

Virtualisasi: Awal Abstraksi Infrastruktur #

Sekitar awal tahun 2000-an, teknologi virtualisasi mulai memasuki industri secara masif melalui hypervisor seperti VMware ESX, Xen, dan kemudian KVM di lingkungan Linux. Untuk pertama kalinya, satu server fisik dapat dibagi secara logis menjadi banyak mesin virtual (Virtual Machine / VM) yang berjalan secara terisolasi satu sama lain.

Dampak Virtualisasi #

flowchart LR
    A["Server Fisik 1"] --> H1{"Hypervisor"}
    A2["Server Fisik 2"] --> H1
    H1 --> V1["VM App A"]
    H1 --> V2["VM App B"]
    H1 --> V3["VM App C"]
    H1 --> V4["VM Dev/Test"]

Virtualisasi membawa perubahan besar pada efisiensi penggunaan hardware:

Batasan yang Tidak Terpecahkan #

Meskipun virtualisasi berhasil memecahkan masalah efisiensi perangkat keras, paradigma pengelolaan operasional tidak banyak berubah. Bagi developer, sebuah VM tetaplah sebuah server. VM tetap memiliki sistem operasi lengkap yang membutuhkan pemeliharaan manual: patching keamanan, konfigurasi networking, instalasi package manager, manajemen user, dan penanganan kegagalan sistem. Beban administrasi sysadmin hanya bergeser dari fisik ke virtual.

Infrastructure as a Service (IaaS): Kelahiran Cloud Computing #

Tahun 2006 menandai lahirnya era komputasi awan modern ketika Amazon Web Services (AWS) meluncurkan Elastic Compute Cloud (EC2). AWS menyewakan VM (instans EC2) secara on-demand yang dapat dipesan secara instan melalui API (Application Programming Interface). Paradigma ini dikenal sebagai Infrastructure as a Service (IaaS).

Perbandingan IaaS dengan Data Center Tradisional #

IaaS Bukan Serverless #

Meskipun sangat memudahkan, IaaS tetap bukan serverless. Di dalam model IaaS, konsep server masih terekspos dengan sangat jelas kepada developer.

flowchart TD
    A["Developer"] -->|"masih urus"| B["OS + Runtime"]
    B --> C["VM / Instance"]
    C --> D["Hypervisor"]
    D --> E["Hardware Fisik"]

    style A stroke:#ff5555,stroke-width:2px
    style B stroke:#ff5555,stroke-width:2px

Warna merah pada diagram di atas menunjukkan layer yang masih menjadi tanggung jawab penuh developer di bawah model IaaS. Cloud provider menangani hardware fisik dan hypervisor, tetapi developer masih harus mengurus instalasi OS, dependensi runtime, manajemen auto-scaling, dan patching keamanan. Jika traffic aplikasi naik tiba-tiba, developer harus mendesain sendiri aturan auto-scaling group yang kompleks agar VM baru dapat menyala tepat waktu.

Platform as a Service (PaaS): Abstraksi Lebih Tinggi #

Melihat developer masih direpotkan oleh pengelolaan sistem operasi, Google mengambil langkah inovatif pada tahun 2008 dengan merilis Google App Engine (GAE), memperkenalkan konsep Platform as a Service (PaaS) ke pasar global.

Filosofi PaaS #

Filosofi PaaS didasarkan pada satu ide utama: developer tidak perlu tahu dan tidak perlu peduli tentang sistem operasi di bawah kodenya.

sequenceDiagram
    participant Dev as Developer
    participant PaaS as Platform
    participant Infra as Infrastructure

    Note over Dev,PaaS: Model Lama (IaaS)
    Dev->>Infra: provision server
    Dev->>Infra: install runtime
    Dev->>Infra: deploy code
    Dev->>Infra: configure scaling
    Dev->>Infra: monitor

    Note over Dev,PaaS: Model Baru (PaaS)
    Dev->>PaaS: push code
    PaaS->>Infra: handle semuanya
    Infra-->>PaaS: jalan
    PaaS-->>Dev: deployed ✓

Developer cukup melakukan push kode aplikasi ke platform, dan sistem PaaS yang akan mengurus kompilasi, penyediaan runtime, konfigurasi web server, load balancing, hingga auto-scaling dasar.

Penyedia Layanan PaaS Populer #

• Google App Engine (2008): Memelopori PaaS dengan dukungan awal untuk runtime Python dan Java.
• Heroku (2009): Sangat populer di kalangan startup karena kemudahan deployment lewat perintah git push heroku master.
• Microsoft Azure App Service (2010): Fokus pada integrasi erat dengan ekosistem .NET dan Windows Server.
• AWS Elastic Beanstalk (2011): Solusi PaaS dari AWS yang membungkus resource IaaS di bawahnya agar lebih mudah dikelola.

Keterbatasan PaaS #

PaaS menawarkan kecepatan deployment yang luar biasa, namun ia memiliki beberapa keterbatasan kritis yang membuatnya kurang fleksibel:

PaaS sangat cocok untuk:
  ✓ Aplikasi web monolitik standar (HTTP request/response)
  ✓ Tim pengembang kecil yang ingin fokus penuh ke kode
  ✓ Aplikasi dengan pola traffic yang relatif stabil dan umum

PaaS bermasalah untuk:
  ✗ Kebutuhan custom runtime atau bahasa pemrograman yang tidak didukung platform
  ✗ Modifikasi konfigurasi sistem operasi tingkat rendah (OS-level customization)
  ✗ Proses asinkron yang berjalan lama di latar belakang (background workers)
  ✗ Reaksi instan terhadap event eksternal non-HTTP (misal: trigger dari upload file storage)

Trade-off utama PaaS: kita menukar kontrol demi kemudahan operasional. Jika aplikasi membutuhkan pustaka sistem C++ native yang harus dikompilasi ke dalam OS, atau butuh protokol komunikasi kustom di luar HTTP/HTTPS, PaaS sering kali tidak dapat memenuhinya. Celah fleksibilitas inilah yang kemudian melahirkan era containerisasi (Docker) dan microservices.

Microservices dan Dorongan Arsitektur Modular #

Seiring dengan kemajuan teknologi infrastruktur, arsitektur perangkat lunak juga berevolusi dari model monolith (semua fitur dikemas dalam satu aplikasi raksasa) menuju arsitektur microservices (aplikasi dipecah menjadi unit-unit kecil yang independen).

Transisi dari Monolith ke Microservices #

flowchart TB
    subgraph Monolith[Arsitektur Monolith]
        M["Single Codebase<br/>Semua fitur dalam 1 app"]
    end

    subgraph Microservices[Arsitektur Microservices]
        S1["Service: Auth"]
        S2["Service: Catalog"]
        S3["Service: Order"]
        S4["Service: Payment"]
        S5["Service: Notification"]
    end

    Monolith -->|Decompose| Microservices

Tantangan Baru di Sisi Operasional #

Pemisahan aplikasi menjadi puluhan microservices independen memicu kompleksitas baru pada infrastruktur:

Tantangan Baru Arsitektur Microservices:
  ✗ 10 service berarti mengelola 10 pipeline deployment yang berbeda
  ✗ 50 service membutuhkan 50 dashboard monitoring terpisah
  ✗ 100 service memicu overhead komunikasi antar-layanan yang tinggi
  ✗ Mengalokasikan VM/server untuk tiap service kecil memicu pemborosan biaya
  ✗ Kesulitan mengoordinasikan scaling yang dinamis untuk tiap microservice

Industri mulai menyadari bahwa menjalankan satu service kecil di dalam satu VM/server virtual khusus sangat tidak efisien secara finansial dan operasional. Komunitas engineering membutuhkan sebuah model di mana mereka bisa menjalankan unit kode terkecil secara instan, tanpa harus membayar biaya sewa server 24/7 untuk service yang jarang dipanggil.

Momen Kunci: Lahirnya Function as a Service (FaaS) #

Tahun 2014 menjadi tonggak sejarah paling penting bagi gerakan serverless. Amazon Web Services memperkenalkan AWS Lambda di konferensi tahunan AWS re:Invent, secara resmi melahirkan kategori komputasi baru yang dinamakan Function as a Service (FaaS).

Pergeseran Paradigma Eksekusi Kode #

Sebelum kehadiran FaaS, pola pikir developer dalam mendeploy aplikasi adalah:

“Jalankan aplikasi ini di atas server secara terus-menerus, lalu biarkan server tersebut menunggu request yang masuk.”

Setelah FaaS lahir, pola pikir tersebut berubah total menjadi:

“Daftarkan fungsi kode ini ke platform cloud. Biarkan platform yang mengurus runtime-nya, dan jalankan kode tersebut hanya saat ada event spesifik yang memicunya.”

sequenceDiagram
    participant User
    participant API Gateway
    participant Lambda
    participant S3

    User->>API Gateway: GET /image
    API Gateway->>Lambda: invoke function
    Lambda->>S3: get object
    S3-->>Lambda: image data
    Lambda-->>API Gateway: response
    API Gateway-->>User: 200 OK + image

    Note over Lambda: Tidak ada server yang terus menyala.<br/>Lambda aktif hanya saat dipanggil,<br/>lalu langsung mati setelah selesai.

Karakteristik FaaS Dibandingkan IaaS dan PaaS #

Perkembangan Provider FaaS #

Peluncuran AWS Lambda memicu persaingan ketat di antara penyedia layanan cloud raksasa lainnya untuk menghadirkan layanan FaaS serupa:

• 2014: AWS meluncurkan AWS Lambda (pionir komersial).
• 2016: Google memperkenalkan Google Cloud Functions dan Microsoft meluncurkan Azure Functions.
• 2017: Cloudflare merilis Cloudflare Workers, mengeksekusi fungsi serverless langsung di lokasi edge terdekat dengan pengguna.
• 2018: Proyek open-source Knative diluncurkan oleh Google beserta konsorsium industri untuk standarisasi serverless di atas Kubernetes.

Contoh Struktur Kode FaaS (JavaScript Node.js) #

Sebuah fungsi serverless dirancang untuk menyelesaikan satu tugas spesifik dengan cepat.

// ANTI-PATTERN: Fungsi tunggal melakukan terlalu banyak tugas (Monolith di FaaS)
exports.handler = async (event) => {
    const user = await getUserFromDB(event.id);
    await sendWelcomeEmail(user);
    await updateSearchIndex(user);
    await notifySlack(user);
    await generateInvoice(user);
    return { statusCode: 200, body: 'User processed' };
};

// BENAR: Fungsi fokus pada satu tugas spesifik (Single Responsibility)
exports.handler = async (event) => {
    const user = await getUserFromDB(event.id);
    await sendWelcomeEmail(user);
    return { statusCode: 200, body: 'Email sent successfully' };
};

Aturan emas FaaS: sebuah fungsi harus bersifat stateless (tidak menyimpan data di memori lokal antar-pemanggilan), singkat (berjalan dalam hitungan detik), dan idempotent (aman dijalankan berulang kali dengan input yang sama tanpa menghasilkan efek samping ganda).

Evolusi Makna “Serverless” Modern #

Dalam perjalanannya, istilah “serverless” tidak lagi terbatas pada FaaS (komputasi fungsi). Istilah ini mengalami generalisasi makna untuk menggambarkan seluruh kategori layanan awan (managed services) yang mengadopsi karakteristik operasional bebas pengelolaan server.

Ekosistem Serverless Modern #

Arsitektur aplikasi serverless kini dapat dibangun secara utuh tanpa melibatkan server tradisional di bagian mana pun, berkat ketersediaan layanan pendukung berikut:

flowchart TD
    Root["Ekosistem Serverless"] --> Compute["Komputasi"]
    Compute --> Lambda["AWS Lambda"]
    Compute --> CF["Cloud Functions"]
    Compute --> AF["Azure Functions"]
    Compute --> CW["Cloudflare Workers"]

    Root --> DB["Database"]
    DB --> DynamoDB["DynamoDB"]
    DB --> Firestore["Firestore"]
    DB --> CosmosDB["Cosmos DB"]
    DB --> Aurora["Aurora Serverless"]

    Root --> Storage["Storage"]
    Storage --> S3["AWS S3"]
    Storage --> GCS["Cloud Storage"]
    Storage --> Blob["Blob Storage"]

    Root --> Msg["Messaging"]
    Msg --> SQS["SQS / SNS"]
    Msg --> PubSub["Pub/Sub"]
    Msg --> EventBridge["EventBridge"]

    Root --> Auth["Autentikasi"]
    Auth --> Cognito["Cognito"]
    Auth --> FireAuth["Firebase Auth"]
    Auth --> Auth0["Auth0"]

    Root --> Integration["Integrasi & Alur"]
    Integration --> APIGW["API Gateway"]
    Integration --> StepFn["Step Functions"]
    Integration --> Workflows["Workflows"]

Definisi Modern: “Tanpa Tanggung Jawab Operasional” #

Definisi terbaik serverless yang disepakati industri saat ini adalah:

# ANTI-PATTERN: "Serverless = tidak ada komputer/server fisik"
# Pemahaman ini keliru. Kode kita tetap berjalan di atas komputer fisik di data center cloud.

# BENAR: "Serverless = developer dibebaskan dari tanggung jawab mengelola server"
# Server fisik itu ada, tetapi seluruh kompleksitas penyediaan, pemeliharaan, scaling, 
# dan toleransi kegagalan ditangani sepenuhnya oleh cloud provider.

Serverless sebagai Konsekuensi Logis Evolusi #

Jika kita tarik garis sejarah ke belakang, serverless bukanlah sebuah inovasi yang terjadi secara tiba-tiba tanpa pola. Ia merupakan puncak dari tren abstraksi teknologi yang terus meningkat secara konsisten selama lebih dari 30 tahun terakhir.

Alur Tren Abstraksi Teknologi #

flowchart LR
    A["Abstraksi<br/>Makin Tinggi"] --> B["Beban Operasional<br/>Makin Ringan"]
    B --> C["Developer Fokus ke<br/>Bisnis, Bukan Infra"]
    C --> D["Time to Market<br/>Makin Cepat"]
    D --> A

    style A stroke:#0080ff,stroke-width:2px
    style B stroke:#00bb00,stroke-width:2px
    style C stroke:#ffaa00,stroke-width:2px
    style D stroke:#ff00aa,stroke-width:2px

Melalui sejarah ini, kita dapat melihat bahwa setiap pergeseran teknologi selalu bertujuan untuk menghilangkan detail infrastruktur yang tidak relevan dengan logika bisnis sehingga produk dapat dirilis ke pasar dengan jauh lebih cepat.

Ringkasan #

• Serverless adalah puncak evolusi arsitektur infrastruktur selama 30 tahun terakhir, bergerak dari Server Fisik → Mesin Virtual (VM) → IaaS (Cloud VM) → PaaS (Runtime Managed) → FaaS/Serverless.
• Masalah utama yang diselesaikan adalah inefisiensi biaya operasional server akibat over-provisioning dan tingginya beban administrasi sistem (patching OS, scaling manual, monitoring hardware).
• Lahirnya AWS Lambda pada 2014 memperkenalkan model FaaS (Function as a Service) yang mengeksekusi kode secara event-driven dan on-demand, mengubah unit deployment dari level server/aplikasi ke level fungsi tunggal.
• Definisi serverless modern tidak berarti meniadakan server, melainkan memindahkan seluruh tanggung jawab pengelolaan server tersebut secara penuh kepada penyedia layanan cloud.
• Ekosistem serverless kini mencakup seluruh layer aplikasi, mulai dari komputasi (FaaS & Container), database relasional/NoSQL, messaging queues, otentikasi pengguna, hingga penyimpanan file.

← Sebelumnya: Pengenalan Aplikasi Serverless   Berikutnya: Kenapa Serverless →