Walaupun teknologi tanpa pelayan telah semakin popular sejak beberapa tahun kebelakangan ini, masih terdapat banyak salah tanggapan dan ketakutan yang berkaitan dengannya. Kebergantungan vendor, perkakas, pengurusan kos, permulaan dingin, pemantauan dan kitaran hayat pembangunan semuanya menjadi topik hangat apabila ia berkaitan dengan teknologi tanpa pelayan. Dalam artikel ini, kami akan meneroka beberapa topik yang dinyatakan, serta berkongsi petua dan pautan kepada sumber maklumat yang berguna untuk membantu pemula mencipta aplikasi tanpa pelayan yang berkuasa, fleksibel dan kos efektif.
Salah Tanggapan Mengenai Teknologi Tanpa Pelayan
Ramai orang berfikir bahawa pemprosesan tanpa pelayan dan tanpa pelayan (, FaaS) adalah perkara yang hampir sama. Ini bermakna perbezaannya tidak terlalu besar dan ia patut memperkenalkan sesuatu yang baru. Walaupun AWS Lambda adalah salah satu bintang zaman kegemilangan tanpa pelayan dan salah satu elemen paling popular dalam seni bina tanpa pelayan, namun, seni bina ini lebih daripada FaaS.
Prinsip asas di sebalik teknologi tanpa pelayan ialah anda tidak perlu risau tentang mengurus dan menskalakan infrastruktur anda, anda hanya membayar untuk apa yang anda gunakan. Banyak perkhidmatan memenuhi kriteria ini - AWS DynamoDB, S3, SNS atau SQS, Graphcool, Auth0, Now, Netlify, Firebase dan banyak lagi. Secara umum, tanpa pelayan bermaksud menggunakan kuasa penuh pengkomputeran awan tanpa perlu mengurus infrastruktur dan mengoptimumkannya untuk penskalaan. Ini juga bermakna keselamatan di peringkat infrastruktur tidak lagi menjadi kebimbangan anda, yang merupakan faedah besar memandangkan kesukaran dan kerumitan memenuhi piawaian keselamatan. Akhirnya, anda tidak perlu membeli infrastruktur yang disediakan kepada anda.
Tanpa pelayan boleh dianggap sebagai "keadaan fikiran": mentaliti tertentu semasa mereka bentuk penyelesaian. Elakkan pendekatan yang memerlukan penyelenggaraan mana-mana infrastruktur. Dengan pendekatan tanpa pelayan, kami meluangkan masa untuk menyelesaikan tugasan yang menjejaskan projek secara langsung dan membawa faedah kepada pengguna kami: kami mencipta logik perniagaan yang mampan, membangunkan antara muka pengguna dan membangunkan API yang boleh suai dan boleh dipercayai.
Sebagai contoh, jika mungkin untuk mengelak daripada mengurus dan mengekalkan platform carian teks percuma, maka itulah yang akan kami lakukan. Pendekatan untuk membina aplikasi ini boleh mempercepatkan masa ke pasaran, kerana anda tidak perlu lagi memikirkan tentang mengurus infrastruktur yang kompleks. Hapuskan tanggungjawab dan kos pengurusan infrastruktur dan fokus pada membina aplikasi dan perkhidmatan yang pelanggan anda perlukan. Patrick Debois memanggil pendekatan ini , istilah ini diterima pakai dalam komuniti tanpa pelayan. Fungsi harus dianggap sebagai pautan kepada perkhidmatan sebagai modul yang boleh digunakan (bukannya menggunakan keseluruhan perpustakaan atau aplikasi web). Ini memberikan butiran yang luar biasa untuk mengurus penggunaan dan perubahan pada aplikasi. Jika anda tidak boleh menggunakan fungsi dengan cara ini, maka ini mungkin menunjukkan bahawa fungsi melakukan terlalu banyak tugas dan perlu difaktorkan semula.
Ada yang keliru dengan pergantungan pada vendor semasa membangunkan aplikasi awan. Perkara yang sama berlaku dengan teknologi tanpa pelayan, dan ini bukanlah satu tanggapan yang salah. Mengikut pengalaman kami, membina aplikasi tanpa pelayan pada AWS, digabungkan dengan keupayaan AWS Lambda untuk menggabungkan perkhidmatan AWS lain bersama-sama, adalah sebahagian daripada kekuatan seni bina tanpa pelayan. Ini adalah contoh sinergi yang baik, apabila hasil gabungan lebih daripada sekadar jumlah terma. Cuba untuk mengelakkan pergantungan vendor boleh menghadapi lebih banyak masalah. Apabila bekerja dengan bekas, lebih mudah untuk mengurus lapisan abstraksi anda sendiri antara penyedia awan. Tetapi apabila ia datang kepada penyelesaian tanpa pelayan, usaha itu tidak akan membuahkan hasil, terutamanya jika keberkesanan kos diambil kira dari awal. Pastikan anda mengetahui cara vendor menyediakan perkhidmatan. Sesetengah perkhidmatan khusus bergantung pada titik integrasi dengan vendor lain dan mungkin menyediakan sambungan plug-and-play di luar kotak. Lebih mudah untuk memberikan panggilan Lambda daripada titik akhir API get laluan daripada memproksi permintaan kepada beberapa bekas atau contoh EC2. Graphcool menyediakan konfigurasi mudah dengan Auth0, yang lebih mudah daripada menggunakan alat pengesahan pihak ketiga.
Memilih vendor yang sesuai untuk aplikasi tanpa pelayan anda ialah keputusan seni bina. Apabila anda membuat aplikasi, anda tidak menjangka satu hari akan kembali ke mengurus pelayan. Memilih vendor awan tidak berbeza daripada memilih untuk menggunakan bekas atau pangkalan data, malah bahasa pengaturcaraan.
Pertimbangkan:
- Apakah perkhidmatan yang anda perlukan dan mengapa.
- Apakah perkhidmatan yang disediakan oleh pembekal awan dan bagaimana anda boleh menggabungkannya dengan penyelesaian FaaS pilihan anda.
- Apakah bahasa pengaturcaraan yang disokong (dengan menaip dinamik atau statik, disusun atau ditafsirkan, apakah penanda aras, apakah prestasi pada permulaan sejuk, apakah ekosistem sumber terbuka, dll.).
- Apakah keperluan keselamatan anda (SLA, 2FA, OAuth, HTTPS, SSL, dll.).
- Cara mengurus CI/CD dan kitaran pembangunan perisian anda.
- Penyelesaian infrastruktur-sebagai-kod yang boleh anda manfaatkan.
Jika anda melanjutkan aplikasi sedia ada dan menambah kefungsian tanpa pelayan secara berperingkat, ini mungkin mengehadkan sedikit keupayaan yang tersedia. Walau bagaimanapun, hampir semua teknologi tanpa pelayan menyediakan beberapa jenis API (melalui REST atau baris gilir mesej) yang membolehkan anda membuat sambungan bebas daripada teras aplikasi dan dengan penyepaduan yang mudah. Cari perkhidmatan dengan API yang jelas, dokumentasi yang baik dan komuniti yang kuat, dan anda tidak boleh salah. Kemudahan penyepaduan selalunya boleh menjadi metrik utama, dan mungkin merupakan salah satu sebab utama mengapa AWS telah begitu berjaya sejak Lambda dikeluarkan pada 2015.
Apabila Tanpa Pelayan Baik
Teknologi tanpa pelayan boleh digunakan hampir di mana-mana. Walau bagaimanapun, kelebihan mereka tidak terhad kepada hanya satu cara aplikasi. Halangan kemasukan untuk pengkomputeran awan hari ini sangat rendah terima kasih kepada teknologi tanpa pelayan. Jika pembangun mempunyai idea, tetapi mereka tidak tahu cara mengurus infrastruktur awan dan mengoptimumkan kos, maka mereka tidak perlu mencari beberapa jenis jurutera untuk melakukannya. Jika syarikat permulaan ingin membina platform tetapi bimbang kos tidak terkawal, mereka boleh beralih kepada penyelesaian tanpa pelayan dengan mudah.
Disebabkan oleh penjimatan kos dan kemudahan penskalaan, penyelesaian tanpa pelayan sama-sama terpakai untuk kedua-dua sistem dalaman dan luaran, sehingga aplikasi web dengan berjuta-juta khalayak. Akaun diukur dan bukannya dalam euro, tetapi dalam sen. Menyewa contoh paling mudah AWS EC2 (t1.micro) selama sebulan akan menelan kos β¬15, walaupun anda tidak melakukan apa-apa dengannya (siapa yang tidak pernah lupa untuk mematikannya?!). Sebagai perbandingan, untuk mencapai tahap perbelanjaan ini dalam tempoh masa yang sama, anda perlu menjalankan Lambda 512 MB selama 1 saat kira-kira 3 juta kali. Dan jika anda tidak menggunakan ciri ini, maka anda tidak akan membayar apa-apa.
Oleh kerana tanpa pelayan terutamanya didorong oleh peristiwa, adalah agak mudah untuk menambahkan infrastruktur tanpa pelayan pada sistem yang lebih lama. Contohnya, menggunakan AWS S3, Lambda dan Kinesis, anda boleh membuat perkhidmatan analitik untuk sistem runcit lama yang boleh menerima data melalui API.
Kebanyakan platform tanpa pelayan menyokong berbilang bahasa. Selalunya ia adalah Python, JavaScript, C#, Java dan Go. Biasanya tiada sekatan ke atas penggunaan perpustakaan dalam semua bahasa, jadi anda boleh menggunakan perpustakaan sumber terbuka kegemaran anda. Walau bagaimanapun, adalah dinasihatkan untuk tidak menyalahgunakan kebergantungan supaya fungsi anda berfungsi secara optimum dan tidak menafikan faedah skalabiliti besar aplikasi tanpa pelayan anda. Lebih banyak bungkusan yang perlu dimuatkan ke dalam bekas, semakin lama permulaan sejuk akan diambil.
Permulaan sejuk ialah apabila anda mula-mula perlu memulakan bekas, masa jalan dan pengendali ralat sebelum menggunakannya. Oleh kerana itu, kelewatan dalam pelaksanaan fungsi boleh sehingga 3 saat, dan ini bukan pilihan terbaik untuk pengguna yang tidak sabar. Walau bagaimanapun, permulaan sejuk berlaku pada panggilan pertama selepas beberapa minit fungsi melahu. Ramai yang menganggap ini sebagai gangguan kecil yang boleh diatasi dengan kerap ping fungsi untuk memastikan ia melahu. Atau mereka mengabaikan aspek ini sama sekali.
Walaupun AWS dikeluarkanWalau bagaimanapun, pangkalan data SQL tidak sesuai untuk aplikasi ini, kerana ia bergantung pada sambungan untuk melaksanakan urus niaga, yang dengan cepat boleh menjadi halangan dengan trafik padat di AWS Lambda. Ya, pembangun sentiasa menambah baik Aurora Tanpa Pelayan, dan anda harus mencubanya, tetapi hari ini penyelesaian NoSQL seperti. Walau bagaimanapun, tidak ada keraguan bahawa keadaan ini akan berubah tidak lama lagi.
Kit alat ini juga mengenakan banyak sekatan, terutamanya dalam bidang ujian tempatan. Walaupun terdapat penyelesaian seperti Docker-Lambda, DynamoDB Local dan LocalStack, ia memerlukan kerja keras dan sejumlah besar konfigurasi. Walau bagaimanapun, semua projek ini dibangunkan secara aktif, jadi hanya menunggu masa sebelum kit alat mencapai tahap yang kami perlukan.
Kesan teknologi tanpa pelayan pada kitaran pembangunan
Oleh kerana infrastruktur anda hanyalah konfigurasi, anda boleh menentukan dan menggunakan kod menggunakan skrip, seperti skrip shell. Atau anda boleh menggunakan penyelesaian kelas konfigurasi sebagai kod seperti . Walaupun perkhidmatan ini tidak menyediakan konfigurasi untuk semua kawasan, ia membenarkan anda menentukan sumber khusus untuk digunakan sebagai fungsi Lambda. Iaitu, apabila CloudFormation mengecewakan anda, anda boleh menulis sumber anda sendiri (fungsi Lambda) yang akan menutup jurang ini. Dengan cara ini anda boleh melakukan apa sahaja, malah mengkonfigurasi kebergantungan di luar persekitaran AWS anda.
Oleh kerana semuanya hanyalah konfigurasi, anda boleh menyesuaikan skrip penggunaan anda untuk persekitaran, wilayah dan pengguna tertentu, terutamanya jika anda menggunakan penyelesaian infrastruktur sebagai kod seperti CloudFormation. Sebagai contoh, anda boleh menggunakan salinan infrastruktur untuk setiap cawangan dalam repositori supaya anda boleh mengujinya sepenuhnya secara berasingan semasa pembangunan. Ini secara drastik mempercepatkan maklum balas untuk pembangun apabila mereka ingin memahami sama ada kod mereka berfungsi dengan secukupnya dalam persekitaran langsung. Pengurus tidak perlu bimbang tentang kos untuk menggunakan berbilang persekitaran, kerana mereka hanya membayar untuk penggunaan sebenar.
DevOps mempunyai lebih sedikit kebimbangan kerana mereka hanya perlu memastikan pembangun mempunyai konfigurasi yang betul. Anda tidak perlu lagi mengurus kejadian, pengimbang atau kumpulan keselamatan. Oleh itu, istilah NoOps semakin digunakan, walaupun masih penting untuk dapat mengkonfigurasi infrastruktur, terutamanya apabila ia berkaitan dengan konfigurasi IAM dan pengoptimuman sumber awan.
Terdapat alat pemantauan dan visualisasi yang sangat berkuasa seperti Epsagon, Thundra, Dashbird dan IOPipe. Ia membolehkan anda memantau keadaan semasa aplikasi tanpa pelayan anda, menyediakan pengelogan dan pengesanan, menangkap metrik prestasi dan kesesakan seni bina, melaksanakan analisis dan ramalan kos, dan banyak lagi. Mereka bukan sahaja memberi jurutera, pembangun dan arkitek DevOps pandangan yang komprehensif tentang prestasi aplikasi, tetapi juga membenarkan pengurus memantau keadaan dalam masa nyata, dengan kos sumber setiap saat dan ramalan kos. Adalah lebih sukar untuk mengatur ini dengan infrastruktur terurus.
Mereka bentuk aplikasi tanpa pelayan adalah lebih mudah kerana anda tidak perlu menggunakan pelayan web, mengurus mesin atau bekas maya, menampal pelayan, sistem pengendalian, gerbang internet, dsb. Dengan mengabsahkan semua tanggungjawab ini, seni bina tanpa pelayan boleh memfokuskan pada teras - penyelesaiannya.perniagaan dan keperluan pelanggan.
Walaupun kit alat boleh menjadi lebih baik (ia menjadi lebih baik setiap hari), pembangun boleh menumpukan pada melaksanakan logik perniagaan dan mengedarkan kerumitan aplikasi dengan terbaik merentas perkhidmatan yang berbeza dalam seni bina. Pengurusan aplikasi tanpa pelayan adalah berasaskan peristiwa dan disarikan oleh pembekal awan (cth. SQS, acara S3 atau strim DynamoDB). Oleh itu, pembangun hanya perlu menulis logik perniagaan untuk bertindak balas kepada peristiwa tertentu, dan tidak perlu risau tentang cara terbaik untuk melaksanakan pangkalan data dan baris gilir mesej, atau cara mengatur kerja optimum dengan data dalam storan perkakasan tertentu.
Kod boleh dijalankan dan nyahpepijat secara tempatan, seperti mana-mana proses pembangunan. Ujian unit tetap sama. Keupayaan untuk menggunakan keseluruhan infrastruktur aplikasi dengan konfigurasi tindanan tersuai membolehkan pembangun mendapatkan maklum balas penting dengan cepat tanpa memikirkan kos ujian atau kesan ke atas persekitaran terurus yang mahal.
Alat dan teknik untuk membina aplikasi tanpa pelayan
Tiada cara khusus untuk membina aplikasi tanpa pelayan. Serta satu set perkhidmatan untuk tugas ini. AWS ialah peneraju antara penyelesaian tanpa pelayan yang berkuasa hari ini, tetapi lihat juga , ΠΈ . Jika anda menggunakan AWS, pendekatan yang disyorkan untuk mengumpul aplikasi ialah (SAM), terutamanya apabila menggunakan C#, kerana Visual Studio mempunyai alatan yang hebat. SAM CLI boleh melakukan semua yang Visual Studio boleh lakukan, jadi anda tidak akan kehilangan apa-apa jika anda beralih kepada IDE atau editor teks yang lain. Sudah tentu, SAM berfungsi dengan bahasa lain juga.
Jika anda menulis dalam bahasa lain, Rangka Kerja Tanpa Pelayan ialah alat sumber terbuka yang sangat baik yang membolehkan anda mengkonfigurasi apa-apa sahaja dengan fail konfigurasi YAML yang sangat berkuasa. Rangka Kerja Tanpa Pelayan juga menyokong pelbagai perkhidmatan awan, jadi kami mengesyorkannya kepada mereka yang mencari penyelesaian berbilang awan. Ia mempunyai komuniti besar yang telah mencipta sekumpulan pemalam untuk sebarang keperluan.
Untuk ujian tempatan, alat sumber terbuka Docker-Lambda, Serverless Local, DynamoDB Local dan LocalStack sangat sesuai. Teknologi tanpa pelayan masih dalam peringkat awal pembangunannya, begitu juga dengan alatan untuknya, jadi apabila menyediakan senario ujian yang kompleks, anda perlu bekerja keras. Walau bagaimanapun, hanya menggunakan timbunan dalam persekitaran dan menguji di sana adalah sangat murah. Dan anda tidak perlu membuat salinan setempat yang tepat bagi persekitaran awan.
Gunakan AWS Lambda Layers untuk mengurangkan saiz pakej yang digunakan dan mempercepatkan muat turun.
Gunakan bahasa pengaturcaraan yang betul untuk tugasan tertentu. Bahasa yang berbeza mempunyai kelebihan dan kekurangan mereka sendiri. Terdapat banyak penanda aras, tetapi JavaScript, Python dan C# (.NET Core 2.1+) adalah peneraju dari segi prestasi AWS Lambda. AWS Lambda baru-baru ini memperkenalkan API Runtime, yang membolehkan anda menentukan bahasa dan persekitaran masa jalan yang anda inginkan, jadi lakukan percubaan.
Pastikan saiz pakej kecil untuk penggunaan. Lebih kecil ia, lebih cepat ia dimuatkan. Elakkan menggunakan perpustakaan yang besar, terutamanya jika anda menggunakan beberapa ciri daripadanya. Jika anda pengaturcaraan dalam JavaScript, gunakan alat binaan seperti Webpack untuk mengoptimumkan binaan anda dan hanya masukkan perkara yang anda perlukan. .NET Core 3.0 mempunyai QuickJit dan Kompilasi Berperingkat yang meningkatkan prestasi dan banyak membantu pada permulaan sejuk.
Pergantungan fungsi tanpa pelayan pada acara boleh menyukarkan untuk menyelaraskan logik perniagaan pada mulanya. Dalam hal ini, baris gilir mesej dan mesin keadaan boleh menjadi sangat berguna. Fungsi Lambda boleh memanggil satu sama lain, tetapi hanya lakukan ini jika anda tidak menjangkakan respons ("api dan lupakan") - anda tidak mahu dibilkan kerana menunggu fungsi lain selesai. Baris gilir mesej berguna untuk mengasingkan bahagian logik perniagaan, mengurus kesesakan aplikasi dan memproses transaksi (menggunakan baris gilir FIFO). Fungsi AWS Lambda boleh diberikan kepada baris gilir SQS sebagai baris gilir mesej tersekat yang menjejaki mesej yang gagal untuk analisis kemudian. Fungsi Langkah AWS (mesin keadaan) sangat berguna untuk mengurus proses kompleks yang memerlukan rantaian fungsi. Daripada fungsi Lambda memanggil fungsi lain, fungsi langkah boleh menyelaraskan peralihan keadaan, menghantar data antara fungsi dan mengurus keadaan fungsi global. Ini membolehkan anda menentukan syarat cuba semula, atau perkara yang perlu dilakukan apabila ralat tertentu berlaku - alat yang sangat berkuasa dalam keadaan tertentu.
Kesimpulan
Dalam beberapa tahun kebelakangan ini, teknologi tanpa pelayan telah berkembang pada kadar yang tidak pernah berlaku sebelum ini. Terdapat salah tanggapan tertentu yang berkaitan dengan anjakan paradigma ini. Dengan mengabstraksi pengurusan infrastruktur dan penskalaan, penyelesaian tanpa pelayan menawarkan faedah yang ketara, daripada pembangunan dipermudahkan dan proses DevOps kepada pengurangan besar-besaran dalam kos operasi.
Walaupun pendekatan tanpa pelayan bukan tanpa kelemahannya, terdapat corak reka bentuk teguh yang boleh digunakan untuk membina aplikasi tanpa pelayan yang teguh atau menyepadukan elemen tanpa pelayan ke dalam seni bina sedia ada.
Sumber: www.habr.com