Meskipun teknologi tanpa server dengan cepat mendapatkan popularitas dalam beberapa tahun terakhir, masih banyak kesalahpahaman dan ketakutan yang terkait dengannya. Ketergantungan vendor, perkakas, manajemen biaya, cold start, pemantauan, dan siklus hidup pengembangan adalah topik hangat terkait teknologi tanpa server. Dalam artikel ini, kami akan menjelajahi beberapa topik yang disebutkan, serta berbagi kiat dan tautan ke sumber informasi bermanfaat untuk membantu pemula membuat aplikasi tanpa server yang andal, fleksibel, dan hemat biaya.
Kesalahpahaman Tentang Teknologi Tanpa Server
Banyak orang berpikir bahwa pemrosesan tanpa server dan tanpa server (, FaaS) adalah hal yang hampir sama. Artinya perbedaannya tidak terlalu besar dan ada baiknya memperkenalkan sesuatu yang baru. Meskipun AWS Lambda adalah salah satu bintang masa kejayaan tanpa server dan salah satu elemen paling populer dari arsitektur tanpa server, arsitektur ini jauh lebih dari FaaS.
Prinsip dasar di balik teknologi tanpa server adalah Anda tidak perlu khawatir tentang pengelolaan dan penskalaan infrastruktur, Anda hanya membayar apa yang Anda gunakan. Banyak layanan yang memenuhi kriteria ini - AWS DynamoDB, S3, SNS atau SQS, Graphcool, Auth0, Now, Netlify, Firebase, dan banyak lainnya. Secara umum, tanpa server berarti menggunakan kekuatan penuh komputasi awan tanpa perlu mengelola infrastruktur dan mengoptimalkannya untuk penskalaan. Ini juga berarti bahwa keamanan di tingkat infrastruktur tidak lagi menjadi perhatian Anda, yang merupakan keuntungan besar mengingat sulitnya dan rumitnya memenuhi standar keamanan. Terakhir, Anda tidak perlu membeli infrastruktur yang disediakan untuk Anda.
Tanpa server dapat dianggap sebagai "keadaan pikiran": mentalitas tertentu saat merancang solusi. Hindari pendekatan yang memerlukan pemeliharaan infrastruktur apa pun. Dengan pendekatan tanpa server, kami menghabiskan waktu untuk menyelesaikan tugas yang secara langsung memengaruhi proyek dan membawa manfaat bagi pengguna kami: kami membuat logika bisnis yang berkelanjutan, mengembangkan antarmuka pengguna, dan mengembangkan API yang adaptif dan andal.
Misalnya, jika memungkinkan untuk menghindari pengelolaan dan pemeliharaan platform pencarian teks gratis, maka itulah yang akan kami lakukan. Pendekatan untuk membangun aplikasi ini dapat sangat mempercepat waktu pemasaran, karena Anda tidak perlu lagi memikirkan pengelolaan infrastruktur yang rumit. Hilangkan tanggung jawab dan biaya manajemen infrastruktur dan fokuslah untuk membangun aplikasi dan layanan yang dibutuhkan pelanggan Anda. Patrick Debois menyebut pendekatan ini , istilah ini diadopsi dalam komunitas tanpa server. Fungsi harus dianggap sebagai tautan ke layanan sebagai modul yang dapat diterapkan (alih-alih menerapkan seluruh pustaka atau aplikasi web). Ini memberikan perincian yang luar biasa untuk mengelola penerapan dan perubahan pada aplikasi. Jika Anda tidak dapat menerapkan fungsi dengan cara ini, ini mungkin mengindikasikan bahwa fungsi melakukan terlalu banyak tugas dan perlu difaktorkan ulang.
Beberapa bingung dengan ketergantungan pada vendor saat mengembangkan aplikasi cloud. Hal yang sama berlaku untuk teknologi tanpa server, dan ini bukanlah kesalahpahaman. Dalam pengalaman kami, membuat aplikasi tanpa server di AWS, dikombinasikan dengan kemampuan AWS Lambda untuk menyatukan layanan AWS lainnya, adalah bagian dari kekuatan arsitektur tanpa server. Ini adalah contoh sinergi yang baik, ketika hasil kombinasi lebih dari sekadar jumlah istilah. Mencoba menghindari ketergantungan vendor dapat menimbulkan lebih banyak masalah. Saat bekerja dengan kontainer, akan lebih mudah mengelola lapisan abstraksi Anda sendiri di antara penyedia cloud. Namun jika menyangkut solusi tanpa server, upaya tersebut tidak akan membuahkan hasil, terutama jika efektivitas biaya diperhitungkan sejak awal. Pastikan untuk mencari tahu bagaimana vendor menyediakan layanan. Beberapa layanan khusus bergantung pada titik integrasi dengan vendor lain dan dapat menyediakan konektivitas plug-and-play di luar kotak. Lebih mudah memberikan panggilan Lambda dari titik akhir API gateway daripada mem-proxy permintaan ke beberapa wadah atau instans EC2. Graphcool menyediakan konfigurasi yang mudah dengan Auth0, yang lebih mudah daripada menggunakan alat autentikasi pihak ketiga.
Memilih vendor yang tepat untuk aplikasi tanpa server Anda merupakan keputusan arsitektural. Saat Anda membuat aplikasi, Anda tidak berharap suatu hari nanti akan kembali mengelola server. Memilih vendor cloud tidak berbeda dengan memilih menggunakan container atau database, atau bahkan bahasa pemrograman.
Mempertimbangkan:
- Layanan apa yang Anda butuhkan dan mengapa.
- Layanan apa yang disediakan penyedia cloud dan bagaimana Anda dapat menggabungkannya dengan solusi FaaS pilihan Anda.
- Bahasa pemrograman apa yang didukung (dengan pengetikan dinamis atau statis, dikompilasi atau diinterpretasikan, apa tolok ukurnya, bagaimana kinerja pada start dingin, apa ekosistem open source, dll.).
- Apa persyaratan keamanan Anda (SLA, 2FA, OAuth, HTTPS, SSL, dll.).
- Bagaimana mengelola CI/CD dan siklus pengembangan perangkat lunak Anda.
- Solusi infrastruktur-sebagai-kode mana yang dapat Anda manfaatkan.
Jika Anda memperluas aplikasi yang sudah ada dan menambahkan fungsionalitas tanpa server secara bertahap, ini mungkin membatasi kemampuan yang tersedia. Namun, hampir semua teknologi tanpa server menyediakan semacam API (melalui REST atau antrean pesan) yang memungkinkan Anda membuat ekstensi yang tidak bergantung pada inti aplikasi dan dengan integrasi yang mudah. Carilah layanan dengan API yang jelas, dokumentasi yang bagus, dan komunitas yang kuat, dan Anda tidak akan salah. Kemudahan integrasi seringkali dapat menjadi metrik kunci, dan mungkin salah satu alasan utama mengapa AWS begitu sukses sejak Lambda dirilis pada tahun 2015.
Ketika Tanpa Server Baik
Teknologi tanpa server dapat diterapkan hampir di semua tempat. Namun, kelebihannya tidak terbatas hanya pada satu cara aplikasi. Hambatan masuk untuk komputasi awan saat ini sangat rendah berkat teknologi tanpa server. Jika pengembang memiliki ide, tetapi mereka tidak tahu cara mengelola infrastruktur cloud dan mengoptimalkan biaya, mereka tidak perlu mencari insinyur untuk melakukannya. Jika sebuah startup ingin membangun platform tetapi khawatir biayanya mungkin tidak terkendali, mereka dapat dengan mudah beralih ke solusi tanpa server.
Karena penghematan biaya dan kemudahan penskalaan, solusi tanpa server sama-sama berlaku untuk sistem internal dan eksternal, hingga aplikasi web dengan jutaan audiens. Akun diukur bukan dalam euro, tetapi dalam sen. Menyewa instance paling sederhana dari AWS EC2 (t1.micro) selama sebulan akan dikenakan biaya β¬15, bahkan jika Anda tidak melakukan apa pun dengannya (siapa yang tidak pernah lupa mematikannya?!). Sebagai perbandingan, untuk mencapai tingkat pengeluaran ini selama periode waktu yang sama, Anda perlu menjalankan Lambda 512 MB selama 1 detik sekitar 3 juta kali. Dan jika Anda tidak menggunakan fitur ini, maka Anda tidak membayar apapun.
Karena tanpa server terutama digerakkan oleh peristiwa, cukup mudah untuk menambahkan infrastruktur tanpa server ke sistem yang lebih lama. Misalnya, dengan menggunakan AWS S3, Lambda, dan Kinesis, Anda dapat membuat layanan analitik untuk sistem retail lama yang dapat menerima data melalui API.
Sebagian besar platform tanpa server mendukung banyak bahasa. Paling sering itu adalah Python, JavaScript, C#, Java dan Go. Biasanya tidak ada batasan penggunaan pustaka dalam semua bahasa, sehingga Anda dapat menggunakan pustaka sumber terbuka favorit Anda. Namun, disarankan untuk tidak menyalahgunakan dependensi agar fungsi Anda bekerja secara optimal dan tidak meniadakan manfaat dari skalabilitas besar aplikasi tanpa server Anda. Semakin banyak paket yang perlu dimuat ke dalam wadah, semakin lama waktu start dingin.
Cold start adalah saat pertama kali Anda harus menginisialisasi container, runtime, dan error handler sebelum menggunakannya. Karena itu, penundaan eksekusi fungsi bisa sampai 3 detik, dan ini bukan pilihan terbaik bagi pengguna yang tidak sabar. Namun, cold start terjadi pada panggilan pertama setelah beberapa menit fungsi diam. Begitu banyak yang menganggap ini sebagai gangguan kecil yang dapat diatasi dengan melakukan ping secara teratur ke fungsi agar tetap diam. Atau mereka mengabaikan aspek ini sama sekali.
Meskipun AWS dirilisNamun, database SQL tidak ideal untuk aplikasi ini, karena database tersebut bergantung pada koneksi untuk melakukan transaksi, yang dapat dengan cepat menjadi hambatan dengan lalu lintas padat di AWS Lambda. Ya, pengembang terus meningkatkan Aurora Tanpa Server, dan Anda harus bereksperimen dengannya, tetapi hari ini solusi NoSQL seperti. Namun, tidak ada keraguan bahwa situasi ini akan segera berubah.
Toolkit ini juga memberlakukan banyak batasan, terutama di bidang pengujian lokal. Meskipun ada solusi seperti Docker-Lambda, DynamoDB Local, dan LocalStack, mereka membutuhkan kerja keras dan konfigurasi yang signifikan. Namun, semua proyek ini dikembangkan secara aktif, jadi hanya masalah waktu sebelum toolkit mencapai level yang kita butuhkan.
Dampak teknologi tanpa server pada siklus pengembangan
Karena infrastruktur Anda hanyalah sebuah konfigurasi, Anda dapat menentukan dan menerapkan kode menggunakan skrip, seperti skrip shell. Atau Anda dapat menggunakan solusi kelas konfigurasi sebagai kode seperti . Meskipun layanan ini tidak menyediakan konfigurasi untuk semua area, layanan ini memungkinkan Anda menentukan sumber daya khusus untuk digunakan sebagai fungsi Lambda. Artinya, jika CloudFormation mengecewakan Anda, Anda dapat menulis sumber daya Anda sendiri (fungsi Lambda) yang akan menutup celah ini. Dengan cara ini Anda dapat melakukan apa saja, bahkan mengonfigurasi dependensi di luar lingkungan AWS Anda.
Karena ini semua hanyalah konfigurasi, Anda dapat menyesuaikan skrip penerapan untuk lingkungan, wilayah, dan pengguna tertentu, terutama jika Anda menggunakan solusi infrastruktur sebagai kode seperti CloudFormation. Misalnya, Anda dapat menerapkan salinan infrastruktur untuk setiap cabang di repositori sehingga Anda dapat mengujinya sepenuhnya secara terpisah selama pengembangan. Ini secara drastis mempercepat umpan balik untuk pengembang ketika mereka ingin memahami apakah kode mereka berfungsi dengan baik di lingkungan langsung. Manajer tidak perlu khawatir tentang biaya penerapan beberapa lingkungan, karena mereka hanya membayar penggunaan yang sebenarnya.
DevOps memiliki lebih sedikit kekhawatiran karena mereka hanya perlu memastikan pengembang memiliki konfigurasi yang benar. Anda tidak perlu lagi mengelola instans, penyeimbang, atau grup keamanan. Oleh karena itu, istilah NoOps semakin banyak digunakan, meskipun tetap penting untuk dapat mengonfigurasi infrastruktur, terutama terkait dengan konfigurasi IAM dan pengoptimalan sumber daya cloud.
Ada alat pemantauan dan visualisasi yang sangat kuat seperti Epsagon, Thundra, Dashbird, dan IOPipe. Mereka memungkinkan Anda untuk memantau status aplikasi tanpa server Anda saat ini, menyediakan logging dan pelacakan, menangkap metrik kinerja dan bottleneck arsitektur, melakukan analisis dan perkiraan biaya, dan banyak lagi. Mereka tidak hanya memberi para insinyur, pengembang, dan arsitek DevOps pandangan komprehensif tentang kinerja aplikasi, tetapi juga memungkinkan manajer untuk memantau situasi secara real time, dengan biaya sumber daya per detik dan perkiraan biaya. Jauh lebih sulit untuk mengatur ini dengan infrastruktur yang dikelola.
Mendesain aplikasi tanpa server jauh lebih mudah karena Anda tidak perlu menerapkan server web, mengelola mesin atau kontainer virtual, server patch, sistem operasi, gateway internet, dll. Dengan mengabaikan semua tanggung jawab ini, arsitektur tanpa server dapat berfokus pada inti - solusi kebutuhan bisnis dan pelanggan.
Sementara toolkit bisa menjadi lebih baik (menjadi lebih baik setiap hari), pengembang dapat fokus pada penerapan logika bisnis dan mendistribusikan kompleksitas aplikasi dengan baik di berbagai layanan dalam arsitektur. Manajemen aplikasi tanpa server berbasis peristiwa dan diabstraksikan oleh penyedia cloud (misalnya peristiwa SQS, S3, atau aliran DynamoDB). Oleh karena itu, pengembang hanya perlu menulis logika bisnis untuk merespons kejadian tertentu, dan tidak perlu khawatir tentang cara terbaik untuk mengimplementasikan database dan antrean pesan, atau cara mengatur pekerjaan optimal dengan data di penyimpanan perangkat keras tertentu.
Kode dapat dijalankan dan di-debug secara lokal, seperti halnya proses pengembangan apa pun. Pengujian unit tetap sama. Kemampuan untuk menerapkan seluruh infrastruktur aplikasi dengan konfigurasi tumpukan kustom memungkinkan pengembang mendapatkan umpan balik penting dengan cepat tanpa memikirkan biaya pengujian atau dampaknya pada lingkungan terkelola yang mahal.
Alat dan teknik untuk membuat aplikasi tanpa server
Tidak ada cara khusus untuk membangun aplikasi tanpa server. Serta satu set layanan untuk tugas ini. AWS adalah pemimpin di antara solusi tanpa server yang andal saat ini, tetapi lihat juga , ΠΈ . Jika Anda menggunakan AWS, pendekatan yang disarankan untuk mengumpulkan aplikasi adalah (SAM), terutama saat menggunakan C#, karena Visual Studio memiliki tool yang bagus. SAM CLI dapat melakukan semua hal yang dapat dilakukan Visual Studio, jadi Anda tidak akan kehilangan apa pun jika beralih ke IDE atau editor teks lain. Tentu saja, SAM juga bekerja dengan bahasa lain.
Jika Anda menulis dalam bahasa lain, Serverless Framework adalah alat sumber terbuka luar biasa yang memungkinkan Anda mengonfigurasi apa pun dengan file konfigurasi YAML yang sangat andal. Framework Tanpa Server juga mendukung berbagai layanan cloud, jadi kami merekomendasikannya kepada mereka yang mencari solusi multi-cloud. Ini memiliki komunitas besar yang telah membuat banyak plugin untuk kebutuhan apa pun.
Untuk pengujian lokal, alat open source Docker-Lambda, Serverless Local, DynamoDB Local, dan LocalStack sangat cocok. Teknologi tanpa server masih dalam tahap awal pengembangannya, begitu pula alat untuknya, jadi saat menyiapkan skenario pengujian yang rumit, Anda harus bekerja keras. Namun, hanya menyebarkan tumpukan di lingkungan dan mengujinya sangat murah. Dan Anda tidak perlu membuat salinan lingkungan cloud lokal yang persis sama.
Gunakan AWS Lambda Layers untuk mengurangi ukuran paket yang diterapkan dan mempercepat unduhan.
Gunakan bahasa pemrograman yang tepat untuk tugas tertentu. Bahasa yang berbeda memiliki kelebihan dan kekurangannya masing-masing. Ada banyak tolok ukur, tetapi JavaScript, Python, dan C# (.NET Core 2.1+) adalah pemimpin dalam hal kinerja AWS Lambda. AWS Lambda baru-baru ini memperkenalkan Runtime API, yang memungkinkan Anda menentukan bahasa dan lingkungan runtime yang Anda inginkan, jadi bereksperimenlah.
Pertahankan ukuran paket tetap kecil untuk penerapan. Semakin kecil mereka, semakin cepat mereka memuat. Hindari menggunakan perpustakaan besar, terutama jika Anda menggunakan beberapa fitur darinya. Jika Anda memprogram dalam JavaScript, gunakan alat build seperti Webpack untuk mengoptimalkan build Anda dan hanya menyertakan yang benar-benar Anda butuhkan. .NET Core 3.0 memiliki QuickJit dan Kompilasi Berjenjang yang meningkatkan kinerja dan banyak membantu saat mulai dingin.
Ketergantungan fungsi tanpa server pada acara dapat mempersulit koordinasi logika bisnis pada awalnya. Dalam hal ini, antrean pesan dan mesin negara bisa sangat berguna. Fungsi Lambda dapat memanggil satu sama lain, tetapi hanya lakukan ini jika Anda tidak mengharapkan respons ("aktifkan dan lupakan") - Anda tidak ingin ditagih karena menunggu fungsi lain selesai. Antrean pesan berguna untuk mengisolasi bagian logika bisnis, mengelola kemacetan aplikasi, dan memproses transaksi (menggunakan antrean FIFO). Fungsi AWS Lambda dapat ditetapkan ke antrean SQS sebagai antrean pesan macet yang melacak pesan gagal untuk analisis nanti. AWS Step Functions (mesin negara) sangat berguna untuk mengelola proses kompleks yang memerlukan rangkaian fungsi. Alih-alih fungsi Lambda memanggil fungsi lain, fungsi langkah dapat mengoordinasikan transisi status, meneruskan data antar fungsi, dan mengelola status fungsi global. Hal ini memungkinkan Anda untuk menentukan kondisi coba lagi, atau apa yang harus dilakukan saat terjadi kesalahan tertentu - alat yang sangat ampuh dalam kondisi tertentu.
Kesimpulan
Dalam beberapa tahun terakhir, teknologi tanpa server telah berkembang dengan kecepatan yang belum pernah terjadi sebelumnya. Ada kesalahpahaman tertentu yang terkait dengan pergeseran paradigma ini. Dengan mengabstraksi infrastruktur dan manajemen penskalaan, solusi tanpa server menawarkan manfaat yang signifikan, mulai dari proses pengembangan dan DevOps yang disederhanakan hingga pengurangan besar-besaran dalam biaya operasional.
Meskipun pendekatan tanpa server bukannya tanpa kelemahan, ada pola desain yang kuat yang dapat digunakan untuk membangun aplikasi tanpa server yang tangguh atau mengintegrasikan elemen tanpa server ke dalam arsitektur yang sudah ada.
Sumber: www.habr.com