Di Mana Aplikasi Anda Akan Berjalan? Server, Container, Serverless, atau Edge

Anda telah membangun sebuah aplikasi. Aplikasi itu berjalan di laptop Anda. Sekarang Anda perlu menempatkannya di suatu tempat agar orang lain dapat menggunakannya. Pertanyaan sederhana — "di mana aplikasi ini akan hidup?" — membentuk segala hal tentang cara Anda membangun, menguji, dan mengirimkan perangkat lunak.

Jawabannya jarang hanya satu hal. Mungkin aplikasi Anda berjalan di server fisik di lemari kantor. Mungkin berjalan di mesin virtual di cloud. Mungkin dikemas sebagai container yang dikelola oleh Kubernetes. Mungkin berjalan sebagai fungsi serverless yang hanya ada saat dipanggil. Atau mungkin perlu berjalan di edge, dekat dengan pengguna, di perangkat IoT atau node jaringan.

Setiap target ini mengubah cara Anda mendesain pipeline CI/CD. Perkakas itu penting, tetapi pertanyaan yang lebih dalam adalah tentang apa yang perlu ditangani oleh pipeline Anda. Mari kita bahas setiap target dan lihat apa yang berubah.

Deployment ke Server: Fisik atau Virtual

Saat Anda melakukan deployment langsung ke server, pipeline Anda perlu menangani seluruh tumpukan. Anda tidak hanya mengirimkan kode. Anda mengirimkan aplikasi yang membutuhkan sistem operasi tertentu, middleware tertentu, versi library tertentu, dan file konfigurasi tertentu.

Proses build Anda biasanya menghasilkan biner, paket, atau sekumpulan file. Pipeline Anda kemudian mentransfer file-file tersebut ke server, menginstalnya, dan memulai ulang aplikasi. Rollback berarti mengganti file atau kembali ke versi sebelumnya di mesin yang sama.

Pipeline untuk deployment server cenderung lebih panjang. Anda memerlukan langkah-langkah untuk provisioning server, menginstal dependensi, mengonfigurasi lingkungan, dan memverifikasi bahwa semuanya berfungsi bersama. Jika Anda mengelola beberapa server, Anda juga perlu mengoordinasikan pembaruan di seluruh server tersebut.

Keuntungannya adalah kontrol. Anda memutuskan persis apa yang berjalan di mesin. Kerugiannya adalah setiap server menjadi unik (snowflake). Perbedaan kecil antar lingkungan — versi library yang sedikit berbeda, file konfigurasi yang diedit secara manual — dapat menyebabkan masalah yang sulit direproduksi.

Deployment ke Container

Container mengubah permainan. Aplikasi Anda dan semua dependensinya dikemas ke dalam sebuah image. Image itu dibangun sekali dan di-deploy ke mana saja. Lingkungan di dalam container konsisten di seluruh pengembangan, pengujian, dan produksi.

Pipeline Anda menggeser fokus. Alih-alih mengelola konfigurasi server, Anda fokus pada membangun image, menyimpannya di registry, dan men-deploy-nya ke platform orkestrasi seperti Kubernetes. Rollback menjadi lebih sederhana: Anda cukup menunjuk ke versi image sebelumnya.

Namun tantangan baru muncul. Anda perlu memastikan image aman. Anda perlu mengelola versi dan tag image. Anda perlu memperbarui container yang sedang berjalan tanpa mengganggu lalu lintas. Anda juga perlu menangani komponen stateful seperti database, yang tidak cocok dengan model container.

Container memberi Anda konsistensi dan portabilitas. Tetapi mereka membutuhkan pemahaman tentang runtime container, orkestrasi, dan jaringan. Tim Anda perlu belajar cara men-debug masalah yang terjadi di dalam container, bukan hanya di server.

Deployment ke Serverless

Serverless membawa abstraksi lebih jauh. Anda tidak perlu memikirkan server sama sekali. Anda menulis fungsi, mengunggahnya ke platform, dan platform menangani eksekusi, penskalaan, dan ketersediaan.

Pipeline Anda menjadi lebih sederhana dalam beberapa hal. Anda hanya perlu mengemas kode fungsi dan men-deploy-nya. Tidak ada server yang perlu di-provision, tidak ada sistem operasi yang perlu dikonfigurasi, tidak ada container yang perlu dikelola.

Namun tantangan bergeser ke area lain. Bagaimana Anda mengelola versi fungsi? Bagaimana Anda mengonfigurasi variabel lingkungan dan rahasia? Bagaimana Anda menguji fungsi Anda ketika lingkungan eksekusi tidak sepenuhnya di bawah kendali Anda? Bagaimana Anda menangani cold start, di mana fungsi membutuhkan waktu lebih lama untuk merespons karena belum dipanggil baru-baru ini?

Serverless bekerja dengan baik untuk beban kerja berbasis peristiwa, API dengan lalu lintas variabel, dan tugas yang berjalan secara intermiten. Ini mengurangi overhead operasional tetapi membatasi kendali Anda atas lingkungan runtime.

Deployment ke Edge

Deployment edge menambahkan jenis kompleksitas yang berbeda. Aplikasi Anda perlu berjalan di banyak lokasi, seringkali dengan sumber daya terbatas. Bayangkan perangkat IoT, router, node CDN, atau sistem point-of-sale ritel.

Pipeline Anda harus menangani distribusi pembaruan ke ribuan atau jutaan perangkat. Beberapa perangkat mungkin offline saat Anda mendorong pembaruan. Beberapa mungkin memiliki koneksi jaringan yang tidak dapat diandalkan. Beberapa mungkin berjalan di perangkat keras yang tidak dapat Anda ganti dengan mudah.

Rollback di edge itu sulit. Anda tidak bisa begitu saja membalik sakelar dan mengembalikan semua perangkat sekaligus. Anda memerlukan strategi untuk peluncuran bertahap, untuk menangani perangkat yang melewatkan pembaruan, dan untuk memulihkan perangkat yang gagal setelah pembaruan.

Deployment edge bukan hanya tentang perangkat lunak. Ini tentang logistik. Bagaimana Anda memastikan bahwa perangkat di lokasi terpencil mendapatkan versi yang tepat? Bagaimana Anda memantau perangkat yang tidak selalu terhubung? Bagaimana Anda menangani perangkat yang kehabisan penyimpanan atau memori?

Target Tidak Bersifat Permanen

Ini masalahnya: target deployment Anda bukanlah keputusan permanen. Aplikasi yang sama dapat berpindah antar target seiring waktu. Anda mungkin memulai dengan server fisik, pindah ke mesin virtual, lalu ke container, dan kemudian membagi bagian-bagian aplikasi menjadi fungsi serverless.

Setiap perpindahan mengubah pipeline Anda. Proses build berubah. Strategi deployment berubah. Mekanisme rollback berubah. Persyaratan pemantauan dan observabilitas berubah.

Kuncinya adalah memahami apa yang dibutuhkan setiap target dari pipeline Anda, bukan hanya alat apa yang digunakan. Ketika Anda mengetahui implikasinya, Anda dapat mendesain pipeline yang sesuai dengan kebutuhan aktual Anda, bukan sekadar tren terbaru.

Daftar Periksa Praktis untuk Memilih Target Deployment

Sebelum Anda berkomitmen pada suatu target, jalankan pertanyaan-pertanyaan ini:

Diagram alir berikut dapat membantu Anda memvisualisasikan bagaimana jawaban Anda atas pertanyaan-pertanyaan tersebut mengarah ke target deployment.

flowchart TD A[Mulai: Apa kebutuhan Anda?] --> B{Kontrol penuh atas lingkungan?} B -- Ya --> C[Server: fisik atau VM] B -- Tidak --> D{Lingkungan konsisten di seluruh deployment?} D -- Ya --> E[Container: Docker, Kubernetes] D -- Tidak --> F{Berbasis peristiwa atau lalu lintas variabel?} F -- Ya --> G[Serverless: fungsi] F -- Tidak --> H{Banyak lokasi terdistribusi?} H -- Ya --> I[Edge: IoT, CDN] H -- Tidak --> J[Evaluasi ulang persyaratan] C --> K[Pertimbangkan: provisioning, manajemen konfigurasi, kompleksitas rollback] E --> L[Pertimbangkan: keamanan image, orkestrasi, layanan stateful] G --> M[Pertimbangkan: cold start, kontrol runtime terbatas, pengujian] I --> N[Pertimbangkan: pembaruan offline, peluncuran bertahap, manajemen perangkat]
  • Di mana tim Anda memiliki pengalaman paling banyak? Tim yang mengenal server dengan baik akan lebih sedikit kesulitan dengan deployment server dibandingkan dengan Kubernetes.
  • Seberapa besar kendali yang Anda butuhkan atas lingkungan runtime? Lebih banyak kendali berarti lebih banyak kompleksitas pipeline.
  • Bagaimana Anda akan menangani rollback? Beberapa target membuat rollback mudah (container), yang lain membuatnya menyakitkan (perangkat edge).
  • Bagaimana Anda akan menguji deployment? Lingkungan serverless dan edge lebih sulit direplikasi secara lokal.
  • Bagaimana pola lalu lintas Anda? Lalu lintas stabil lebih cocok untuk container atau server. Lalu lintas spiky lebih cocok untuk serverless.
  • Berapa banyak instance yang perlu Anda kelola? Beberapa server masih bisa dikelola. Ribuan perangkat edge memerlukan pendekatan yang berbeda.

Yang Paling Penting

Target deployment menentukan bentuk pipeline Anda. Ia menentukan apa yang dihasilkan oleh build Anda, bagaimana pengujian Anda berjalan, bagaimana pembaruan Anda mencapai pengguna, dan bagaimana Anda pulih dari kegagalan.

Pilihlah berdasarkan kebutuhan aplikasi Anda, kemampuan tim Anda, dan realitas operasional Anda. Bukan karena container populer atau serverless adalah masa depan. Target yang tepat adalah target yang dapat Anda operasikan dengan andal, perbarui dengan aman, dan debug secara efektif ketika terjadi kesalahan.

Pipeline Anda harus mencerminkan pilihan itu, bukan melawannya.