Π΅Π²ΡΠ΅ ΠΎΠΌΠ΅Π½ΡΡ
- Sudah beberapa tahun ini kita dijanjikan bahwa komputasi tanpa server (serverless) akan membuka era baru tanpa OS khusus untuk menjalankan aplikasi. Kami diberi tahu bahwa struktur seperti itu akan menyelesaikan banyak masalah skalabilitas. Nyatanya, semuanya berbeda.
- Meskipun banyak yang melihat teknologi tanpa server sebagai ide baru, akarnya dapat ditelusuri hingga tahun 2006 dengan Zimki PaaS dan Google App Engine, keduanya menggunakan arsitektur tanpa server.
- Ada empat alasan mengapa revolusi tanpa server terhenti, mulai dari dukungan bahasa pemrograman yang terbatas hingga masalah kinerja.
- Komputasi tanpa server sama sekali tidak berguna. Jauh dari itu. Namun, mereka tidak boleh dilihat sebagai pengganti langsung untuk server. Untuk beberapa aplikasi, mereka bisa menjadi alat yang berguna.
Server mati, hidup server!
Inilah seruan perang para penganut revolusi tanpa server. Sekilas pers industri selama beberapa tahun terakhir sudah cukup 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 di artikel kami di , ini salah. Meskipun banyak artikel tentang manfaat , itu tidak pernah terjadi. Nyatanya, bahwa revolusi ini mungkin telah menemui jalan buntu.
Beberapa janji untuk model tanpa server memang menjadi kenyataan, tetapi tidak semuanya. Tidak semua orang.
Pada artikel ini saya ingin mempertimbangkan alasan kondisi ini. Mengapa kurangnya fleksibilitas model tanpa server masih menjadi kendala untuk adopsi yang lebih luas, meskipun tetap berguna dalam keadaan tertentu yang terdefinisi dengan baik.
Apa yang dijanjikan oleh ahli komputasi tanpa server
Sebelum beralih ke masalah komputasi tanpa server, mari kita lihat apa yang harus mereka sediakan. banyak dan - kadang - 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) berjalan sesuai permintaan di lingkungan runtime yang biasanya dihosting dari jarak jauh. Selain itu, sistem tanpa server dapat dihosting. Membangun sistem tanpa server yang kuat telah menjadi perhatian utama administrator sistem dan perusahaan SaaS selama beberapa tahun terakhir, karena (diklaim) arsitektur ini menawarkan beberapa keunggulan utama dibandingkan model klien/server "tradisional":
- Model tanpa server tidak mengharuskan pengguna untuk memelihara sistem operasinya sendiri atau bahkan membuat aplikasi yang kompatibel dengan sistem operasi tertentu. Sebagai gantinya, pengembang membuat kode bersama, mengunggahnya ke platform tanpa server, dan melihatnya berjalan.
- Sumber daya dalam kerangka kerja tanpa server biasanya ditagih per menit (atau bahkan detik). Ini berarti klien hanya membayar saat mereka benar-benar mengeksekusi kode. Ini lebih baik dibandingkan dengan VM cloud tradisional, di mana mesin hampir selalu menganggur, tetapi Anda harus membayarnya.
- Masalah skalabilitas juga terpecahkan. Sumber daya dalam kerangka kerja tanpa server ditugaskan secara dinamis sehingga sistem dapat dengan mudah mengatasi lonjakan permintaan yang tiba-tiba.
Singkatnya, model tanpa server memberikan solusi yang fleksibel, murah, dan dapat diskalakan. Saya terkejut kami tidak memikirkan ide ini sebelumnya.
Apakah ini benar-benar ide baru?
Sebenarnya ide tersebut bukanlah hal baru. Konsep memungkinkan pengguna untuk membayar hanya untuk saat kode benar-benar berjalan telah ada sejak diperkenalkan di bawah pada tahun 2006, dan sekitar waktu yang sama, Google App Engine menghasilkan solusi yang sangat mirip.
Faktanya, apa yang sekarang kita sebut model "tanpa server" lebih tua dari banyak teknologi yang sekarang disebut "cloud native" yang menyediakan hampir sama. Seperti disebutkan, 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 komputasi-sentris dari arsitektur tanpa server, tetapi tidak mewakili keseluruhan sistem.
Jadi mengapa semua hype ini? Nah, karena tingkat penetrasi Internet di negara-negara berkembang terus meroket, begitu pula permintaan akan sumber daya komputasi. Misalnya, banyak negara dengan sektor e-commerce yang berkembang pesat tidak memiliki infrastruktur komputasi untuk aplikasi pada platform ini. Di sinilah platform tanpa server berbayar masuk.
Masalah dengan Model Tanpa Server
Tangkapannya adalah bahwa model tanpa server memiliki⦠masalah. Jangan salah paham: Saya tidak mengatakan mereka buruk dalam diri mereka sendiri atau tidak memberikan nilai yang signifikan bagi beberapa perusahaan dalam beberapa keadaan. Tetapi klaim utama dari "revolusi" - bahwa arsitektur tanpa server akan segera menggantikan arsitektur tradisional - tidak pernah membuahkan hasil.
Itu sebabnya.
Dukungan terbatas untuk bahasa pemrograman
Sebagian besar platform tanpa server hanya mengizinkan aplikasi yang ditulis dalam bahasa tertentu untuk dijalankan. Ini sangat membatasi fleksibilitas dan kemampuan beradaptasi dari sistem ini.
Platform tanpa server dianggap mendukung sebagian besar bahasa utama. AWS Lambda dan Azure Functions juga menyediakan pembungkus untuk menjalankan aplikasi dan fungsi dalam bahasa yang tidak didukung, meskipun hal ini sering menimbulkan biaya kinerja. Jadi bagi sebagian besar organisasi, batasan ini biasanya bukan masalah besar. Tapi inilah masalahnya. Salah satu keuntungan dari model tanpa server seharusnya program yang tidak jelas dan jarang digunakan dapat digunakan dengan lebih murah karena Anda hanya membayar waktu program berjalan. Dan program yang tidak jelas dan jarang digunakan sering kali ditulis dalam... bahasa pemrograman yang tidak jelas dan jarang digunakan.
Ini melemahkan salah satu keuntungan utama dari model tanpa server.
Mengikat ke vendor
Masalah kedua dengan platform tanpa server, atau setidaknya cara penerapannya saat ini, adalah bahwa platform tersebut biasanya tidak mirip di tingkat operasional. Praktis tidak ada standarisasi dalam hal penulisan fungsi, penyebaran dan manajemen. Ini berarti bahwa memigrasikan fitur dari satu platform ke platform lainnya sangat memakan waktu.
Bagian tersulit dari beralih ke model tanpa server bukanlah fitur komputasi, yang biasanya hanya potongan kode, tetapi cara aplikasi berkomunikasi dengan sistem yang terhubung seperti penyimpanan objek, manajemen identitas, dan antrean. Fungsi dapat dipindahkan, tetapi aplikasi lainnya tidak bisa. Ini kebalikan dari platform murah dan fleksibel yang dijanjikan.
Beberapa berpendapat bahwa model tanpa server adalah baru dan belum ada waktu untuk membakukan cara kerjanya. Tapi mereka tidak begitu baru, seperti yang saya sebutkan di atas, dan banyak teknologi cloud lainnya seperti kontainer telah menjadi jauh lebih nyaman karena pengembangan dan penerapan standar yang baik secara luas.
Performa
Performa komputasi platform tanpa server sulit diukur, sebagian karena vendor cenderung merahasiakan informasi. Sebagian besar berpendapat bahwa fitur pada platform jarak jauh tanpa server berjalan secepat yang mereka lakukan pada server internal, kecuali beberapa masalah latensi yang tak terhindarkan.
Namun, beberapa bukti menunjukkan sebaliknya. Fungsi yang sebelumnya tidak berjalan pada platform tertentu, atau tidak berjalan selama beberapa waktu, membutuhkan waktu untuk diinisialisasi. Ini mungkin karena kode mereka telah dipindahkan ke beberapa media penyimpanan yang kurang tersedia, meskipun - seperti tolok ukur - sebagian besar vendor tidak akan memberi tahu Anda tentang memindahkan data.
Tentu saja, ada beberapa cara untuk menyiasatinya. Salah satunya adalah mengoptimalkan fitur untuk bahasa cloud apa pun yang dijalankan oleh platform tanpa server Anda, tetapi hal itu agak melemahkan klaim bahwa platform ini "lincah".
Pendekatan lain adalah memastikan bahwa program-program kritis kinerja dijalankan secara teratur agar tetap "segar". Pendekatan kedua ini, tentu saja, sedikit berlawanan dengan klaim bahwa platform tanpa server lebih hemat biaya karena Anda hanya membayar saat program Anda berjalan. Penyedia cloud telah memperkenalkan cara baru untuk mengurangi cold start, tetapi banyak dari mereka memerlukan "skala ke satu" (skala ke satu), yang menggerogoti nilai asli FaaS.
Masalah cold start sebagian dapat diatasi dengan menjalankan sistem tanpa server secara internal, tetapi ini datang dengan biaya sendiri dan tetap menjadi opsi khusus untuk tim yang memiliki sumber daya yang baik.
Anda tidak dapat menjalankan seluruh aplikasi
Akhirnya, mungkin alasan paling penting mengapa arsitektur tanpa server tidak akan menggantikan model tradisional dalam waktu dekat adalah karena mereka (umumnya) tidak dapat menjalankan seluruh aplikasi.
Lebih tepatnya, ini tidak praktis dari sudut pandang biaya. Monolit Anda yang sukses mungkin tidak boleh diubah menjadi sekumpulan empat lusin fungsi yang diikat menjadi satu oleh delapan gateway, empat puluh antrean, dan selusin instans database. Karena alasan ini, tanpa server lebih cocok untuk perkembangan baru. Hampir tidak ada aplikasi (arsitektur) yang ada yang dapat di-porting. Anda dapat bermigrasi, tetapi Anda harus memulai dari awal.
Ini berarti bahwa dalam sebagian besar kasus, platform tanpa server digunakan sebagai pelengkap server back-end untuk melakukan tugas intensif komputasi. 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 untuk bermigrasi dari layanan mikro ke sistem tanpa server.
Tentu saja, ini tidak selalu menjadi masalah. Kemampuan untuk menggunakan sumber daya komputasi yang sangat besar secara berkala tanpa membeli perangkat keras Anda sendiri dapat memberikan manfaat yang nyata dan bertahan lama bagi banyak organisasi. Tetapi jika beberapa aplikasi ada di server internal dan yang lainnya di arsitektur cloud tanpa server, manajemen memasuki tingkat kerumitan baru.
Hidup revolusi?
Terlepas dari semua keluhan ini, saya tidak menentang solusi tanpa server itu sendiri. Sejujurnya. Hanya saja pengembang perlu memahami - terutama jika mereka menjelajahi model tanpa server untuk pertama kalinya - bahwa teknologi ini bukanlah pengganti langsung untuk server. Sebagai gantinya, lihat tips dan sumber daya kami di dan memutuskan cara terbaik untuk menerapkan model ini.
Sumber: www.habr.com