Serverless bukan tentang ketiadaan fisik server. Ini bukan "pembunuh" kontainer dan bukan tren yang lewat. Ini adalah pendekatan baru untuk membangun sistem di cloud. Pada artikel hari ini, kita akan menyentuh arsitektur aplikasi Serverless, lihat apa peran penyedia layanan Serverless dan proyek sumber terbuka. Pada akhirnya, kita akan berbicara tentang Serverless.
Saya ingin menulis sisi server dari aplikasi (ya bahkan toko online). Ini bisa berupa obrolan, layanan untuk menerbitkan konten, atau penyeimbang beban. Bagaimanapun, akan ada banyak sakit kepala: Anda harus menyiapkan infrastruktur, menentukan ketergantungan aplikasi, dan memikirkan sistem operasi host. Maka Anda perlu memperbarui komponen kecil yang tidak mempengaruhi pekerjaan monolit lainnya. Nah, jangan lupa tentang penskalaan di bawah beban.
Tetapi bagaimana jika kita mengambil wadah sementara di mana dependensi yang diperlukan sudah diinstal sebelumnya, dan wadah itu sendiri terisolasi satu sama lain dan dari OS host? Kami akan memecah monolith menjadi layanan microser, yang masing-masing dapat diperbarui dan diskalakan secara terpisah dari yang lain. Setelah menempatkan kode dalam wadah seperti itu, saya dapat menjalankannya pada infrastruktur apa pun. Sudah lebih baik.
Dan jika Anda tidak ingin mengkonfigurasi kontainer? Saya tidak ingin berpikir tentang meningkatkan aplikasi. Saya tidak ingin membayar kontainer yang tidak digunakan saat beban pada layanan minimal. Saya ingin menulis kode. Fokus pada logika bisnis dan produk pasar dengan kecepatan cahaya.
Pikiran-pikiran seperti itu menuntun saya ke komputasi tanpa server. Serverless dalam hal ini
tidak berarti
tidak adanya server secara fisik, tetapi tidak adanya sakit kepala untuk manajemen infrastruktur.Idenya adalah bahwa logika aplikasi dipecah menjadi fungsi-fungsi independen. Mereka memiliki struktur acara. Masing-masing fungsi melakukan satu "mikrotask". Semua yang diperlukan dari pengembang adalah memuat fungsi ke konsol yang disediakan oleh penyedia cloud dan menghubungkannya dengan sumber acara. Kode akan dieksekusi berdasarkan permintaan dalam wadah yang disiapkan secara otomatis, dan saya hanya akan membayar untuk waktu eksekusi.
Mari kita lihat bagaimana proses pengembangan aplikasi sekarang.
Dari pengembang
Sebelumnya, kami mulai berbicara tentang aplikasi untuk toko online. Dalam pendekatan tradisional, logika utama sistem dilakukan oleh aplikasi monolitik. Dan server dengan aplikasi terus berjalan, bahkan jika tidak ada beban.
Untuk beralih ke serverless, kami memecah aplikasi menjadi mikrotasks. Di bawah masing-masing dari mereka kita menulis fungsi kita sendiri. Fungsi independen satu sama lain dan tidak menyimpan informasi negara. Mereka bahkan dapat ditulis dalam berbagai bahasa. Jika salah satunya macet, seluruh aplikasi tidak akan berhenti. Arsitektur aplikasi akan terlihat seperti ini:
Pembagian fungsi di Serverless mirip dengan bekerja dengan layanan microser. Tetapi sebuah layanan mikro dapat melakukan beberapa tugas, dan idealnya, suatu fungsi harus melakukan satu. Bayangkan bahwa tugasnya adalah untuk mengumpulkan statistik dan ditampilkan atas permintaan pengguna. Dalam pendekatan microservice, tugas dilakukan oleh satu layanan dengan dua titik masuk: menulis dan membaca. Dalam komputasi tanpa server, ini akan menjadi dua fungsi berbeda yang tidak saling berhubungan. Pengembang menyimpan sumber daya komputasi jika, misalnya, statistik diperbarui lebih sering daripada yang diunduh.
Fungsi tanpa server harus dijalankan dalam waktu singkat (batas waktu), yang ditentukan oleh penyedia layanan. Misalnya, untuk AWS, batas waktu adalah 15 menit. Ini berarti bahwa fungsi yang berumur panjang (berumur panjang) harus diubah untuk memenuhi persyaratan - Serverless ini berbeda dari teknologi lain yang populer saat ini (wadah dan Platform sebagai Layanan).
Kami menetapkan suatu acara untuk setiap fungsi. Suatu peristiwa adalah pemicu suatu tindakan:
Acara dapat berupa permintaan HTTP, streaming data, antrian pesan, dan sebagainya. Sumber peristiwa adalah perubahan atau tampilan data. Selain itu, fungsi dapat dijalankan oleh timer.
Arsitekturnya berfungsi, dan aplikasi hampir menjadi serverless. Selanjutnya kita pergi ke penyedia layanan.
Dari provider
Komputasi tanpa server biasanya ditawarkan oleh penyedia layanan cloud. Mereka menyebutnya secara berbeda: Fungsi Azure, AWS Lambda, Fungsi Google Cloud, Fungsi IBM Cloud.
Kami akan menggunakan layanan melalui konsol atau akun pribadi penyedia. Kode fungsi dapat diunduh dengan salah satu cara berikut:
- tulis kode dalam editor bawaan melalui konsol web,
- Unduh arsip dengan kodenya,
- bekerja dengan repositori git publik atau pribadi.
Di sini kita mengkonfigurasi peristiwa yang memanggil fungsi. Penyedia yang berbeda mungkin memiliki rangkaian acara yang berbeda.
Penyedia infrastrukturnya telah membangun dan mengotomatiskan sistem Function as a Service (FaaS):
- Kode fungsi sampai ke repositori di sisi penyedia.
- Ketika suatu peristiwa terjadi, wadah dengan lingkungan yang disiapkan secara otomatis dikerahkan ke server. Setiap instance fungsi memiliki wadah tersendiri.
- Dari penyimpanan, fungsi dikirim ke wadah, dihitung, mengembalikan hasilnya.
- Jumlah peristiwa paralel meningkat - jumlah kontainer bertambah. Sistem secara otomatis berskala. Jika pengguna tidak mengakses fungsi, itu akan menjadi tidak aktif.
- Penyedia mengatur waktu idle wadah - jika selama ini fungsi tidak muncul dalam wadah, itu dihancurkan.
Jadi kita mendapatkan Serverless di luar kotak. Kami akan membayar layanan sesuai dengan model pay-as-you-go dan hanya untuk fungsi-fungsi yang digunakan, dan hanya untuk saat mereka digunakan.
Untuk memperkenalkan pengembang ke layanan, penyedia menawarkan hingga 12 bulan pengujian gratis, tetapi mereka membatasi waktu komputasi total, jumlah permintaan per bulan, uang atau konsumsi daya.
Keuntungan utama bekerja dengan penyedia adalah kemampuan untuk tidak khawatir tentang infrastruktur (server, mesin virtual, wadah). Untuk bagiannya, penyedia dapat menerapkan FaaS baik pada pengembangannya sendiri, dan menggunakan alat open-source. Kami akan membicarakannya lebih lanjut.
Dari sumber terbuka
Selama beberapa tahun terakhir, komunitas open-source telah secara aktif mengerjakan alat Serverless. Secara khusus, pemain pasar terbesar berkontribusi pada pengembangan platform tanpa server:
- Google menawarkan pengembangnya alat open-source - Knative . Pengembangannya melibatkan IBM, RedHat, Pivotal dan SAP;
- IBM bekerja pada platform OpenWhisk Serverless, yang kemudian menjadi proyek Apache Foundation;
- Microsoft membuka sebagian kode platform Azure Functions .
Pengembangan juga dilakukan ke arah kerangka serverless.
Kubeless dan
Fission dikerahkan dalam kluster Kubernet yang telah disiapkan sebelumnya,
OpenFaaS bekerja dengan Kubernetes dan Docker Swarm. Kerangka kerja bertindak sebagai semacam pengontrol - atas permintaan, ia menyiapkan runtime di dalam cluster, kemudian menjalankan fungsi di sana.
Kerangka kerja memberikan ruang untuk konfigurasi alat agar sesuai dengan kebutuhan Anda. Jadi, di Kubeless, pengembang dapat mengatur batas waktu untuk fungsi yang akan dieksekusi (nilai default adalah 180 detik). Fisi dalam upaya untuk memecahkan masalah penawaran mulai dingin agar bagian wadah tetap berjalan sepanjang waktu (meskipun ini memerlukan biaya waktu henti). Dan OpenFaaS menawarkan serangkaian pemicu untuk setiap rasa dan warna: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs dan lainnya.
Instruksi untuk memulai dapat ditemukan dalam dokumentasi resmi kerangka kerja. Bekerja dengan mereka menyiratkan sedikit lebih banyak keterampilan daripada bekerja dengan penyedia - ini setidaknya kemampuan untuk memulai cluster Kubernetes melalui CLI. Maksimum, termasuk alat sumber terbuka lainnya (misalnya, manajer antrian Kafka).
Terlepas dari bagaimana kami bekerja dengan Serverless - melalui penyedia atau menggunakan open-source, kami mendapatkan sejumlah keuntungan dan kerugian dari pendekatan Serverless.
Dari perspektif kelebihan dan kekurangan
Serverless mengembangkan ide-ide infrastruktur wadah dan pendekatan layanan mikro, di mana tim dapat bekerja dalam mode multibahasa, tanpa terikat pada satu platform. Membangun sistem disederhanakan, dan memperbaiki kesalahan menjadi lebih mudah. Arsitektur Microservice memungkinkan Anda untuk menambahkan fungsionalitas baru ke sistem jauh lebih cepat daripada dalam kasus aplikasi monolitik.
Tanpa server mengurangi waktu pengembangan lebih jauh dengan membiarkan pengembang hanya berfokus pada logika dan pengkodean aplikasi bisnis. Akibatnya, waktu ke pasar untuk pengembangan berkurang.
Sebagai bonus, kami mendapatkan penskalaan otomatis ke beban, dan kami hanya membayar sumber daya yang digunakan dan hanya pada saat mereka digunakan.
Seperti halnya teknologi apa pun, Serverless memiliki kelemahan.
Misalnya, kelemahan seperti itu bisa menjadi waktu mulai yang dingin (rata-rata hingga 1 detik untuk bahasa seperti JavaScript, Python, Go, Java, Ruby).Di satu sisi, pada kenyataannya, waktu mulai dingin tergantung pada banyak variabel: bahasa di mana fungsi ditulis, jumlah perpustakaan, jumlah kode, komunikasi dengan sumber daya tambahan (database yang sama atau server otentikasi). Karena pengembang mengontrol variabel-variabel ini, ia dapat mempersingkat waktu mulai. Tetapi di sisi lain, pengembang tidak dapat mengontrol waktu peluncuran wadah - semuanya tergantung pada penyedia.
Awal yang dingin dapat berubah menjadi hangat ketika fungsi menggunakan kembali wadah yang diluncurkan oleh acara sebelumnya. Situasi ini akan terjadi dalam tiga kasus:
- jika pelanggan sering menggunakan layanan ini dan jumlah panggilan ke fungsi bertambah;
- jika penyedia, platform atau kerangka kerja memungkinkan Anda untuk menjaga agar bagian dari wadah tetap berjalan sepanjang waktu;
- jika pengembang menjalankan fungsi timer (katakanlah, setiap 3 menit).
Untuk banyak aplikasi, awal yang dingin tidak menjadi masalah. Di sini Anda perlu membangun pada jenis dan tugas layanan. Awal yang tertunda selama sedetik tidak selalu penting untuk aplikasi bisnis, tetapi dapat menjadi penting untuk layanan medis. Mungkin, dalam hal ini, pendekatan tanpa server tidak lagi cocok.
Kelemahan berikutnya dari Serverless adalah masa pakai fungsi yang singkat (batas waktu untuk fungsi yang harus dijalankan).Tetapi, jika Anda harus bekerja dengan tugas yang berumur panjang, Anda dapat menggunakan arsitektur hybrid - menggabungkan Serverless dengan teknologi lainnya.
Tidak semua sistem akan dapat bekerja sesuai dengan skema Serverless.Beberapa aplikasi masih akan menyimpan data dan status saat runtime. Beberapa arsitektur akan tetap monolitik, dan beberapa fungsi akan berumur panjang. Namun (seperti teknologi cloud dulu, dan kemudian wadah), Serverless adalah teknologi dengan masa depan yang hebat.
Dalam nada ini, saya ingin beralih ke masalah penerapan pendekatan Serverless.
Di sisi aplikasi
Pada 2018, persentase penggunaan Tanpa Server
meningkat satu setengah kali . Di antara perusahaan yang telah menerapkan teknologi dalam layanan mereka, ada raksasa pasar seperti Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Pada saat yang sama, Anda perlu memahami bahwa Serverless bukanlah obat mujarab, tetapi alat untuk menyelesaikan berbagai tugas:
- Kurangi sumber daya waktu henti. Anda tidak perlu terus-menerus menjaga mesin virtual di bawah layanan yang tidak banyak diakses.
- "On the fly" memproses data. Kompres gambar, memotong latar belakang, mengubah pengkodean video, bekerja dengan sensor IoT, melakukan operasi matematika.
- Rekatkan layanan lain. Git repositori dengan program internal, chat bot di Slack with Jira dan dengan kalender.
- Seimbangkan beban. Di sini kita tinggal lebih detail.
Katakanlah ada layanan yang dihadiri 50 orang. Di bawahnya adalah mesin virtual dengan perangkat keras yang lemah. Secara berkala, beban pada layanan meningkat secara signifikan. Maka besi yang lemah tidak bisa mengatasinya.
Anda dapat memasukkan penyeimbang dalam sistem yang akan mendistribusikan beban, katakanlah, ke tiga mesin virtual. Pada tahap ini, kami tidak dapat secara akurat memprediksi beban, jadi kami menjaga sejumlah sumber daya berjalan “dalam cadangan”. Dan membayar lebih untuk downtime.
Dalam situasi ini, kita dapat mengoptimalkan sistem melalui pendekatan hybrid: untuk penyeimbang beban kita meninggalkan satu mesin virtual dan menempatkan tautan ke Serverless Endpoint dengan fungsi. Jika beban melebihi ambang batas, penyeimbang meluncurkan contoh fungsi yang mengambil bagian dari pemrosesan permintaan.
Dengan demikian, Serverless dapat digunakan di tempat yang tidak terlalu sering, tetapi untuk memproses sejumlah besar permintaan secara intensif. Dalam hal ini, menjalankan beberapa fungsi selama 15 menit lebih menguntungkan daripada memegang mesin atau server virtual sepanjang waktu.
Dengan semua keunggulan komputasi tanpa server, sebelum menerapkannya, Anda harus terlebih dahulu mengevaluasi logika aplikasi dan memahami tugas-tugas yang dapat diselesaikan Serverless dalam kasus tertentu.
Tanpa Server dan Selectel
Di Selectel, kami telah
membuat bekerja dengan Kubernetes di
cloud pribadi virtual lebih mudah melalui panel kontrol kami. Sekarang kami sedang membangun platform FaaS kami sendiri. Kami ingin pengembang dapat menyelesaikan masalah mereka dengan Serverless melalui antarmuka yang nyaman dan fleksibel.
Ingin mengikuti proses pengembangan platform FaaS baru? Berlangganan buletin Selectel “Cloud Functions”
di halaman layanan . Kami akan berbicara tentang proses pengembangan dan mengumumkan rilis Cloud Functions.
Jika Anda memiliki ide apa platform FaaS ideal seharusnya dan bagaimana Anda ingin menggunakan Serverless dalam proyek Anda, bagikan dalam komentar. Kami akan mempertimbangkan keinginan Anda saat mengembangkan platform.
Bahan yang digunakan dalam artikel: