Poin-poin penting
- Selama beberapa tahun ini, kami telah dijanjikan bahwa komputasi tanpa server akan mengantarkan era baru tanpa OS khusus untuk menjalankan aplikasi. Kami diberi tahu bahwa struktur seperti itu akan menyelesaikan banyak masalah skalabilitas. Padahal, semuanya berbeda.
- Meskipun banyak yang melihat teknologi tanpa server sebagai ide baru, akarnya dapat ditelusuri kembali ke tahun 2006, ketika Zimki PaaS dan Google App Engine diperkenalkan, keduanya menggunakan arsitektur tanpa server.
- Ada empat alasan mengapa revolusi tanpa server terhenti, dari dukungan terbatas untuk bahasa pemrograman hingga masalah kinerja.
- Komputasi tanpa server tidak begitu berguna. Tidak semuanya. Namun, mereka tidak boleh dilihat sebagai pengganti langsung untuk server. Untuk beberapa aplikasi, mereka bisa menjadi alat yang berguna.
Server mati, server hidup lama!
Ini adalah seruan para ahli revolusi tanpa server. Dengan melihat sekilas pers industri beberapa tahun terakhir, mudah untuk menyimpulkan bahwa model server tradisional sudah mati dan dalam beberapa tahun kita semua akan menggunakan arsitektur tanpa server.
Seperti yang diketahui siapa pun di industri ini, dan seperti yang juga kami tunjukkan dalam artikel kami tentang status Komputasi Tanpa Server , ini bukanlah masalahnya. Meskipun banyak artikel tentang manfaat Revolusi Tanpa Server , itu tidak pernah terwujud . Faktanya, penelitian terbaru menunjukkan bahwa revolusi ini mungkin menemui jalan buntu.
Tidak diragukan lagi, beberapa janji untuk model tanpa server telah terwujud, tetapi tidak semua. Tidak semua orang.
Pada artikel ini, saya ingin mempertimbangkan alasan dari kondisi ini. Mengapa kurangnya fleksibilitas model tanpa server masih menjadi kendala untuk adopsi yang lebih luas, meskipun model tersebut tetap berguna dalam keadaan tertentu yang ditentukan dengan baik.
Apa yang Dijanjikan oleh Pendukung Komputasi Tanpa Server
Sebelum masuk ke masalah komputasi tanpa server, mari kita lihat apa yang harus mereka sediakan. Janji dari revolusi tanpa server sangat banyak dan - terkadang - sangat ambisius.
Bagi mereka yang tidak terbiasa dengan istilah tersebut, berikut adalah definisi singkatnya. Komputasi tanpa server mendefinisikan arsitektur di mana aplikasi (atau bagian dari aplikasi) dijalankan sesuai permintaan di lingkungan runtime yang biasanya dihosting dari jarak jauh. Selain itu, sistem tanpa server dapat dihosting. Selama beberapa tahun terakhir, membangun sistem tanpa server yang tangguh telah menjadi perhatian utama bagi sysadmin dan perusahaan SaaS, karena (diduga) arsitektur ini menawarkan beberapa keunggulan utama dibandingkan model klien / server "tradisional":
- , , . , .
- ( ). , , . VM, , .
- . , .
Singkatnya, model tanpa server memberikan solusi yang fleksibel, berbiaya rendah, dan dapat diskalakan. Sungguh menakjubkan bahwa kami tidak menemukan ide ini sebelumnya.
Apakah ini benar-benar ide baru?
Padahal, idenya bukanlah hal baru. Konsep yang memungkinkan pengguna membayar hanya untuk waktu yang benar-benar dijalankan kode telah ada sejak diperkenalkan sebagai bagian dari Zimki PaaS pada tahun 2006, dan sekitar waktu yang sama Google App Engine menawarkan solusi yang sangat mirip.
Faktanya, apa yang sekarang kita sebut model "tanpa server" lebih tua daripada banyak teknologi yang sekarang disebut teknologi "cloud native" yang menyediakan hampir semua hal yang sama. Seperti dicatat, model tanpa server pada dasarnya hanyalah perpanjangan dari model bisnis SaaS yang telah ada selama beberapa dekade.
Perlu juga diketahui bahwa model tanpa server bukanlah arsitektur FaaS, meskipun ada hubungan antara keduanya. FaaS pada dasarnya adalah bagian yang berorientasi komputasi dari arsitektur tanpa server, tetapi tidak mewakili keseluruhan sistem.
Jadi apa yang diributkan itu? Nah, seiring kecepatan penetrasi Internet di negara berkembang yang terus meroket, permintaan akan sumber daya komputasi juga meningkat. Misalnya, banyak negara dengan sektor e-commerce yang berkembang pesat tidak memiliki infrastruktur komputasi untuk aplikasi pada platform ini. Di sinilah platform berbayar tanpa server masuk.
Masalah model tanpa server
Hasil tangkapannya adalah bahwa model tanpa server memiliki… masalah. Jangan salah paham: Saya tidak mengatakan bahwa mereka sendiri buruk atau bahwa mereka tidak memberikan nilai yang signifikan kepada beberapa perusahaan dalam beberapa keadaan. Tetapi klaim utama dari "revolusi" - bahwa arsitektur tanpa server akan segera menggantikan arsitektur tradisional - tidak pernah terwujud.
Karena itulah.
Dukungan terbatas untuk bahasa pemrograman
Kebanyakan platform tanpa server hanya mengizinkan aplikasi yang ditulis dalam bahasa tertentu untuk dijalankan. Ini sangat membatasi fleksibilitas dan kemampuan beradaptasi sistem ini.
Platform tanpa server diyakini mendukung sebagian besar bahasa utama. AWS Lambda dan Azure Functions juga menyediakan pembungkus untuk menjalankan aplikasi dan fungsi dalam bahasa yang tidak didukung, meskipun ini sering kali disertai dengan biaya kinerja. Jadi untuk kebanyakan organisasi, batasan ini biasanya tidak terlalu menjadi masalah. Tapi inilah masalahnya. Diasumsikan bahwa salah satu keuntungan dari model tanpa server adalah program yang jarang diketahui dan jarang digunakan dapat digunakan lebih murah karena Anda hanya membayar waktu eksekusi. Dan program yang kurang dikenal dan jarang digunakan sering kali ditulis dalam ... bahasa pemrograman yang jarang digunakan dan kurang dikenal.
Ini merusak salah satu manfaat utama dari model tanpa server.
Vendor mengikat
Masalah kedua dengan platform tanpa server, atau setidaknya cara penerapannya saat ini, adalah bahwa platform tersebut biasanya tidak terlihat sama di tingkat operasional. Praktis tidak ada standarisasi dalam hal penulisan fungsi, penerapan dan manajemen. Artinya, memigrasi fitur dari satu platform ke platform lain sangat memakan waktu.
Bagian tersulit dari pindah ke model tanpa server bukanlah fungsi komputasi, yang biasanya hanya berupa potongan kode, tetapi bagaimana aplikasi berhubungan dengan sistem yang terhubung seperti penyimpanan objek, manajemen identitas, dan antrian. Fungsi dapat dipindahkan, tetapi aplikasi lainnya tidak bisa. Ini adalah kebalikan dari platform berbiaya rendah dan fleksibel yang dijanjikan.
Beberapa orang berpendapat bahwa model tanpa server adalah baru dan belum ada waktu untuk menstandarkan cara kerjanya. Namun tidak semuanya baru, seperti yang saya sebutkan di atas, dan banyak teknologi cloud lainnya seperti container telah menjadi jauh lebih dapat digunakan melalui pengembangan dan adopsi standar yang baik secara luas.
Performa
Kinerja komputasi platform tanpa server sulit diukur, sebagian karena vendor cenderung merahasiakan informasi. Sebagian besar berpendapat bahwa fitur pada platform jarak jauh dan tanpa server sama cepatnya dengan di server internal, kecuali beberapa masalah latensi yang tak terhindarkan.
Namun, beberapa fakta menunjukkan sebaliknya. Fungsi yang sebelumnya tidak berjalan pada platform tertentu atau tidak berjalan selama beberapa waktu membutuhkan waktu untuk diinisialisasi. Ini mungkin karena fakta bahwa kode mereka di-porting ke beberapa media penyimpanan yang kurang dapat diakses, meskipun - seperti dalam kasus benchmark - sebagian besar vendor tidak akan memberi tahu Anda tentang transfer data.
Tentu saja ada beberapa cara untuk menyiasatinya. Salah satunya adalah mengoptimalkan fungsionalitas untuk bahasa cloud apa pun yang dijalankan oleh platform tanpa server Anda, tetapi hal itu agak merongrong klaim bahwa platform ini "fleksibel".
Pendekatan lain adalah untuk memastikan bahwa program-program yang kritis terhadap kinerja dijalankan secara teratur untuk menjaganya tetap segar. Pendekatan kedua ini, tentu saja, bertentangan dengan klaim bahwa platform tanpa server lebih hemat biaya karena Anda hanya membayar untuk waktu program Anda berjalan. Penyedia cloud telah memperkenalkan cara baru untuk mengurangi start cold, tetapi banyak di antaranya memerlukan "skala ke satu", yang merusak nilai asli FaaS.
Masalah cold start sebagian dapat diatasi dengan menjalankan sistem tanpa server di dalam perusahaan, tetapi ini menimbulkan biaya dan tetap menjadi pilihan khusus untuk tim yang memiliki sumber daya yang baik.
Anda tidak dapat menjalankan seluruh aplikasi
Terakhir, mungkin alasan terpenting mengapa arsitektur tanpa server tidak akan menggantikan model tradisional dalam waktu dekat: mereka (biasanya) tidak dapat menjalankan seluruh aplikasi.
Lebih tepatnya, ini tidak hemat biaya. Monolit Anda yang berhasil mungkin tidak boleh diubah menjadi satu set empat lusin fungsi yang dihubungkan oleh delapan gateway, empat puluh antrian, dan selusin contoh database. Untuk alasan ini, tanpa server lebih cocok untuk pengembangan baru. Hampir tidak ada aplikasi (arsitektur) yang ada yang dapat dimigrasi. Anda dapat bermigrasi, tetapi Anda harus memulai dari awal.
Ini berarti bahwa dalam sebagian besar kasus, platform tanpa server digunakan untuk melengkapi server back-end untuk melakukan tugas komputasi intensif. Ini sangat berbeda dari dua bentuk komputasi awan lainnya, kontainer dan mesin virtual, yang menawarkan cara holistik untuk melakukan komputasi jarak jauh. Ini menggambarkan salah satu tantangan dalam berpindah dari layanan mikro ke sistem tanpa server.
Tentu saja, ini tidak selalu menjadi masalah. Kemampuan untuk menggunakan sumber daya komputasi besar-besaran secara berkala tanpa membeli perangkat keras Anda sendiri dapat memberikan manfaat nyata dan bertahan lama bagi banyak organisasi. Tetapi jika beberapa aplikasi berada di server internal dan lainnya di arsitektur cloud tanpa server, maka manajemen mencapai tingkat kerumitan yang baru.
Hidup revolusi?
Terlepas dari semua keluhan ini, saya tidak menentang solusi tanpa server itu sendiri. Secara jujur. Hanya saja pengembang perlu memahami - terutama jika mereka menjelajahi model tanpa server untuk pertama kalinya - bahwa teknologi ini bukanlah pengganti langsung untuk server. Alih-alih, lihat kiat dan sumber daya kami untuk membuat aplikasi tanpa server dan lihat cara terbaik untuk menerapkan model ini.