Sanajan teknologi tanpa server wis cepet populer ing taun-taun pungkasan, isih ana akeh misconceptions lan rasa wedi sing ana gandhengane. Ketergantungan vendor, perkakas, manajemen biaya, wiwitan kadhemen, ngawasi, lan siklus urip pangembangan kabeh dadi topik panas nalika nerangake teknologi tanpa server. Ing artikel iki, kita bakal njelajah sawetara topik sing kasebut, uga nuduhake tips lan pranala menyang sumber informasi sing migunani kanggo mbantu pamula nggawe aplikasi tanpa server sing kuat, fleksibel, lan larang regane.
Kesalahan babagan Teknologi Tanpa Server
Akeh wong sing mikir yen proses tanpa server lan tanpa server (, FaaS) meh padha. Iki tegese prabΓ©dan ora banget gedhe lan iku worth ngenalke anyar. Sanajan AWS Lambda minangka salah sawijining bintang ing jaman jaya tanpa server lan salah sawijining unsur paling populer ing arsitektur tanpa server, nanging arsitektur iki luwih akeh tinimbang FaaS.
Prinsip dhasar ing mburi teknologi tanpa server yaiku sampeyan ora perlu kuwatir babagan ngatur lan nggedhekake infrastruktur sampeyan, sampeyan mung mbayar apa sing sampeyan gunakake. Akeh layanan sing cocog karo kritΓ©ria kasebut - AWS DynamoDB, S3, SNS utawa SQS, Graphcool, Auth0, Now, Netlify, Firebase lan liya-liyane. UmumΓ©, tanpa server tegese nggunakake kekuwatan komputasi awan tanpa perlu ngatur infrastruktur lan ngoptimalake kanggo skala. Iki uga ateges keamanan ing tingkat infrastruktur ora dadi keprihatinan sampeyan maneh, sing entuk manfaat gedhe amarga angel lan kerumitan nyukupi standar keamanan. Pungkasan, sampeyan ora kudu tuku infrastruktur sing diwenehake kanggo sampeyan.
Serverless bisa dianggep minangka "negara pikiran": mentalitas tartamtu nalika ngrancang solusi. Ngindhari pendekatan sing mbutuhake pangopènan infrastruktur apa wae. Kanthi pendekatan tanpa server, kita nglampahi wektu kanggo ngrampungake tugas sing langsung mengaruhi proyek kasebut lan nggawa keuntungan kanggo pangguna: kita nggawe logika bisnis sing lestari, ngembangake antarmuka pangguna, lan ngembangake API adaptif lan dipercaya.
Contone, yen bisa nyegah ngatur lan njaga platform telusuran teks gratis, mula sing bakal ditindakake. Pendekatan iki kanggo mbangun aplikasi bisa nyepetake wektu menyang pasar, amarga sampeyan ora perlu mikir babagan ngatur infrastruktur kompleks. Ngilangi tanggung jawab lan biaya manajemen infrastruktur lan fokus kanggo mbangun aplikasi lan layanan sing dibutuhake pelanggan. Patrick Debois disebut pendekatan iki , istilah kasebut diadopsi ing komunitas tanpa server. Fungsi kudu dianggep minangka link kanggo layanan minangka modul deployable (tinimbang deploying kabeh perpustakaan utawa aplikasi web). Iki nyedhiyakake granularitas sing luar biasa kanggo ngatur penyebaran lan owah-owahan ing aplikasi kasebut. Yen sampeyan ora bisa masang fungsi kanthi cara iki, bisa uga nuduhake yen fungsi kasebut nindakake akeh banget tugas lan kudu diowahi maneh.
Sawetara bingung amarga gumantung marang vendor nalika ngembangake aplikasi awan. Semono uga karo teknologi tanpa server, lan iki meh ora salah. Ing pengalaman kita, mbangun aplikasi tanpa server ing AWS, digabungake karo kemampuan AWS Lambda kanggo nggabungake layanan AWS liyane, minangka bagean saka kekuwatan arsitektur tanpa server. Iki minangka conto sinergi sing apik, nalika asil kombinasi luwih saka mung jumlah istilah. Nyoba ngindhari ketergantungan vendor bisa ngalami masalah liyane. Nalika nggarap wadhah, luwih gampang ngatur lapisan abstraksi dhewe ing antarane panyedhiya awan. Nanging nalika nerangake solusi tanpa server, gaweyan ora bakal mbayar, utamane yen efektifitas biaya dianggep wiwit wiwitan. Priksa manawa sampeyan ngerti carane vendor nyedhiyakake layanan. Sawetara layanan khusus gumantung ing titik integrasi karo vendor liyane lan bisa nyedhiyakake konektivitas plug-and-play metu saka kothak. Iku luwih gampang kanggo nyedhiyani telpon Lambda saka endpoint API gateway saka proxy panjalukan kanggo sawetara wadhah utawa conto EC2. Graphcool nyedhiyakake konfigurasi sing gampang karo Auth0, sing luwih gampang tinimbang nggunakake alat otentikasi pihak katelu.
Milih vendor sing tepat kanggo aplikasi tanpa server sampeyan minangka kaputusan arsitektur. Nalika nggawe aplikasi, sampeyan ora ngarep-arep sedina bali menyang ngatur server. Milih vendor maya ora beda karo milih nggunakake wadhah utawa database, utawa malah basa pamrograman.
nimbang:
- Layanan apa sing sampeyan butuhake lan kenapa.
- Layanan apa sing disedhiyakake dening panyedhiya awan lan kepiye sampeyan bisa nggabungake karo solusi FaaS sing dipilih.
- Apa basa pemrograman sing didhukung (kanthi ngetik dinamis utawa statis, disusun utawa diinterpretasikake, apa pathokan, apa kinerja ing wiwitan kadhemen, apa ekosistem open source, lan sapiturute).
- Apa syarat keamanan sampeyan (SLA, 2FA, OAuth, HTTPS, SSL, lsp).
- Cara ngatur siklus pangembangan CI/CD lan piranti lunak.
- Solusi infrastruktur-minangka-kode sing bisa sampeyan gunakake.
Yen sampeyan ngluwihi aplikasi sing wis ana lan nambah fungsionalitas tanpa server, iki bisa uga mbatesi kemampuan sing kasedhiya. Nanging, meh kabeh teknologi tanpa server nyedhiyakake sawetara jinis API (liwat REST utawa antrian pesen) sing ngidini sampeyan nggawe ekstensi bebas saka inti aplikasi lan kanthi integrasi sing gampang. Goleki layanan kanthi API sing cetha, dokumentasi sing apik, lan komunitas sing kuwat, lan sampeyan ora bisa salah. Gampang integrasi asring bisa dadi metrik kunci, lan bisa uga dadi salah sawijining sebab utama kenapa AWS sukses wiwit Lambda dirilis ing 2015.
Nalika Serverless Apik
Teknologi tanpa server bisa ditrapake meh ing endi wae. Nanging, kaluwihan kasebut ora diwatesi mung siji cara aplikasi. Rintangan kanggo mlebu komputasi awan saiki sithik banget amarga teknologi tanpa server. Yen pangembang duwe ide, nanging ora ngerti carane ngatur infrastruktur awan lan ngoptimalake biaya, mula ora perlu golek insinyur kanggo nindakake. Yen wiwitan pengin mbangun platform nanging wedi yen biaya bisa metu saka kontrol, dheweke bisa kanthi gampang nguripake solusi tanpa server.
Amarga penghematan biaya lan gampang skala, solusi tanpa server bisa ditrapake kanggo sistem internal lan eksternal, nganti aplikasi web kanthi pirang-pirang yuta pamirsa. Akun diukur tinimbang ing euro, nanging ing sen. Nyewakake conto paling gampang saka AWS EC2 (t1.micro) sajrone sasi bakal biaya β¬ 15, sanajan sampeyan ora nindakake apa-apa (sing ora lali mateni?!). Yen dibandhingake, kanggo nggayuh tingkat mbuwang iki sajrone wektu sing padha, sampeyan kudu mbukak Lambda 512 MB sajrone 1 detik udakara 3 yuta kaping. Lan yen sampeyan ora nggunakake fitur iki, sampeyan ora mbayar apa-apa.
Amarga tanpa server utamane didorong acara, cukup gampang kanggo nambah infrastruktur tanpa server menyang sistem lawas. Contone, nggunakake AWS S3, Lambda, lan Kinesis, sampeyan bisa nggawe layanan analytics kanggo sistem ritel lawas sing bisa nampa data liwat API.
Umume platform tanpa server ndhukung macem-macem basa. Paling asring Python, JavaScript, C #, Java lan Go. Biasane ora ana watesan babagan panggunaan perpustakaan ing kabeh basa, mula sampeyan bisa nggunakake perpustakaan open source favorit. Nanging, disaranake supaya ora nyalahake dependensi supaya fungsi sampeyan bisa nindakake kanthi optimal lan ora nolak keuntungan saka skalabilitas aplikasi tanpa server sampeyan. Paket liyane sing kudu dimuat menyang wadhah, luwih suwe wiwitan kadhemen.
Miwiti sing adhem yaiku nalika sampeyan kudu miwiti wadhah, runtime, lan panangan kesalahan sadurunge digunakake. Amarga iki, wektu tundha ing eksekusi fungsi bisa nganti 3 detik, lan iki dudu pilihan sing paling apik kanggo pangguna sing ora sabar. Nanging, kadhemen diwiwiti nalika telpon pisanan sawise sawetara menit fungsi nganggur. Dadi akeh sing nganggep iki gangguan cilik sing bisa diatasi kanthi rutin ping fungsi kasebut supaya tetep ora aktif. Utawa padha nglirwakake aspek iki kabeh.
Senajan AWS dirilisNanging, database SQL ora becik kanggo aplikasi iki, amarga padha gumantung ing sambungan kanggo nindakake transaksi, kang bisa cepet dadi bottleneck karo lalu lintas abot ing AWS Lambda. Ya, para pangembang terus nambah Aurora Tanpa Server, lan sampeyan kudu nyoba, nanging saiki solusi NoSQL kaya. Nanging, ora ana sangsi manawa kahanan iki bakal owah banget.
Toolkit uga ngetrapake akeh larangan, utamane ing babagan tes lokal. Sanajan ana solusi kaya Docker-Lambda, DynamoDB Local lan LocalStack, mbutuhake kerja keras lan konfigurasi sing akeh. Nanging, kabeh proyek kasebut dikembangake kanthi aktif, dadi mung sawetara wektu sadurunge toolkit tekan level sing dibutuhake.
Dampak teknologi tanpa server ing siklus pangembangan
Amarga infrastruktur sampeyan mung konfigurasi, sampeyan bisa nemtokake lan nyebarake kode nggunakake skrip, kayata skrip cangkang. Utawa sampeyan bisa nggunakake solusi kelas konfigurasi-minangka-kode kaya . Sanajan layanan iki ora nyedhiyakake konfigurasi kanggo kabeh wilayah, nanging ngidini sampeyan nemtokake sumber daya tartamtu kanggo digunakake minangka fungsi Lambda. Sing, ing ngendi CloudFormation gagal sampeyan, sampeyan bisa nulis sumber daya dhewe (fungsi Lambda) sing bakal nutup celah iki. Kanthi cara iki sampeyan bisa nindakake apa wae, malah ngatur dependensi ing njaba lingkungan AWS sampeyan.
Amarga kabeh iku mung konfigurasi, sampeyan bisa ngatur skrip penyebaran kanggo lingkungan, wilayah, lan pangguna tartamtu, utamane yen sampeyan nggunakake solusi infrastruktur-minangka-kode kaya CloudFormation. Contone, sampeyan bisa masang salinan infrastruktur kanggo saben cabang ing repositori supaya sampeyan bisa nguji kanthi lengkap sajrone pembangunan. Iki kanthi drastis nyepetake umpan balik kanggo pangembang nalika pengin ngerti apa kode kasebut bisa digunakake ing lingkungan urip. Manajer ora perlu kuwatir babagan biaya nyebarake macem-macem lingkungan, amarga mung mbayar panggunaan nyata.
DevOps ora kuwatir amarga mung kudu nggawe pangembang duwe konfigurasi sing bener. Sampeyan ora perlu maneh ngatur instance, balancer, utawa grup keamanan. Mulane, istilah NoOps saya akeh digunakake, sanajan isih penting kanggo bisa ngatur infrastruktur, utamane nalika nerangake konfigurasi IAM lan optimalisasi sumber daya awan.
Ana alat ngawasi lan visualisasi sing kuat banget kaya Epsagon, Thundra, Dashbird lan IOPipe. Iki ngidini sampeyan ngawasi kahanan saiki aplikasi tanpa server, nyedhiyakake logging lan nelusuri, njupuk metrik kinerja lan kemacetan arsitektur, nindakake analisis lan prakiraan biaya, lan liya-liyane. Dheweke ora mung menehi insinyur, pangembang, lan arsitek DevOps tampilan lengkap babagan kinerja aplikasi, nanging uga ngidini manajer ngawasi kahanan kasebut kanthi nyata, kanthi biaya sumber daya saben detik lan prakiraan biaya. Luwih angel ngatur iki kanthi infrastruktur sing dikelola.
Ngrancang aplikasi tanpa server luwih gampang amarga sampeyan ora kudu masang server web, ngatur mesin virtual utawa wadhah, server patch, sistem operasi, gateway internet, lsp. Kanthi ngilangi kabeh tanggung jawab kasebut, arsitektur tanpa server bisa fokus ing inti - solusi, bisnis lan kabutuhan pelanggan.
Nalika toolkit bisa luwih apik (dadi luwih apik saben dina), pangembang bisa fokus kanggo ngetrapake logika bisnis lan nyebarake kerumitan aplikasi ing macem-macem layanan ing arsitektur. Manajemen aplikasi tanpa server adhedhasar acara lan diabstraksi dening panyedhiya maya (umpamane SQS, acara S3 utawa aliran DynamoDB). Mulane, pangembang mung kudu nulis logika bisnis kanggo nanggepi acara tartamtu, lan ora kudu padha sumelang ing bab carane paling apik kanggo ngleksanakake database lan pesen antrian, utawa carane ngatur karya optimal karo data ing panyimpenan hardware tartamtu.
Kode bisa mbukak lan debugged sacara lokal, kaya proses pangembangan. Pengujian unit tetep padha. Kemampuan kanggo nyebarake kabeh infrastruktur aplikasi kanthi konfigurasi tumpukan khusus ngidini pangembang cepet entuk umpan balik sing penting tanpa mikir babagan biaya tes utawa dampak ing lingkungan sing dikelola larang.
Piranti lan teknik kanggo mbangun aplikasi tanpa server
Ora ana cara khusus kanggo mbangun aplikasi tanpa server. Uga minangka set layanan kanggo tugas iki. AWS minangka pimpinan ing antarane solusi tanpa server sing kuat saiki, nanging deleng uga , ΠΈ . Yen sampeyan nggunakake AWS, banjur pendekatan sing disaranake kanggo ngumpulake aplikasi yaiku (SAM), utamane nalika nggunakake C #, amarga Visual Studio duwe alat sing apik. SAM CLI bisa nindakake kabeh sing Visual Studio bisa nindakake, supaya sampeyan ora bakal kelangan apa-apa yen sampeyan ngalih menyang IDE liyane utawa editor teks. Mesthine, SAM uga bisa nganggo basa liya.
Yen sampeyan nulis ing basa liya, Serverless Framework minangka alat open source sing apik banget sing ngidini sampeyan ngatur apa wae kanthi file konfigurasi YAML sing kuat banget. Framework Tanpa Server uga ndhukung macem-macem layanan awan, mula disaranake kanggo wong-wong sing nggoleki solusi multi-cloud. Nduwe komunitas gedhe sing nggawe pirang-pirang plugin kanggo kabutuhan apa wae.
Kanggo tes lokal, alat open source Docker-Lambda, Serverless Local, DynamoDB Local, lan LocalStack cocok banget. Teknologi tanpa server isih ana ing tahap pangembangan awal, uga alat kanggo dheweke, mula nalika nyiyapake skenario uji coba sing rumit, sampeyan kudu kerja keras. Nanging, mung masang tumpukan ing lingkungan lan nguji ana sing murah banget. Lan sampeyan ora perlu nggawe salinan lingkungan maya lokal sing tepat.
Gunakake AWS Lambda Layers kanggo nyuda ukuran paket sing disebar lan nyepetake download.
Gunakake basa pamrograman sing tepat kanggo tugas tartamtu. Basa sing beda-beda duwe kaluwihan lan kekurangane dhewe-dhewe. Ana akeh pathokan, nanging JavaScript, Python, lan C # (.NET Core 2.1+) minangka pimpinan ing babagan kinerja AWS Lambda. AWS Lambda bubar ngenalake Runtime API, sing ngidini sampeyan nemtokake basa sing dikarepake lan lingkungan runtime, supaya eksperimen.
Tansah ukuran paket cilik kanggo penyebaran. Sing luwih cilik, luwih cepet dimuat. Aja nggunakake perpustakaan gedhe, utamane yen sampeyan nggunakake sawetara fitur saka perpustakaan kasebut. Yen sampeyan nggawe program ing JavaScript, gunakake alat mbangun kaya Webpack kanggo ngoptimalake bangunan sampeyan lan mung kalebu apa sing sampeyan butuhake. NET inti 3.0 wis QuickJit lan Tiered Kompilasi kang mbenakake kinerja lan mbantu kathah ing kadhemen wiwit.
Ketergantungan fungsi tanpa server ing acara bisa dadi angel kanggo koordinasi logika bisnis ing wiwitan. Ing babagan iki, antrian pesen lan mesin negara bisa migunani banget. Fungsi Lambda bisa nelpon saben liyane, nanging mung nindakake iki yen sampeyan ora ngarep-arep respon ("geni lan lali") - sampeyan ora pengin njaluk tagihan kanggo ngenteni fungsi liyane rampung. Antrian pesen migunani kanggo ngisolasi bagean saka logika bisnis, ngatur bottlenecks aplikasi, lan ngolah transaksi (nggunakake antrian FIFO). Fungsi AWS Lambda bisa ditugasake menyang antrian SQS minangka antrian pesen sing macet sing nglacak pesen sing gagal kanggo analisis mengko. AWS Step Functions (mesin negara) migunani banget kanggo ngatur proses rumit sing mbutuhake chaining fungsi. Tinimbang fungsi Lambda nelpon fungsi liyane, fungsi langkah bisa koordinasi transisi negara, pass data antarane fungsi, lan ngatur negara fungsi global. Iki ngidini sampeyan nemtokake kahanan nyoba maneh, utawa apa sing kudu ditindakake nalika ana kesalahan tartamtu - alat sing kuat banget ing kahanan tartamtu.
kesimpulan
Ing taun-taun pungkasan, teknologi tanpa server wis berkembang kanthi cepet. Ana misconceptions tartamtu sing digandhengake karo owah-owahan paradigma iki. Kanthi abstraksi infrastruktur lan manajemen skala, solusi tanpa server nawakake keuntungan sing signifikan, saka pangembangan sing disederhanakake lan proses DevOps nganti pangurangan biaya operasional.
Nalika pendekatan tanpa server ora tanpa kekurangan, ana pola desain sing kuat sing bisa digunakake kanggo mbangun aplikasi tanpa server sing kuat utawa nggabungake unsur tanpa server menyang arsitektur sing wis ana.
Source: www.habr.com