Get best of the week

Kiat dan sumber untuk membuat aplikasi tanpa server


Meskipun teknologi tanpa server dengan cepat mendapatkan popularitas dalam beberapa tahun terakhir, masih ada banyak kesalahpahaman dan kekhawatiran yang terkait dengannya. Ketergantungan vendor, alat, manajemen biaya, mulai dingin, pemantauan, dan siklus hidup pengembangan - semua topik ini dibahas secara aktif ketika datang ke teknologi tanpa server. Dalam artikel ini, kita akan melihat beberapa topik yang disebutkan, dan juga berbagi tips dan tautan ke sumber informasi yang berguna, dengan bantuan yang pemula dapat membuat aplikasi serverless yang kuat, fleksibel dan ekonomis.

Kesalahpahaman tentang Teknologi Tanpa Server


Banyak yang percaya bahwa serverlessness dan pemrosesan data non-server ( Fungsi sebagai Layanan , FaaS) adalah hal yang hampir sama. Jadi, perbedaannya tidak terlalu besar dan ada baiknya memperkenalkan produk baru. Meskipun AWS Lambda adalah salah satu bintang di masa kejayaan teknologi tanpa server dan salah satu elemen paling populer dari arsitektur serverless, arsitektur ini lebih dari FaaS.

Prinsip dasar dari teknologi tanpa server adalah bahwa Anda tidak perlu khawatir tentang mengelola dan meningkatkan skala infrastruktur, Anda hanya membayar untuk apa yang Anda gunakan. Banyak layanan yang cocok untuk kriteria ini - AWS DynamoDB, S3, SNS atau SQS, Graphcool, Auth0, Sekarang, Netlify, Firebase dan banyak lainnya. Secara umum, serverlessness berarti menggunakan semua kemampuan komputasi awan tanpa perlu mengelola infrastruktur dan pengoptimalannya untuk penskalaan. Ini juga berarti bahwa keamanan tingkat infrastruktur bukan lagi masalah Anda, tetapi keuntungan besar, mengingat kesulitan dan kerumitan mematuhi standar keamanan. Akhirnya, Anda tidak perlu membeli infrastruktur yang disediakan untuk digunakan.

Serverlessness dapat dianggap sebagai "keadaan pikiran": mentalitas tertentu dalam desain solusi. Hindari pendekatan yang membutuhkan pemeliharaan infrastruktur apa pun. Dengan pendekatan tanpa server, kami menghabiskan waktu memecahkan masalah yang secara langsung mempengaruhi proyek dan membawa manfaat bagi pengguna kami: kami menciptakan logika bisnis yang berkelanjutan, mengembangkan antarmuka pengguna dan mengembangkan API yang adaptif dan andal.

Misalnya, jika Anda dapat menghindari mengelola dan memelihara platform pencarian teks gratis, maka itulah yang akan kami lakukan. Pendekatan untuk membangun aplikasi ini dapat sangat mempercepat peluncuran produk di pasar, karena Anda tidak perlu lagi berpikir tentang mengelola infrastruktur yang kompleks. Singkirkan tanggung jawab dan biaya pengelolaan infrastruktur Anda dan fokuskan untuk menciptakan aplikasi dan layanan yang dibutuhkan pelanggan Anda. Patrick Debois menyebut pendekatan ini 'layanan', istilah ini diadopsi di komunitas tanpa server. Fungsi harus dianggap sebagai tautan penghubung untuk layanan dalam bentuk modul yang dapat digunakan (alih-alih menggunakan seluruh perpustakaan atau aplikasi web). Ini memberikan rincian yang luar biasa dalam pengelolaan penyebaran dan perubahan dalam aplikasi. Jika Anda tidak dapat menggunakan fungsi dengan cara ini, maka ini mungkin menunjukkan bahwa fungsi melakukan terlalu banyak tugas dan harus di refactored.

Ada yang bingung dengan ketergantungan vendor dalam pengembangan aplikasi cloud. Hal yang sama dengan teknologi tanpa server, dan ini hampir tidak merupakan konsekuensi dari kebingungan. Dalam pengalaman kami, membuat aplikasi tanpa server pada AWS dikombinasikan dengan kemampuan AWS Lambda untuk mengintegrasikan layanan AWS lainnya - semua ini sebagian membentuk keunggulan arsitektur tanpa server. Ini adalah contoh sinergi yang baik ketika hasil penggabungan lebih dari sekadar jumlah istilah. Mencoba menghindari ketergantungan vendor, Anda mungkin mengalami masalah yang lebih besar. Saat bekerja dengan kontainer, lebih mudah untuk mengelola tingkat abstraksi Anda sendiri antara penyedia cloud. Tetapi ketika datang ke solusi tanpa server, upaya tidak akan membuahkan hasil, terutama jika efisiensi ekonomi diperhitungkan sejak awal. Pastikan untuk mengetahui bagaimana vendor memberikan layanan.Beberapa layanan khusus bergantung pada titik integrasi dengan vendor lain, dan di luar kotak mereka dapat menyediakan konektivitas plug-and-play. Lebih mudah untuk memberikan panggilan Lambda dari titik akhir API gateway daripada untuk mem-proxy permintaan ke beberapa wadah atau contoh EC2. Graphcool menyediakan konfigurasi yang mudah dengan Auth0, yang lebih mudah daripada menggunakan otentikasi pihak ketiga.

Memilih vendor yang tepat untuk aplikasi tanpa server Anda adalah solusi tingkat arsitektur. Ketika Anda membuat aplikasi, Anda tidak berharap bahwa suatu hari Anda akan kembali ke manajemen server. Memilih vendor cloud tidak berbeda dengan memilih untuk menggunakan wadah atau database, atau bahkan bahasa pemrograman.

Mempertimbangkan:

  • Layanan apa yang Anda butuhkan dan mengapa.
  • Layanan apa yang disediakan oleh penyedia cloud dan bagaimana Anda dapat menggabungkannya menggunakan solusi FaaS yang dipilih.
  • Apa bahasa pemrograman yang didukung (dengan pengetikan dinamis atau statis, dikompilasi atau ditafsirkan, tolok ukur apa yang ada, apa kinerja pada awal yang dingin, apa itu ekosistem sumber terbuka, dll.).
  • Apa persyaratan keamanan Anda (SLA, 2FA, OAuth, HTTPS, SSL, dll.).
  • Cara mengelola siklus pengembangan CI / CD dan perangkat lunak Anda.
  • Solusi kelas infrastruktur-sebagai-kode apa yang dapat Anda manfaatkan?

Jika Anda memperluas aplikasi yang ada dan menambahkan fungsi tanpa server secara bertahap, ini mungkin agak membatasi opsi yang tersedia. Namun, hampir semua teknologi tanpa server menyediakan beberapa jenis API (melalui REST atau antrian pesan) yang memungkinkan Anda membuat ekstensi terlepas dari kernel aplikasi dan dengan integrasi sederhana. Cari layanan dengan API yang jelas, dokumentasi yang baik, dan komunitas yang kuat, dan Anda tidak akan salah. Kemudahan integrasi seringkali dapat menjadi metrik kunci, dan ini mungkin salah satu alasan utama untuk keberhasilan AWS sejak rilis Lambda pada tahun 2015.

Ketika serverlessness bermanfaat


Teknologi tanpa server dapat diterapkan hampir di semua tempat. Namun, keunggulan mereka tidak terbatas hanya pada satu aplikasi. Ambang entri cloud sangat rendah hari ini berkat teknologi tanpa server. Jika pengembang memiliki ide, tetapi mereka tidak tahu bagaimana mengelola infrastruktur cloud dan mengoptimalkan biaya, maka mereka tidak perlu mencari semacam insinyur untuk ini. Jika startup ingin membuat platform, tetapi khawatir biaya mungkin tidak terkendali, ia 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 pemirsa. Akun diukur bukan dalam euro, tetapi dalam sen. Menyewa contoh paling sederhana dari AWS EC2 (t1.micro) selama satu bulan akan dikenakan biaya € 15, bahkan jika Anda tidak melakukan apa pun dengannya (siapa yang tidak pernah lupa mematikannya?!). Sebagai perbandingan, untuk mencapai tingkat pengeluaran yang sudah seperti itu selama periode waktu yang sama, Anda harus menjalankan ukuran Lambda 512 MB selama 1 detik sekitar 3 juta kali. Dan jika Anda tidak menggunakan fungsi ini, maka tidak membayar apa pun.

Karena teknologi tanpa server terutama bergantung pada peristiwa, cukup mudah untuk menambahkan infrastruktur tanpa server ke sistem yang lebih lama. Misalnya, menggunakan AWS S3, Lambda dan Kinesis, Anda dapat membuat layanan analitik untuk sistem ritel lama yang dapat menerima data melalui API.

Sebagian besar platform tanpa server mendukung berbagai bahasa. Paling sering ini adalah Python, JavaScript, C #, Java dan Go. Biasanya dalam semua bahasa tidak ada batasan pada penggunaan perpustakaan, sehingga Anda dapat menggunakan perpustakaan open source favorit Anda. Namun, disarankan untuk tidak menyalahgunakan dependensi sehingga fungsi Anda bekerja secara optimal dan tidak meniadakan manfaat skalabilitas yang sangat besar dari aplikasi serverless Anda. Semakin banyak paket yang perlu Anda muat ke dalam wadah, semakin lama waktu mulai yang dingin.

Awal yang dingin adalah ketika pertama kali Anda perlu menginisialisasi wadah, runtime, dan penangan kesalahan sebelum menggunakannya. Karena itu, penundaan dalam pelaksanaan fungsi dapat mencapai 3 detik, dan ini bukan pilihan terbaik bagi pengguna yang tidak sabar. Namun, mulai dingin terjadi pada penggunaan pertama setelah beberapa menit downtime. Begitu banyak orang menganggap ini ketidaknyamanan kecil yang dapat dielakkan dengan secara teratur melakukan ping fungsi agar tetap idle. Atau bahkan mengabaikan aspek ini.

Meskipun AWS telah merilis Database Serverless Aurora Serverless SQLNamun, database SQL tidak ideal untuk aplikasi seperti itu, karena ketika melakukan transaksi, mereka bergantung pada koneksi, yang dapat dengan cepat menjadi hambatan dengan banyak lalu lintas di AWS Lambda. Ya, pengembang terus meningkatkan Serverless Aurora, dan Anda harus mencobanya, tetapi hari ini solusi NoSQL seperti DynamoDB jauh lebih baik untuk sistem tanpa server . Namun, tidak diragukan bahwa situasi ini akan segera berubah.

Toolkit ini juga memberlakukan banyak pembatasan, terutama di bidang pengujian lokal. Meskipun ada solusi seperti Docker-Lambda, DynamoDB Local dan LocalStack, namun, mereka membutuhkan kerja keras dan sejumlah besar konfigurasi. Namun, semua proyek ini sedang aktif dikembangkan, jadi tinggal menunggu waktu sebelum alat mencapai tingkat yang kita butuhkan.

Dampak teknologi tanpa server pada siklus pengembangan


Karena infrastruktur Anda hanyalah konfigurasi, Anda dapat menentukan dan menggunakan kode menggunakan skrip, seperti skrip shell. Atau Anda dapat menggunakan solusi kelas konfigurasi-sebagai-kode seperti AWS CloudFormation . Meskipun layanan ini tidak menyediakan konfigurasi untuk semua area, layanan ini memungkinkan Anda untuk menentukan sumber daya spesifik untuk digunakan sebagai fungsi Lambda. Yaitu, ketika 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 mengkonfigurasi dependensi di luar lingkungan AWS Anda.

Karena semua ini hanya konfigurasi, Anda dapat membuat parameter skrip penerapan untuk lingkungan, wilayah, dan pengguna tertentu, terutama jika Anda menggunakan solusi kelas infrastruktur-sebagai-kode seperti CloudFormation. Misalnya, Anda dapat menggunakan salinan infrastruktur untuk setiap cabang di repositori untuk mengujinya sepenuhnya dalam isolasi selama pengembangan. Ini secara drastis mempercepat pengembang mendapatkan umpan balik ketika mereka ingin memahami apakah kode mereka berfungsi dengan baik di lingkungan langsung. Manajer tidak perlu khawatir tentang biaya penempatan berbagai lingkungan, karena hanya penggunaan aktual yang dibayar.

DevOps memiliki lebih sedikit kekhawatiran karena mereka hanya perlu memastikan bahwa pengembang memiliki konfigurasi yang benar. Anda tidak perlu lagi mengelola mesin virtual, penyeimbang, atau grup keamanan. Oleh karena itu, istilah NoOps semakin banyak digunakan, walaupun masih penting untuk dapat mengkonfigurasi infrastruktur, terutama ketika menyangkut konfigurasi IAM dan mengoptimalkan sumber daya cloud.

Ada alat pemantauan dan visual yang sangat kuat seperti Epsagon, Thundra, Dashbird, dan IOPipe. Mereka memungkinkan Anda untuk memantau keadaan aplikasi tanpa server saat ini, menyediakan log dan penelusuran, mencatat metrik kinerja dan hambatan arsitektur, melakukan analisis biaya dan perkiraan, dan banyak lagi. Mereka tidak hanya memberi para insinyur, pengembang, dan arsitek DevOps gagasan komprehensif tentang cara kerja aplikasi, tetapi juga memungkinkan para manajer untuk memantau situasi secara real time, dengan biaya sumber daya per detik dan prediksi biaya. Mengelola ini dengan infrastruktur yang dikelola jauh lebih sulit.

Mendesain aplikasi tanpa server jauh lebih sederhana karena Anda tidak perlu menggunakan server web, mengelola mesin atau wadah virtual, menambal server, sistem operasi, gateway internet, dll. Abstraksi dari semua tanggung jawab ini memungkinkan arsitektur tanpa server untuk fokus pada hal utama - solusinya kebutuhan bisnis dan pelanggan.

Meskipun toolkit bisa lebih baik (itu membaik setiap hari), namun, pengembang dapat fokus pada penerapan logika bisnis dan distribusi kompleksitas aplikasi terbaik di berbagai layanan dalam arsitektur. Aplikasi tanpa server adalah event driven dan disarikan oleh penyedia cloud (misalnya, SQS, S3 events, atau stream DynamoDB). Oleh karena itu, pengembang hanya perlu meresepkan logika bisnis untuk merespons peristiwa tertentu, dan Anda tidak perlu khawatir tentang cara mengimplementasikan basis data dan antrian pesan yang lebih baik, atau bagaimana mengatur kerja optimal dengan data di penyimpanan perangkat keras tertentu.

Kode dapat dieksekusi dan didebug secara lokal, seperti halnya proses pengembangan apa pun. Pengujian unit tetap sama. Kemampuan untuk menyebarkan seluruh infrastruktur aplikasi dengan konfigurasi tumpukan kustom memungkinkan pengembang untuk dengan cepat mendapatkan umpan balik penting tanpa khawatir tentang biaya pengujian atau dampak pada lingkungan yang dikelola mahal.

Alat dan teknik untuk membangun aplikasi tanpa server


Tidak ada cara khusus untuk membangun aplikasi tanpa server. Serta seperangkat layanan untuk tugas ini. AWS adalah pemimpin di antara solusi serverless yang kuat saat ini, namun perhatikan Google Cloud , Zeit dan Firebase . Jika Anda menggunakan AWS, maka Serverless Application Model (SAM) dapat direkomendasikan sebagai pendekatan untuk mengumpulkan aplikasi , terutama ketika menggunakan C #, karena Visual Studio adalah toolkit yang hebat. SAM CLI dapat melakukan semuanya sama seperti Visual Studio, jadi Anda tidak akan kehilangan apa pun jika Anda beralih ke IDE atau editor teks lain. Tentu saja, SAM juga bekerja dengan bahasa lain.

Jika Anda menulis dalam bahasa lain, maka Serverless Framework adalah alat open source luar biasa yang memungkinkan Anda untuk mengonfigurasi apa pun dengan bantuan konfigurasi file YAML yang sangat kuat. Serverless Framework juga mendukung berbagai layanan cloud, jadi kami merekomendasikannya kepada mereka yang mencari solusi multi-cloud. Dia memiliki komunitas besar yang telah menciptakan banyak plug-in untuk kebutuhan apa pun.

Untuk pengujian lokal, alat open source Docker-Lambda, Serverless Local, DynamoDB Local, dan LocalStack sangat cocok. Teknologi tanpa server masih pada tahap awal pengembangan, seperti juga alat untuk mereka, jadi ketika menyiapkan skenario pengujian yang rumit, Anda harus berkeringat. Namun, hanya memperluas tumpukan di lingkungan dan pengujian di sana ternyata sangat murah. Dan Anda tidak perlu membuat salinan lokal persis dari lingkungan cloud.

Gunakan AWS Lambda Layers untuk mengurangi ukuran paket yang digunakan dan mempercepat pemuatan.

Gunakan bahasa pemrograman yang benar untuk tugas tertentu. Bahasa yang berbeda memiliki kelebihan dan kekurangan mereka sendiri. Ada banyak tolok ukur, tetapi JavaScript, Python, dan C # (.NET Core 2.1+) adalah pemimpin dalam hal kinerja AWS Lambda. API Runtime baru-baru ini muncul di AWS Lambda, yang memungkinkan Anda menentukan bahasa dan runtime yang diinginkan, jadi cobalah.

Simpan ukuran paket kecil untuk penyebaran. Semakin kecil mereka, semakin cepat mereka memuat. Hindari menggunakan perpustakaan besar, terutama jika Anda menggunakan beberapa fitur dari mereka. Jika Anda memprogram dalam JavaScript, maka gunakan alat bantu seperti Webpack untuk mengoptimalkan versi Anda dan hanya menyertakan apa yang benar-benar Anda butuhkan. .NET Core 3.0 memiliki QuickJit dan Tiered Compilation yang meningkatkan kinerja dan banyak membantu di awal yang dingin.

Ketergantungan fungsi serverless pada peristiwa pada awalnya dapat menyulitkan koordinasi logika bisnis. Dalam hal ini, antrian pesan dan mesin negara dapat sangat berguna. Fungsi Lambda mampu saling memanggil satu sama lain, tetapi lakukan hanya jika Anda tidak berharap menerima jawaban ("jepret dan lupakan") - Anda tidak ingin mendapatkan akun untuk menunggu penyelesaian fungsi lain. Antrian pesan berguna untuk mengisolasi bagian-bagian dari logika bisnis, mengelola kemacetan aplikasi, dan memproses transaksi (menggunakan antrian FIFO). Fungsi AWS Lambda dapat ditetapkan ke antrian SQS sebagai antrian pesan hang yang melacak pesan yang gagal untuk analisis selanjutnya. AWS Step Functions (state machine) sangat berguna untuk mengelola proses kompleks yang membutuhkan penciptaan rantai fungsi.Alih-alih memanggil fungsi Lambda fungsi lain, fungsi Langkah dapat mengoordinasikan transisi status, mentransfer data antar fungsi, dan mengontrol status fungsi global. Ini memungkinkan Anda untuk menentukan kondisi untuk coba lagi, atau apa yang perlu dilakukan ketika kesalahan tertentu terjadi - dalam kondisi tertentu, alat yang sangat kuat.

Kesimpulan


Dalam beberapa tahun terakhir, teknologi tanpa server telah berkembang dengan kecepatan yang belum pernah terjadi sebelumnya. Ada kesalahpahaman tertentu yang terkait dengan perubahan paradigma ini. Dengan mengabstraksi infrastruktur dan mengelola penskalaan, solusi tanpa server menawarkan manfaat signifikan: dari pengembangan yang disederhanakan dan proses DevOps, hingga pengurangan besar dalam biaya operasi.
Meskipun pendekatan serverless bukan tanpa kelemahan, ada metode pola desain yang dapat diandalkan yang dapat digunakan untuk membuat aplikasi tanpa server yang stabil atau mengintegrasikan elemen tanpa server ke dalam arsitektur yang ada.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles