Dapatkah saya memberi tahu pengembang front-end tentang arsitektur Serverless tanpa awan di dalam AWS (Amazon Web Services) dengan cara sederhana? Kenapa tidak Mari kita membuat aplikasi AWS React / Redux, dan kemudian berbicara tentang pro dan kontra dari lambda AWS.
Materi ini didasarkan pada transkrip laporan Marina Mironovich dari konferensi musim semi HolyJS 2018 kami di St. Petersburg.Secara resmi, Marina adalah pengembang terkemuka EPAM. Sekarang dia bekerja di grup arsitek solusi untuk pelanggan dan karena ini berpartisipasi dalam sejumlah besar proyek. Karena itu, akan lebih mudah bagi kami untuk menguraikan lingkaran minatnya saat ini daripada mendaftar semua teknologi yang digunakannya.
Pertama-tama, saya tertarik pada semua teknologi cloud, khususnya, AWS, karena saya banyak bekerja dengan ini dalam produksi. Tetapi saya mencoba mengikuti semua yang lain.
Frontend adalah cinta pertamaku dan sepertinya selamanya. Secara khusus, saya saat ini bekerja dengan Bereaksi dan Bereaksi Asli, jadi saya tahu sedikit tentang itu. Saya juga mencoba melacak semua yang lainnya. Saya tertarik pada segala sesuatu yang berkaitan dengan dokumentasi proyek, misalnya, diagram UML. Karena saya adalah anggota dari kelompok arsitek solusi, saya harus melakukan banyak hal.
Bagian 1. Latar Belakang
Ide untuk berbicara tentang Serverless datang kepada saya sekitar setahun yang lalu. Saya ingin berbicara tentang Serverless untuk pengembang front-end dengan mudah dan alami. Agar Anda tidak memerlukan pengetahuan tambahan untuk menggunakannya, semakin banyak teknologi sekarang memungkinkan Anda untuk melakukan ini.
Hingga taraf tertentu, idenya terwujud - saya
berbicara tentang Serverless di FrontTalks 2017. Tetapi ternyata 45 menit tidak cukup untuk cerita yang sederhana dan mudah dimengerti. Oleh karena itu, laporan itu dibagi menjadi dua bagian, dan sekarang sebelum Anda adalah "seri" kedua. Siapa yang tidak melihat yang pertama - jangan khawatir, ini tidak ada salahnya untuk memahami apa yang tertulis di bawah ini. Seperti dalam acara TV yang layak, saya akan mulai dengan ringkasan dari bagian sebelumnya. Lalu saya akan beralih ke jus itu sendiri - kita akan membuat aplikasi React / Redux. Dan akhirnya, saya akan berbicara tentang pro dan kontra fungsi cloud pada prinsipnya (khususnya, AWS lambdas) dan apa lagi yang bisa dilakukan dengannya. Saya berharap bagian ini akan bermanfaat bagi semua yang sudah terbiasa dengan lambda AWS. Yang terpenting, dunia tidak berakhir dengan Amazon, jadi mari kita bicara tentang apa lagi yang ada di bidang fungsi cloud.
Apa yang akan saya gunakan
Untuk membuat aplikasi, saya akan menggunakan banyak layanan Amazon:
- S3 adalah sistem file di awan. Di sana kita akan menyimpan aset statis.
- IAM (hak akses untuk pengguna dan layanan) - secara implisit, tetapi akan digunakan di latar belakang sehingga layanan berkomunikasi satu sama lain.
- API Gateway (URL untuk mengakses situs) - Anda akan melihat URL tempat kami dapat memanggil lambda kami.
- CloudFormation (untuk penyebaran) - akan digunakan secara implisit di latar belakang.
- AWS Lambda - kami datang ke sini untuk ini.
Apa itu serverless dan apa itu AWS Lambda?
Sebenarnya Serverless adalah penipuan besar, karena tentu saja ada server: di suatu tempat, semuanya dimulai. Tetapi apa yang terjadi di sana?
Kami sedang menulis fungsi, dan fungsi ini berjalan di server. Tentu saja, itu tidak hanya dimulai begitu saja, tetapi juga dalam semacam wadah. Dan, pada kenyataannya, fungsi ini dalam wadah di server disebut lambda.
Dalam kasus lambda, kita bisa melupakan servernya. Saya bahkan akan mengatakan ini: ketika Anda menulis fungsi lambda, berbahaya untuk memikirkannya. Kami tidak bekerja dengan lambda seperti yang kami lakukan dengan server.
Bagaimana cara menyebarkan lambda
Sebuah pertanyaan logis muncul: jika kita tidak memiliki server, bagaimana kita menggunakannya? Ada SSH di server, kami mengunggah kode, meluncurkannya - semuanya baik-baik saja. Apa yang harus dilakukan dengan lambda?
Opsi 1. Kami tidak dapat menyebarkannya.AWS di konsol membuat IDE yang bagus dan lembut bagi kami, tempat kami dapat datang dan menulis fungsi di sana.
Itu bagus, tapi tidak bisa diperluas.
Opsi 2. Kita dapat membuat zip dan mengunduhnya dari baris perintahBagaimana cara kita membuat file zip?
zip -r build/lambda.zip index.js [node_modules/] [package.json]
Jika Anda menggunakan node_modules, semua ini di-zip menjadi satu arsip.
Lebih lanjut, tergantung pada apakah Anda membuat fungsi baru atau jika Anda sudah memiliki fungsi seperti itu, Anda melakukannya
aws lambda create-function...
juga
aws lambda update-function-code...
Apa masalahnya? Pertama, AWS CLI ingin tahu apakah suatu fungsi sedang dibuat atau apakah Anda sudah memilikinya. Ini adalah dua tim yang berbeda. Jika Anda ingin memperbarui tidak hanya kode, tetapi juga beberapa atribut dari fungsi ini, masalah akan dimulai. Jumlah perintah ini bertambah, dan Anda harus duduk dengan direktori dan memikirkan perintah mana yang harus digunakan.
Kita bisa melakukannya dengan lebih baik dan lebih mudah. Untuk ini, kami memiliki kerangka kerja.
Kerangka kerja AWS Lambda
Ada banyak kerangka kerja seperti itu. Ini terutama AWS CloudFormation, yang bekerja bersama dengan AWS CLI. CloudFormation adalah file Json yang menggambarkan layanan Anda. Anda menggambarkannya dalam file Json, kemudian melalui AWS CLI mengatakan "eksekusi", dan secara otomatis akan membuat segalanya untuk Anda dalam layanan AWS.
Tetapi masih sulit untuk tugas sederhana seperti merender sesuatu. Di sini ambang entri terlalu besar - Anda perlu membaca struktur apa yang dimiliki CloudFormation, dll.
Mari kita coba sederhanakan. Dan di sini muncul berbagai kerangka kerja: APEX, Zappa (hanya untuk Python), Claudia.js. Saya hanya mendaftarkan beberapa saja, secara acak.
Masalah dan kekuatan kerangka kerja ini adalah bahwa mereka sangat terspesialisasi. Jadi, mereka sangat pandai melakukan beberapa tugas sederhana. Misalnya, Claudia.js sangat bagus untuk membuat API REST. Dia akan membuat AWS memanggil API Gateway, dia akan membuat lambda untuk Anda, semuanya akan terkunci dengan indah. Tetapi jika Anda perlu menerapkan sedikit lebih banyak, masalah mulai - Anda harus menambahkan sesuatu, membantu, mencari, dll.
Zappa hanya ditulis untuk Python. Dan saya ingin sesuatu yang lebih ambisius. Dan inilah Terraform dan cinta Serverless-ku.
Serverless berada di tengah-tengah antara CloudFormation yang sangat besar, yang dapat melakukan hampir semua hal, dan kerangka kerja yang sangat khusus ini. Hampir semuanya dapat digunakan di dalamnya, tetapi melakukan semuanya masih cukup mudah. Ini juga memiliki sintaks yang sangat ringan.
Terraform, sampai taraf tertentu, merupakan analog dari CloudFormation. Terraform adalah open source, di dalamnya Anda dapat menggunakan semuanya - baik, atau hampir semuanya. Dan ketika AWS menciptakan layanan, Anda dapat menambahkan sesuatu yang baru di sana. Tapi itu besar dan rumit.
Sejujurnya, dalam produksi kami menggunakan Terraform, karena dengan Terraform semua yang kami miliki naik lebih mudah - Serverless tidak akan menjelaskan semua ini. Tapi Terraform sangat kompleks. Dan ketika saya menulis sesuatu untuk pekerjaan, saya pertama kali menulis di Serverless, mengujinya untuk kinerja, dan hanya setelah konfigurasi saya diuji dan diuji, saya menulis ulang di Terraform (ini "menyenangkan" selama beberapa hari lagi).
Tanpa server
Mengapa saya suka Serverless?
- Serverless memiliki sistem yang memungkinkan Anda membuat plugin. Menurut pendapat saya, ini adalah keselamatan dari segalanya. Tanpa server - sumber terbuka. Tetapi menambahkan sesuatu ke open source tidak selalu mudah. Anda perlu memahami apa yang terjadi dalam kode yang ada, mematuhi pedoman, setidaknya codestyle, mengirimkan PR, mereka akan melupakan PR ini dan akan mengumpulkan debu selama tiga tahun. Menurut hasil, Anda bercabang, dan ini akan berada di suatu tempat untuk Anda secara terpisah. Semua ini sangat tidak sehat. Tetapi ketika ada plugin, semuanya disederhanakan. Anda perlu menambahkan sesuatu - Anda bertekad menciptakan plugin kecil Anda sendiri. Untuk melakukan ini, Anda tidak perlu lagi memahami apa yang terjadi di dalam Serverless (jika ini bukan pertanyaan yang sangat khusus). Anda cukup menggunakan API yang tersedia, di suatu tempat Anda menyimpan plugin atau menyebarkannya untuk semua orang. Dan semuanya bekerja untuk Anda. Selain itu, sudah ada kebun binatang besar plugin dan orang-orang yang menulis plugin ini. Artinya, mungkin sesuatu sudah diputuskan untuk Anda.
- Serverless membantu menjalankan lambda secara lokal. Kelemahan yang cukup besar dari lambda adalah AWS tidak berpikir tentang bagaimana kita akan men-debug dan mengujinya. Tetapi Serverless memungkinkan Anda untuk menjalankan semuanya secara lokal, melihat apa yang terjadi (ia bahkan melakukan ini bersama dengan Gateway API).
Demonstrasi
Sekarang saya akan menunjukkan bagaimana semua ini bekerja. Selama satu setengah hingga dua menit berikutnya, kita akan dapat membuat layanan yang akan merender halaman HTML kita.
Pertama, di folder baru, saya menjalankan SLS Buat template:
mkdir sls-holyjs
cd sls-holyjs
sls create --template aws-nodejs-ecma-script
npm install
Pengembang tanpa server menangani kami - memungkinkan untuk membuat layanan dari template. Dalam hal ini, saya menggunakan
nodejs-ecma-script , yang akan membuat beberapa file untuk saya, seperti konfigurasi webpack, package.json, beberapa fungsi dan serverless.yml:
ls
Saya tidak membutuhkan semua fitur. Saya akan menghapus ganti nama pertama, kedua di holyjs:
Saya akan sedikit mengubah serveless.yml, di mana saya memiliki deskripsi semua layanan yang diperlukan:
Baiklah, maka saya akan memperbaiki respons yang mengembalikan fungsi:
Saya akan membuat HTML "Hello HolyJS" dan menambahkan pegangan untuk rendering.
Selanjutnya:
sls deploy
Dan voila! Ada URL tempat saya dapat melihat di akses publik apa yang sedang dirender:
Percaya, tapi verifikasi. Saya akan pergi ke Konsol AWS dan memverifikasi bahwa saya telah membuat fungsi holyjs:
Seperti yang Anda lihat, sebelum menggunakan itu, Serverless akan membangunnya menggunakan webpack. Selain itu, sisa infrastruktur yang dijelaskan di sana akan dibuat - API Gateway, dll.
Ketika saya ingin menghapus ini:
sls remove
Semua infrastruktur yang dijelaskan dalam serverless.yml akan dihapus.
Jika seseorang berada di belakang proses yang dijelaskan di sini, saya mengundang Anda untuk sekadar meninjau
laporan saya
sebelumnya .
Jalankan lambda secara lokal
Saya menyebutkan bahwa lambda dapat dijalankan secara lokal. Ada dua opsi peluncuran di sini.
Opsi 1. Kami menjalankan semua yang ada di terminalKami mendapatkan apa yang dikembalikan fungsi kami.
sls invoke local -f [fn_name]
Jangan lupa, kami membuat aplikasi isomorfik, itu akan menjadi HTML dan CSS, jadi di terminal itu entah bagaimana tidak terlalu menarik untuk melihat garis HTML yang panjang. Di sana Anda dapat memeriksa apakah fungsinya berfungsi. Tetapi saya ingin menjalankan dan merender ini di browser. Oleh karena itu, saya perlu banyak gateway API dengan lambda.
Untuk melakukan ini, ada plugin serverless-offline terpisah yang akan meluncurkan lambda Anda pada beberapa port (ini ditulis), maka itu akan menampilkan URL di terminal di mana Anda dapat mengaksesnya.
sls offline --port 8000 start
Bagian terbaiknya adalah ada hot reload. Artinya, Anda menulis kode fungsi, memperbarui browser Anda dan Anda diperbarui apa fungsi kembali. Anda tidak harus memulai kembali semuanya.
Ini adalah ringkasan dari bagian pertama laporan. Sekarang kita beralih ke bagian utama.
Bagian 2. Rendering dengan AWS
Proyek yang dijelaskan di bawah ini
sudah ada di GitHub. Jika Anda tertarik, Anda dapat mengunduh kode di sana.
Mari kita mulai dengan cara kerjanya.
Misalkan ada pengguna - saya.
- Saya membuka situs.
- Di URL tertentu, kami mengakses API gateway. Saya ingin mencatat bahwa Gateway API sudah menjadi layanan AWS, kami sudah berada di awan.
- Gateway API akan memanggil lambda.
- Lambda akan membuat situs, dan semua ini akan kembali ke browser.
- Browser akan mulai membuat dan menyadari bahwa beberapa file statis hilang. Kemudian ia akan beralih ke bucket S3 (sistem file kami, tempat kami akan menyimpan semua statika; di bucket S3 Anda dapat meletakkan semuanya - font, gambar, CSS, JS).
- Data dari bucket S3 akan kembali ke browser.
- Browser akan merender halaman.
- Semua orang senang.
Mari kita lakukan sedikit review kode dari apa yang saya tulis.
Jika Anda pergi ke GitHub, Anda akan melihat struktur file berikut:
lambda-react
README.md
config
package.json
public
scripts
serverless.yml
src
yarn.lock
Semua ini secara otomatis dihasilkan dalam kit alat Bereaksi / Redux. Bahkan, di sini kita hanya akan tertarik pada beberapa file dan mereka harus sedikit diperbaiki:
- konfigurasi
- package.json
- serverless.yml - karena kami akan menggunakan,
- src - tidak ada tempat tanpa itu.
Mari kita mulai dengan konfigurasi
Untuk menyatukan semuanya di server, kita perlu menambahkan webpack.config lain:
Webpack.config ini sudah akan dibuat untuk Anda jika Anda menggunakan templat. Dan ada variabel
slsw.lib.entries secara otomatis diganti, yang akan menunjuk ke penangan lambda Anda. Jika mau, Anda bisa mengubahnya sendiri dengan menentukan sesuatu yang lain.
Kita perlu merender semuanya untuk node (
target: 'node' ). Pada prinsipnya, semua loader lainnya tetap sama seperti untuk aplikasi Bereaksi reguler.
Lebih jauh ke package.json
Kami hanya akan menambahkan beberapa skrip - mulai dan bangun telah dibuat dengan React / Redux - tidak ada perubahan. Tambahkan skrip untuk meluncurkan lambda dan skrip untuk menyebarkan lambda.
serverless.yml
File yang sangat kecil - hanya 17 baris, semuanya di bawah ini:
Apa yang menarik bagi kita di dalamnya? Pertama-tama, pawang. Path lengkap ke file
src/lambda/handler (
src/lambda/handler ) dan fungsi handler ditentukan melalui titik.
Jika Anda benar-benar ingin, Anda dapat mendaftarkan beberapa penangan dalam satu file. Juga di sini adalah jalur ke webpack, yang harus mengumpulkan semua ini. Pada dasarnya, semuanya: sisanya sudah dihasilkan secara otomatis.
Yang paling menarik adalah src
Berikut ini adalah aplikasi React / Redux besar (dalam kasus saya ini tidak besar - ke halaman). Dalam folder lambda tambahan adalah semua yang kita butuhkan untuk membuat lambda:
Ini adalah 2 file:
Mari kita mulai dengan pawang. Yang paling penting adalah baris 13. Ini adalah renderer, yang merupakan lambda yang akan dipanggil di awan:
Seperti yang Anda lihat, fungsi
render () mengembalikan janji, dari mana semua pengecualian harus ditangkap. Ini adalah kekhasan lambda, jika tidak lambda tidak akan segera berakhir, tetapi akan bekerja sampai batas waktu. Anda harus membayar uang ekstra untuk kode yang sudah jatuh. Untuk mencegah hal ini terjadi, Anda harus menyelesaikan lambda sedini mungkin - pertama-tama, tangkap dan tangani semua pengecualian. Nanti kita akan kembali ke ini.
Jika kami tidak memiliki kesalahan atau pengecualian, kami memanggil fungsi
createResponse , yang mengambil lima baris. Kami hanya menambahkan semua header sehingga ditampilkan dengan benar di browser:
Hal yang paling menarik di sini adalah fungsi
render , yang akan membuat halaman kita:
Fungsi ini datang kepada kita dari renderer.js. Mari kita lihat apa yang ada di sana.
Aplikasi isomorfik diberikan di sana. Selain itu, ini diberikan pada server apa pun - tidak masalah apakah itu lambda atau tidak.
Saya tidak akan memberi tahu Anda secara terperinci tentang apa itu aplikasi isomorfik, bagaimana merendernya, karena ini adalah topik yang sama sekali berbeda, dan ada orang yang mengatakannya lebih baik daripada saya. Berikut adalah beberapa tutorial yang saya temukan dengan googling hanya dalam beberapa menit:
Jika Anda mengetahui laporan lain, Anda dapat memberi saran, saya akan memberikan tautan kepada mereka di Twitter saya.
Agar tidak kehilangan siapa pun, saya hanya naik ke atas, ceritakan apa yang terjadi di sana.
Pertama-tama, kita perlu membuat ini dengan HTML / React / Redux.
Ini dilakukan melalui metode Bereaksi standar -
renderToString :
Selanjutnya kita perlu membuat gaya agar konten kita tidak berkedip. Ini bukan tugas yang sangat sepele. Ada beberapa paket npm yang menyelesaikannya. Sebagai contoh, saya menggunakan
node-style-loader , yang akan menggabungkan semuanya dalam
styleTag , dan kemudian Anda dapat menempelkannya ke dalam HTML.
Jika ada paket yang lebih baik - itu adalah kebijaksanaan Anda.
Selanjutnya kita harus melewati status Redux. Karena Anda merender di server, Anda mungkin ingin mendapatkan beberapa data, dan Anda tidak ingin Redux bertanya kembali dan merendernya lagi. Ini adalah tugas yang cukup standar. Ada beberapa contoh di situs web Redux utama tentang cara melakukan ini: kita membuat objek dan kemudian meneruskannya melalui variabel global:
Sekarang sedikit lebih dekat ke lambda.
Maka perlu dilakukan penanganan kesalahan. Kami ingin menangkap semuanya dan melakukan sesuatu dengan mereka, setidaknya menghentikan perkembangan lambda. Misalnya, saya melakukan ini melalui
promise :
Selanjutnya, kita perlu mengganti URL kita dengan file statis. Dan untuk ini kita perlu mencari tahu di mana lambda berjalan - secara lokal atau di suatu tempat di awan. Bagaimana cara mengetahuinya?
Kami akan melakukan ini melalui variabel lingkungan:
…
const bundleUrl = process.env.NODE_ENV === 'AWS' ?
AWS_URL : LOCAL_URL;
Sebuah pertanyaan menarik: bagaimana variabel lingkungan berkumpul di lambda. Sebenarnya cukup mudah. Dalam yml, Anda dapat meneruskan variabel apa pun ke
environment . Ketika dikunci, mereka akan tersedia:
Nah, bonus - setelah kami menggunakan lambda, kami ingin menggunakan semua aset statis. Untuk melakukan ini, kami telah menulis sebuah plugin di mana Anda dapat menetapkan keranjang S3 tempat Anda ingin menyebarkan sesuatu:
Secara total, kami membuat aplikasi isomorfik dalam waktu sekitar lima menit untuk menunjukkan bahwa ini semua mudah.
Sekarang mari kita bicara sedikit tentang teori - pro dan kontra dari lambda.
Mari kita mulai dengan yang buruk.
Kontra fungsi lambda
Minus mungkin termasuk (atau mungkin tidak) waktu awal yang dingin. Misalnya, untuk lambda di Node.js yang kami tulis sekarang, waktu mulai yang dingin tidak berarti banyak.
Grafik di bawah ini menunjukkan waktu mulai dingin. Dan ini bisa menjadi masalah besar, terutama untuk Java dan C # (perhatikan titik-titik oranye) - Anda tidak ingin Anda butuh lima atau enam detik untuk memulai kode.
Untuk Node.js, waktu mulai hampir nol - 30 - 50 ms. Tentu saja, bagi sebagian orang ini mungkin juga menjadi masalah. Tetapi fungsinya dapat dipanaskan (meskipun ini bukan topik laporan ini). Jika ada yang tertarik dengan bagaimana tes ini dilakukan, selamat datang di acloud.guru, mereka akan memberi tahu Anda segalanya (
dalam artikel ).
Jadi apa kerugiannya?
Batasan Ukuran Kode Fungsi
Kode harus kurang dari 50 MB. Apakah mungkin untuk menulis fungsi sebesar itu? Tolong jangan lupa tentang node_modules. Jika Anda menghubungkan sesuatu, terutama jika ada file biner di sana, Anda dapat dengan mudah mencapai lebih dari 50 MB, bahkan untuk file zip. Saya punya kasus seperti itu. Tapi ini adalah alasan tambahan untuk melihat apa yang Anda sambungkan ke node_modules.
Keterbatasan Runtime
Secara default, fungsi ini dijalankan sesaat. Jika tidak berakhir setelah satu detik, Anda akan memiliki batas waktu. Tapi kali ini bisa ditingkatkan di pengaturan. Saat membuat fungsi, Anda dapat mengatur nilainya menjadi lima menit. Lima menit adalah tenggat waktu yang sulit. Ini bukan masalah bagi situs. Tetapi jika Anda ingin melakukan sesuatu yang lebih menarik pada lambdas, misalnya, memproses gambar, mengubah teks menjadi suara atau suara menjadi teks, dll., Perhitungan seperti itu dapat dengan mudah memakan waktu lebih dari lima menit. Dan itu akan menjadi masalah. Apa yang harus dilakukan? Optimalkan atau tidak gunakan lambda.
Hal menarik lain yang muncul sehubungan dengan batas waktu eksekusi lambda. Ingat tata letak situs kami. Semuanya bekerja dengan sempurna sampai produk datang dan berharap pada feed situs real time - untuk menampilkan berita secara real time. Kita tahu bahwa ini diterapkan dengan WebSockets. Tapi WebSockets tidak berfungsi selama lima menit, mereka harus disimpan lebih lama. Dan di sini batas lima menit menjadi masalah.
Sebuah komentar kecil. Bagi AWS, ini bukan lagi masalah. Mereka menemukan cara untuk mengatasi ini. Tetapi berbicara secara umum, begitu soket web muncul, lambda bukanlah solusi untuk Anda. Anda perlu beralih ke server lama yang baik lagi.
Jumlah fungsi paralel per menit
Di atas adalah batas 500 hingga 3.000, tergantung pada wilayah di mana Anda berada. Menurut pendapat saya, di Eropa hampir 500. 3000 didukung di AS.
Jika Anda memiliki situs yang sibuk dan Anda mengharapkan lebih dari tiga ribu permintaan per menit (yang mudah dibayangkan), ini menjadi masalah. Tetapi sebelum kita berbicara tentang minus ini, mari kita bicara sedikit tentang bagaimana skala lambda.
Permintaan datang kepada kami, dan kami mendapatkan lambda. Sementara lambda ini dieksekusi, dua permintaan lagi datang kepada kami - kami mulai dua lambda lagi. Orang-orang mulai datang ke situs kami, permintaan muncul dan lambdas diluncurkan, semakin banyak.
Dengan melakukannya, Anda membayar waktu ketika lambda berjalan. Misalkan Anda membayar satu sen untuk satu detik eksekusi lambda. Jika Anda memiliki 10 lambda per detik, maka Anda akan membayar 10 sen untuk detik ini. Jika Anda memiliki sejuta lambda berjalan per detik, itu sekitar 10 ribu dolar. Sosok yang tidak menyenangkan.
Oleh karena itu, AWS memutuskan bahwa mereka tidak ingin mengosongkan dompet Anda dalam sedetik jika Anda melakukan tes Anda dengan salah dan Anda memulai DDOS sendiri, menyebabkan lambda, atau orang lain datang untuk melakukan DDOS. Oleh karena itu, batas tiga ribu ditetapkan - sehingga Anda memiliki kesempatan untuk menanggapi situasi tersebut.
Jika memuat 3000 permintaan reguler untuk Anda, Anda dapat menulis dalam AWS dan mereka akan menaikkan batas.
Tanpa kewarganegaraan
Ini adalah yang terakhir, sekali lagi, minus yang kontroversial.
Apa itu stateless? Di sini muncul lelucon tentang ikan mas - mereka tidak memiliki konteks:
Lambda, dipanggil untuk kedua kalinya, tidak tahu apa-apa tentang panggilan pertama.
Mari saya tunjukkan sebuah contoh. Katakanlah saya memiliki sistem - kotak hitam besar. Dan sistem ini, antara lain, dapat mengirim SMS.
Pengguna datang dan berkata: kirim nomor templat SMS 1. Dan sistem mengirimkannya ke perangkat nyata.
Pada titik tertentu, produk menyatakan keinginan untuk mencari tahu apa yang akan pergi ke sana, dan untuk memeriksa bahwa tidak ada yang rusak dalam sistem ini di mana pun. Untuk melakukan ini, kami akan mengganti perangkat asli dengan semacam nomor tes - misalnya, Twilio dapat melakukan ini. Dia akan memanggil Webhook, mengirim teks SMS, kami akan memproses teks SMS ini dalam aplikasi (kita perlu memeriksa bahwa templat kita telah menjadi SMS yang benar).
Untuk memeriksa, kita perlu tahu apa yang dikirim - kita akan melakukan ini melalui aplikasi uji. Tetap membandingkan dan menampilkan hasilnya.
Mari kita coba melakukan hal yang sama pada lambda.
Lambda akan mengirim SMS, SMS akan datang ke Twilio.
Saya menarik garis putus-putus bukan karena kebetulan, karena SMS dapat kembali dalam hitungan menit, jam atau hari - tergantung operator Anda, artinya, ini bukan panggilan sinkron. Pada saat ini, lambda akan melupakan segalanya, dan kami tidak akan dapat memeriksa SMS.
Saya akan mengatakan bahwa ini bukan minus, tetapi fitur. Skema dapat diulang. Ada beberapa opsi untuk melakukan ini, saya akan menawarkan saya sendiri. Jika kita memiliki stateless, dan kita ingin menyimpan sesuatu, maka kita pasti perlu menggunakan penyimpanan, misalnya, database, S3, tetapi apa pun yang akan menyimpan konteks kita.
Dalam skema dengan penyimpanan SMS, itu akan dikirim ke nomor tes. Dan ketika Webhook menyebutnya - saya sarankan memanggil, misalnya, lambda kedua, karena ini adalah fungsi yang sedikit berbeda. Dan lambda kedua sudah bisa pergi dan mengambil SMS-ku yang masuk dari database, periksa dan tampilkan hasilnya.
Bingo!
Pada awalnya, saya mengatakan bahwa Anda perlu melupakan server jika Anda menulis lambda. Saya bertemu orang-orang yang menulis di node.js dan digunakan untuk mengekspresikan server. Mereka suka mengandalkan cache, dan cache tetap di lambdas. Dan kadang-kadang, ketika mereka menguji, itu akan berhasil, dan kadang-kadang tidak. Bagaimana ini mungkin?Misalkan kita memiliki server, dan sebuah wadah dimulai di dalamnya. Meluncurkan wadah adalah operasi yang cukup mahal. Pertama, Anda harus membuat wadah ini. Hanya setelah dibuat, kode fungsi digunakan di sana dan dapat dieksekusi. Setelah fungsi Anda dieksekusi, wadah tidak terbunuh, karena AWS percaya bahwa Anda dapat memanggil fungsi ini lagi. AWS tidak pernah menulis berapa lama wadah itu hidup setelah fungsi berhenti. Kami melakukan eksperimen. Menurut pendapat saya, untuk simpul ini adalah tiga menit, untuk Jawa mereka dapat memegang wadah selama 12-15 menit. Tetapi ini berarti bahwa ketika fungsi berikutnya dipanggil, ia akan dipanggil dalam wadah yang sama dan di lingkungan yang sama. Jika Anda menggunakan cache node di suatu tempat, Anda membuat variabel di sana, dll. - jika Anda tidak membersihkannya, mereka akan tetap di sana. Jadi jika Anda menulis di lambda,maka Anda perlu melupakan cache secara umum, jika tidak Anda bisa masuk ke situasi yang tidak menyenangkan. Ini sulit untuk ditangkis.Plus fungsi lambda
Jumlah mereka lebih sedikit, tetapi bagi saya mereka tampak lebih menyenangkan.- Pertama-tama, kami benar-benar lupa bahwa ada server. Sebagai pengembang, saya menulis fungsi dalam javascript, dan hanya itu. Saya yakin banyak dari Anda menulis fungsi dalam javascript, Anda tidak perlu tahu apa-apa lagi tentang ini.
- Tidak perlu memikirkan cache, juga tentang penskalaan, vertikal atau horizontal. Apa yang Anda tulis akan berhasil. Tidak masalah jika satu orang datang ke situs Anda sebulan atau akan ada satu juta kunjungan.
- Dalam kasus lambda AWS, mereka sudah memiliki integrasi sendiri dengan hampir semua server mereka (DynamoDB, Alexa, API Gateway, dll.).
Apa lagi yang bisa dilakukan pada lambdas?
Saya memberikan contoh yang cukup standar - saya berbicara tentang rendering aplikasi isomorfik, karena pada dasarnya mereka menganggap lambdas sebagai REST API. Tetapi saya ingin memberikan beberapa contoh lagi tentang apa yang dapat dilakukan dengan mereka, hanya untuk memberi Anda makanan untuk pemikiran dan imajinasi.Pada prinsipnya, pada lambda Anda dapat melakukan apa saja ... dengan tanda bintang.- Layanan HTTP adalah apa yang saya bicarakan. REST API, setiap endpoint API adalah satu lambda. Sangat cocok. Terutama mengingat bagaimana perusahaan sering menggunakan node.js untuk membuat middleware. Kami memiliki java yang melakukan semua penetapan biaya, lalu kami menulis layer pada js yang menangani permintaan dengan sangat mudah. Ini dapat ditulis ulang dalam lambdas dan akan lebih keren.
- IoT — , Alexa - -, , .
- Chat Bots — , IoT.
- Image/Video conversions.
- Machine learning.
- Batch Jobs — - , Batch Job .
Sekarang, selain Amazon, Google, Azure, IBM, Twillio, hampir semua layanan besar ingin mengimplementasikan fungsi cloud di rumah mereka. Jika Roskomnadzor memblokir semuanya, kami memulai server favorit kecil di garasi kami dan menggunakan komputasi awan kami di sana. Untuk melakukan ini, kita perlu open source (terlebih lagi karena Anda harus membayar untuk layanan, dan open source gratis). Dan open source tidak tinggal diam. Mereka telah membuat sejumlah implementasi yang tidak realistis dari semua ini. Sekarang saya akan mengatakan kata-kata menakutkan untuk frontends - Docker Swarm, Kubernetes - semuanya bekerja seperti itu.Bagian terbaiknya adalah, pertama, fungsi cloud tetap sederhana. Jika Anda memiliki fungsi pada AWS atau lambdas, menerjemahkannya ke open source juga mudah.Tidak semua perkembangan tercantum di bawah ini. Saya hanya memilih yang lebih besar dan lebih menarik. Daftar lengkapnya sangat besar: banyak startup yang mulai mengerjakan topik ini sekarang:- Fungsi besi
- Fnproject
- Openfaas
- Apache OpenWhisk
- Kubeless
- Fisi
- Funktion
Saya mencoba Fnproject dan hanya menghabiskan beberapa jam untuk mentransfer aplikasi isomorfik ini ke Fnproject dan menjalankannya secara lokal dengan wadah Kubernetes.Masih terukur dengan cepat. Anda akan memiliki banyak API Gateway (tentu saja, tanpa sisa layanan), tetapi Anda masih memiliki URL yang memanggil lambda. Dan pada kenyataannya, hampir semua orang bisa melupakan server, seperti yang dijanjikan, kecuali satu orang yang akan menggunakan kerangka kerja ini dan mengkonfigurasi orkestrasi Kubernetes ini sehingga pengembang yang bahagia dapat menggunakannya nanti.. HolyJS 2018 Moscow, 24-25 . , Early Bird-.